Ressourcengruppelaufzeit

Verwenden Sie dies, um geschäftige Konten, Cooldowns oder Konversations-Routing zu untersuchen. Alltagsgebrauch.

SubLane Der Administrator kann den Planungszustand von Modell-Request-Leasings und vorübergehenden Kontoausfällen in jedem Pool verfolgen, der sich ein Konto teilt. KontenÄndern Sie ein Pro-Account-Limit durch Fahrplaneinstellungen, und prüfen Sie alle abgeschlossenen Anrufe unter Administration → Alle AnfragenJeder angemeldete Benutzer, einschließlich des Administrators, hat eine persönliche Allgemein → Anfragen Ansicht.

Zulassung und Affinität

Neue Konten sind standardmäßig 30 gleichzeitige Modellanforderungen, konfigurierbar von 1 bis 1.000. Upgrades behalten gespeicherte Kontolimits. Dies ist lokale Gateway-Kapazität, keine Provider-Garantie. Workspace-Kapazität ist standardmäßig auf 128 Operationen, einschließlich Kellner und gemeinsam genutzte Metadaten, die gelesen werden, und kann beim Start konfiguriert werden. Mitgliederkonkurrenz ist standardmäßig auf 10 und kann von 0 bis 1.000 eingestellt werden; 0 entfernt das Mitgliederlimit. Kontoleasing bleibt bis zur Schließung des Körpers über HTTP/SSE, Verdichtung und WebSocket Das Absenken eines Limits erlaubt es, bestehende Anfragen zu beenden.

Ein untätiges Gespräch oder ein offenes WebSocket Eine Verbindung verbraucht keinen Modellanforderungsschlitz zwischen den Kurven. Eine abgeschlossene Antwort gibt ihren Schlitz frei, wenn der Körper schließt. Codex Stream kann bis zu drei Sekunden lang weiterlesen, um die endgültige Nutzung zu sammeln, bevor er seinen Slot freigibt; die konfigurierbare Gesamtanforderungsfrist (standardmäßig 30 Minuten) und die Prozessabschaltung gelten weiterhin. Wenn der Client eine Anforderung ohne Absenden von Stornierungen laufen lässt, behält diese Anforderung ihren Slot, bis sie endet oder die Anforderungsfrist erreicht.

Ein gebundenes Gespräch führt sein Konto; eine vom Kunden initiierte Änderung an einem anderen Modell mit vollständiger tragbarer Historie kann ein unterstützendes Konto auswählen, wenn das Girokonto es nicht bedienen kann; Modell-Routing Kapazitäts- und Gesundheitsänderungen allein bewirken nie eine Bindung, wenn die Kapazität voll ist, wartet ein neuer Antrag bis 30 Sekunden standardmäßig, mit höchstens 100 Warteanforderungen pro Pool standardmäßigEin freigegebener Kontoplatz oder ein erhöhtes Konkurrenzlimit weckt Warteanfragen. HTTP 429 account_queue_full; eine abgelaufene Warterückkehr HTTP 429 account_wait_timeout, beide mit Retry-After: 1Warten und diese lokalen Ablehnungen unterbrechen keine aktiven Streams oder bestrafen die Gesundheit vorgelagerter Konten.

Warteanfragen zählen zu den eintrittslimits für das mitglied und den arbeitsbereich und verbrauchen das mitglied. RPM Einmalige Kontingent. Sie reservieren keine Kontingent oder verbrauchen einen Kontoplatz bis zur Zulassung. Poolzugriff, Modellrichtlinie, Mitgliederfreigabe, Schlüsselfreigabe/-widerruf/-ablauf, Kontozustand, Abonnementkontingent und Kontingent werden vor dem Versand erneut überprüft. Kundenkündigung und Service-Abschaltung entfernen Warteanforderungen umgehend. Warten gibt die Zutrittssperre frei und führt keine Datenbanktransaktion durch; abgeschlossene Nutzung wird aufgezeichnet, bevor ein freigegebener Platz für eine andere Anfrage verfügbar wird.

Cooldown-Erträge HTTP 429 account_cooling Eine sitzungslose oder neue Konversation kann sofort ein anderes berechtigtes Konto verwenden; eine gebundene Konversation wartet nur auf ihr ursprüngliches Konto. Die Erschöpfung der Abonnementquote, Mitglieder-/Arbeitsplatzgrenzen und Zutrittsfehler bleiben ihre normalen Wachen.

ohne Session_id oder ein nonempt prompt_cache_key, erhält jeder Anruf eine unabhängige Auswahl und eine zufällige vorgelagerte Korrelations-ID. Er liest oder erzeugt keinen Affinitätseintrag. Neue native Auswahlen rotieren innerhalb jedes Pools zwischen berechtigten Abonnementkonten, die das Modell unterstützen. Explizite Legacy-Präfixe begrenzen die Auswahl auf ihren Provider. Bestehende explizite Standardgruppengespräche behalten ihren historischen Digest.

Das Limit deckt Modellanforderungen ab; Kontoverifizierung, Modellerkennung und Quotenlesungen bleiben durch die bestehende globale Zulassungsrichtlinie begrenzt und verbrauchen keine Modellanforderungs-Slots.

Beispiel Account Scheduling und Subscription Quota View mit synthetischen Werten:

Cooldown und Erholung

Kontoweite Kühlung ist für vorgelagerte 429 Antworten reserviert. Retry-After innerhalb von 1–3600 Sekunden erfüllt wird; bei Abwesenheit oder Ungültigkeit sind die konfigurierbaren Fallback-Standards auf 5 Sekunden festgelegt. Credential Refresh-Ausfälle haben ihre eigenen Backoffs. Anforderungsfristen, HTTP 408 und unbekannte Netzwerkausfälle kühlen nicht das gesamte Konto.

Explizite vorgeschaltete 5xx-Antworten und ungültige/unterbrochene Streams werden für das ausgewählte Konto und Modell gezählt. Der Standardschwellenwert beträgt drei logische Fehler innerhalb von zwei Minuten, gefolgt von einer 10-Sekunden-Modellabklingzeit. Wiederholte Fehler erhöhen die Verzögerung auf bis zu fünf Minuten. Der Schwellenwert, das Fenster und die anfängliche Dauer sind konfigurierbar. Ein Schwellenwert von 0 deaktiviert vorübergehende Modellabklingzeiten. Andere Modelle bleiben förderfähig. Erfolgreiche gewöhnliche Wiederherstellungsanforderungen löschen den zutreffenden Zustand; verspätete Ergebnisse können neuere Fehler nicht löschen. Bestehende strukturierte Fehler Antigravity Modellzinsobergrenzen behalten ihre Einziehungsregeln bei.

Vor der Annahme einer erfolgreichen vorgelagerten Antwort, explizit HTTP Ablehnungen 408, 500, 502, 503 und 504 können zweimal auf demselben Konto wiederholt werden, mit begrenztem Backoff. Retries überprüfen die aktuellen Mitgliedschafts-, Schlüssel-, Gruppen-/Modellrichtlinien, Quoten-, Kontolebenszyklus- und Inhaltsregeln. Sie behalten eine Leasing-, Anfrage-ID, Historie-Aufzeichnung und endgültige Abrechnung. Lange Upstream-Wiederholungshinweise werden zurückgegeben, anstatt vorzeitig wiedergegeben. Netzwerkunsicherheit, 400/401/403/429, akzeptierte Streams und Teilausgabe werden nicht automatisch durch diesen Mechanismus wiedergegeben. Der bestehende explizite 401-Anmelde-Erneuerungsversuch bleibt getrennt.

HTTP SSE Ein optionaler Stream-Idle-Timeout zählt nur Upstream-Ereignisse; Downstream-Herzschläge können ein blockiertes Modell nicht verbergen. Es wird standardmäßig ausgeschaltet. Inference-Header-Timeout ist standardmäßig auf fünf Minuten, Metadaten halten seinen kürzeren Timeout und die Gesamtanforderung / Turn-Timeout ist standardmäßig auf 30 Minuten. Bereitstellungskonfiguration.

Administratoren können Abklingzeiten löschen, ohne ein Konto zu aktivieren, die Autorisierung zu erneuern oder die Abonnementquote wiederherzustellen. Bestehende Gespräche behalten ihr ursprüngliches Konto. Abklingzeiten von Konten/Modellen überleben den Neustart.

Credential Refresh und Recovery

Codex Anmeldeinformationen werden bei Bedarf innerhalb von zwei Minuten nach Ablauf aktualisiert. Wenn diese Aktualisierung vorübergehend fehlschlägt, können Anforderungen mit dem vorhandenen Zugriffstoken nur solange fortgesetzt werden, bis mehr als 30 Sekunden verbleiben und sie nicht vom Upstream abgelehnt wurden. Der Ablauf wird nach dem Aktualisierungsversuch erneut überprüft. Claude und Antigravity ihre bestehenden Gültigkeitsanforderungen beibehalten.

Fehlgeschlagene Aktualisierungsversuche teilen sich eine kontospezifische Wiederholungsverzögerung: 30 Sekunden, eine Minute, zwei Minuten, vier Minuten, dann höchstens fünf Minuten. OAuth Retry-After Wenn die Verzögerung abläuft, kann die nächste Anforderung zum Auslesen von Berechtigungen oder Modellen wiederholt werden; es gibt keine zusätzliche Hintergrundabfrageschleife. Andere Konten behalten ihre eigenen Wiederholungspläne bei.

Wenn kein verwendbares Token verbleibt, fordert das Modell die Rückgabe an 503 account_refresh_failed mit Retry-After. Refresh-Fehler akkumulieren keine Abklingstrafen für Modellanrufe. Erfolgreiches Refresh oder Reauthorization löscht den Refresh-Wiederholungszustand. Retry-Verzögerungen sind prozesslokal, während eine vorgelagerte Ablehnung mit dem verschlüsselten Berechtigungsnachweis gespeichert wird, so dass ein Neustart dieses Token nicht wieder für ein Fallback geeignet machen kann.

Die Codex Token-Endpunkt muss einen expliziten Berechtigungsfehler zurückgeben, wie z.B. invalid_grant oder refresh_token_reused, um eine erneute Autorisierung zu erfordern. Eine unbekannte HTTP 400/401, Proxy-Antwort oder geteilt OAuth Ein aktualisiertes Token, das immer noch vom Modell-Endpunkt abgelehnt wird, erfordert weiterhin eine erneute Autorisierung. Bestehende Gespräche halten ihr Konto während der gesamten Wiederherstellung bindend.

Quotenbewusste Auswahl

Codex, Claude und Antigravity Modellverkehr startet gemeinsame Hintergrundquoten-Aktualisierungen für berechtigte Poolkonten, ohne auf Provider-IO zu warten. Höchstens zwei Quotenlesungen laufen gleichzeitig innerhalb der Arbeitsbereich-Eintrittsschlitze; doppelte Lesevorgänge verschmelzen und bestehende Cooldown-/Backoff-Regeln gelten. Es gibt keine allgemeine untätige Umfrageschleife. Verwaltete Freigaberessourcen führen nach Abschluss der Anfrage zusätzlich begrenzte Wiederholungen aus, um die wartende Nutzung, auch nach der letzten Anfrage, abzugleichen; siehe Versöhnung und Pausen. Claude Hauptfenster können ein erschöpftes Konto ausschließen. Antigravity überprüft nur das genau angeforderte native Modell, mit SDK Thinking Suffixes normalisiert; andere Modelle bleiben förderfähig und der kontoweite Laufzeitzustand bleibt verfügbar.

für Codex und Claude, Auswahl liest die persistierte normalisiert Haupthauptstadt Abonnementlimit in derselben kurzen Transaktion wie Pool-Richtlinie und Affinität. Eine explizite Denial, ein Erreichen-Limit-Flag oder ein Fenster bei 100% verwendet schließt das Konto von der Neuauswahl nur aus, wenn die Beobachtung frisch ist (zwei Minuten, verkürzt durch einen Reset). Unbekannte, veraltete, zukunftsgerichtete oder bereits zurückgesetzte Daten bedeuten nicht Nullquote. Zusätzliche benannte Limits werden nicht angenommen, um Modellen zuzuordnen und können ein ganzes Konto nicht ausschließen. Niedrige, aber positive Quote verändert nicht die Round-Robin-Gewichte. Eine fehlgeschlagene Aktualisierung behält die letzte erfolgreiche Beobachtung bei; sie kann die Terminplanung nur bis zu ihrer ursprünglichen Frischefrist auf unbestimmte Zeit beeinflussen.

Ein gebundenes Gespräch, dessen Konto oder angefordert Antigravity Modell ist erschöpfte Renditen HTTP 403 quota_exhausted. Der Anbieter wird nach dem Momentaufnahme-Fristtermin für Frische/Reset erneut überprüft; das Erreichen dieses Zeitpunkts ist kein Versprechen, dass die Kontingent wieder eingezogen wurde; es wird nie auf ein anderes Konto umgestellt; die Ablehnung von Quoten erhöht nicht vorübergehende Ausfälle, und Klare Abklingzeit die Zeichnungsquote nicht löscht; die Konten weisen einen eindeutigen Status der Quotenerschöpfung auf.

Erfolgreiche Beobachtungen werden vor der Veröffentlichung gespeichert und überleben Neustart. Quota-Zeilen tragen die bestehende Konto Lifecycle-Revision; deaktivieren/aktivieren und Reautorisierung frühere Beobachtungen ungültig, und bedingt schreibt ablehnen ältere Aktualisierungen während des Fluges. Das konsolidierte Schema speichert Lifecycle-Revision Metadaten mit Quota-Zeilen und Anforderung Diagnose.

Aufzeichnungen der letzten Anfrage

Aufzeichnungen umfassen authentifizierte Modellversuche, die die Gateway-Zeitplanung erreichen, einschließlich der Ablehnung von Kontokapazitäten/Cooldown-Abmeldungen; Authentifizierungsfehler; HTTP Fehler bei der Validierung von Stellen/Inhaltstypen, globale Ablehnung der Zulassung, Modellfindung, Quotenabfragen und WebSocket Vorwarm erstellen Sie keine Modellaufrufdatensätze.

Gespeicherte Metadaten sind beschränkt auf Benutzer/Schlüssel/Pool/Konto-IDs, Anbieter, eine begrenzte Modell-ID, Protokoll/Operation, Startzeit, Dauer, Anfragekorrelations-ID, nullbare erste Ausgabelatenz, Ergebnis, entsorgter Fehlercode, Upstream HTTP Status und gemeldete Input-/Output-/Cache-Token-Zahlen; Eingabeaufforderungen, Response-Bodys, Roh-Provider-Fehler, Header, IP-Adressen, Session-Identifier und Anmeldeinformationen werden nicht aufgezeichnet; fehlende Token-Zahlen bleiben null; Zählungen beschreiben einzelne beobachtete Antworten; sie sind keine Abrechnung oder das Ressourcenzuweisungs-Ledger; unabhängige tägliche Zusammenfassungen und Mitgliederanforderungslimits werden beschrieben in TeamkontrollenEin Stream kann HTTP 200 endet jedoch mit einem Fehler, so dass Ergebnis und Upstream-Status unterschiedlich sind.

Persönliche Datensätze werden vom authentifizierten Sitzungsbenutzer in SQL vor der Paginierung gefiltert; eine vom Kunden bereitgestellte Benutzer-ID oder ein Umfang kann den Zugriff nicht erweitern. API Antwort. Benutzer können ihre eigene Historie nach Ergebnis, genauem Modell filtern. API Schlüssel, Request-ID und Zeitintervall, einschließlich Anrufe über Schlüssel, die anschließend widerrufen wurden. Administratoren können getrennt nach Mitglieds- und Abonnementkonto filtern. Anruferoptionen ergeben sich nur aus dem gespeicherten Verlauf innerhalb desselben Besitzumfangs. Beide Ansichten werden in einer fortlaufenden Reihenfolge von 50 gespeichert. Höchstens 5.000 Datensätze werden in einem Sieben-Tage-Fenster gespeichert. Die Bereinigung läuft atomar bei der Aufzeichnung und beim Lesen des Verlaufs; untätige Datensätze werden bei der nächsten Operation wiederverwendet. Monotonische Datensatz-IDs werden nach der Bereinigung der Aufbewahrung nicht wiederverwendet. Gelöschte Kontonamen werden als gelöscht dargestellt, ohne historische Metadaten zu löschen.

In Tabellen mit persönlicher und Administratoranforderung wird neben der Anzahl der zwischengespeicherten Token eine Trefferrate des Input-Token-Caches angezeigt: zwischengespeicherte Input-Token geteilt durch die Gesamtzahl der Input-Token, formatiert als Prozentsatz mit höchstens einer Dezimalstelle. Hierbei wird der Anteil der aus dem Upstream-Cache bereitgestellten Input-Token gemessen, nicht der Anteil der Anforderungen, die einen Cache getroffen haben. Eine gemeldete Null-Cache-Zählung mit positiver Eingabe zeigt 0%; fehlende Zählungen, Null-Eingaben oder eine Cache-Zählung, die die Gesamteingabe übersteigt, zeigen einen em-Schlag. Die Rate wird aus vorhandenen Anfrage-Metadaten abgeleitet und fügt keine gespeicherte Spalte oder Upstream-Anfrage hinzu.

Jeder neue Modellversuch erhält einen Server-generierten req_… Identifikator, ignoriert von Anrufern bereitgestellte IDs. HTTP Antworten geben es zurück in X-Request-ID; WebSocket Turns Add Add request_id zu erstellten/vervollständigten/unvollständigen Ereignissen und Gateway-Fehlern. Die vorgeschaltete Antwort-ID ist unverändert. Datensätze von vor dem Upgrade haben keine Korrelations-ID oder Erstausgabemessung. Die Anforderungstabelle zeigt eine kompakte ID unter jedem Startzeitpunkt mit einer Kopieraktion für den vollständigen Wert. Wenn Sie auf den Startzeitpunkt klicken, werden die Details mit der vollständigen ID geöffnet.

first_token_ms Es ist nicht die Zeit bis zum ersten Lifecycle-Ereignis oder Client-Rendered-Token. Compaction, streams without a observed delta and older records keep null; die Benutzeroberfläche nennt es erster AusgangDie Gesamtdauer umfasst noch immer die Schließung des Körpers.

Beispiel persönliche Anfrage Diagnose mit synthetischen Aufzeichnungen:

API und Lagerung

• GET /api/accounts/runtime: aktuelle Scheduling-Status- und Model-Request-Counts.
• PATCH /api/accounts/{id}/limits: eingestellt max_concurrency (ganzzahl 1–1.000).
• POST /api/accounts/{id}/resume: explizit klare Abklingzeit/Ausfälle.
• GET /api/me/requests?cursor=0&outcome=: Metadaten der aktuellen Benutzeranfrage für beide aktivierten Rollen.
• GET /api/requests?cursor=0&account_id=&outcome=Administrator fordert Metadaten an; Ergebnis kann Erfolg, unvollständig, Fehler, abgebrochen oder abgelehnt sein.

Beide History-Endpunkte akzeptieren ebenfalls model, request_id, key_id, from (einschließlich Unix-Sekunden) und until (exklusive Unix-Sekunden); der Administrator-Endpunkt akzeptiert user_idDie Aufbewahrung bleibt sieben Tage, unabhängig von der beantragten Reichweite. GET /api/me/requests/filters und Administrator-only GET /api/requests/filters Rückgabebegrenzte Anrufer-/Schlüsselauswahl ohne Abonnementidentität oder geheime Werte.

Abgesehen von den explizit persönlichen historischen Endpunkten erfordern diese Routen eine aktivierte Administratorsitzung; Mutationen behalten den Ursprung /JSON Schutzmaßnahmen. Das konsolidierte Schema erstellt Workspace-scoped Laufzeit- und Historientabellen. credentials.key vor dem Austausch einer Entwicklungsinstallation.

Modellspezifische Grenzwerte

Explizit strukturiert Antigravity Unbekannte 429-Antworten behalten die kontoweite Abklingzeit bei, Modelllimits bleiben beim Neustart bestehen und gehören zum Lebenszyklus des aktuellen Kontos; Neuautorisierung, Deaktivierung/Aktivierung und manuelle Abklingzeitverrechnung machen den vorherigen Zustand ungültig.

Ein begrenztes Modell kehrt zurück 429 model_cooling; das ursprüngliche Provider-Limit wird als 429 model_rate_limited. Beide behalten begrenzte Wiederholungsanweisungen bei. Andere Modelle bleiben verwendbar, und bestehende Gespräche behalten ihre ursprüngliche Accountbindung bei. Nach dem Cooldown versucht höchstens eine normale Anforderung für dieses Modell die Wiederherstellung zu einem Zeitpunkt; es wird keine zusätzliche Inferenzsonde gesendet. Ältere oder nicht verwandte Erfolge können ein neueres Limit nicht löschen. Ein fehlgeschlagener Persistenzversuch behält die Einschränkung im aktuellen Prozess bei und wird als Persistenzfehler protokolliert.

Kontokarten zeigen eine begrenzte Modellzahl an, während die gesamte Kontoplanung weiterhin verfügbar ist. Planungseinstellungen → Klare Abklingzeit löscht Konto- und Modell-Cooldowns, ohne die Freigabe-, Autorisierungs- oder Abonnementquote zu ändern. HTTP 403 wird berichtet als upstream_forbiddenstatt einer erneuten Autorisierung.

Automatische Codex-Freigabeprüfungen

Bei codex-auto-review-Anfragen mit der Kennzeichnung guardian oder review können übereinstimmende Metadaten des übergeordneten Threads dessen Konto bevorzugen, innerhalb desselben authentifizierten Benutzers und derselben Ressourcengruppe. Eine bestehende Bindung der untergeordneten Sitzung hat Vorrang. Das Konto muss weiterhin Prüfungen für Modellunterstützung, Berechtigungen, Kontingente, Nutzungslimits und Kapazität bestehen. Fehlende, widersprüchliche, mehrdeutige, abgelaufene oder nicht verfügbare Elterninformationen führen zur normalen Auswahl zurück, ohne die übergeordnete Bindung zu ändern. Sitzungs- und Cache-IDs bleiben getrennt. HTTP- und WebSocket-Tests verwenden synthetische Daten; die Akzeptanz durch einen echten Codex-Client ist noch nicht geprüft.

Neue Gespräche nach Restkontingent verteilen

SUBLANE_GATEWAY_QUOTA_WEIGHTED=true gewichtet nach dem engsten verbleibenden Prozentfenster. Nur für Kandidaten derselben Prioritätsstufe und desselben unterstützten Anbieters mit frischen vollständigen Zahlen; Antigravity nutzt das genaue Modell. Unbekannte, veraltete, unvollständige oder gemischte Daten behalten gleiche Rotation.

Standardmäßig aus; Neustart erforderlich. Bestehende Bindungen, Elternkonto-Präferenz, Modellrechte, Kontingente und Parallelitätsprüfungen bleiben maßgeblich. Prozentwerte sind eine Heuristik, keine vergleichbare absolute Plankapazität.