Codex Abonnements und Gateway

Mit einem persönlichen Schlüssel bereit, konfigurieren Sie Ihren Client unten. Erster Antrag Oder fragen Sie Ihren Administrator nach einem Mitglieds-Login.

Clientkonfiguration

Erstellen Sie ein persönliches API Schlüssel in API-Schlüssel. Verwenden Sie die Instanz origin plus /v1 als Basis-URL. Konfigurieren Sie eine Modell-ID, die zurückgegeben wird GET /v1/models.

Setz SUBLANE_API_KEY in der Client-Prozessumgebung die folgenden Einstellungen auf Benutzerebene zusammenführen ~/.codex/config.toml, ersetzt übereinstimmende vorhandene Werte:

model = "<model-id-from-your-account>"
model_provider = "sublane"

[model_providers.sublane]
name = "SubLane"
base_url = "http://127.0.0.1:8080/v1"
env_key = "SUBLANE_API_KEY"
wire_api = "responses"
requires_openai_auth = false
supports_websockets = true

Verwenden Sie die tatsächliche URL Ihrer Instanz, mit HTTPS für den Netzeinsatz. HTTP/SSE Transport, eingestellt supports_websockets = false. Codex CLI und Desktop müssen die vorgesehene Konfiguration auf Benutzerebene lesen.Eine bereits laufende Desktop-App erbt nicht automatisch Umgebungsvariablen, die in einem anderen Terminal exportiert werden; starten Sie sie in einer Umgebung neu, in der der Schlüssel verfügbar ist.

Die API Keys Page bietet einen Konfigurations-Snippet ohne Einbettung oder Beibehaltung des Geheimnisses. CC Switch Einfuhr der den gewählten Schlüssel nach expliziter Vorbereitung an die lokal installierte Anwendung weiterleitet. CC Switch Erzeugt seine eigene Codex Authentifizierungsdateikonfiguration; sie bewahrt nicht die Umgebungsvariable oder WebSocket Einstellungen im manuellen Snippet oben. erweiterte Konfiguration und Authentifizierung Anleitungen zur Client-Konfiguration und Credential Storage.

Account-Kataloge werden zwischengespeichert und überleben Neustarts. Discovery, Pool-Aggregation und modellbewusste Account-Auswahl werden beschrieben in Modellkataloge.

Nach dem Einrichten: Senden Sie eine Nachricht und überprüfen Sie die Antwort, dann fahren Sie fort mit Alltagsgebrauch. Das Konto, das Kontingent und die Protokolldetails unten sind Referenzen für später.

Fügen Sie ein Konto hinzu

Melden Sie sich als Administrator an, öffnen Kontenund wählen Konto hinzufügenMitglieder können nicht auf Abonnementverwaltungsendpunkte oder Anmeldeinformationen zugreifen.

• Browser-Autorisierung: Benennen Sie das Konto, starten Sie die Autorisierung und öffnen Sie die OpenAI Nach dem Einloggen kopieren Sie den vollständigen http://localhost:1455/auth/callback?... Adresse aus der Browser-Adressleiste und fügen Sie sie in SubLaneEin Localhost-Verbindungsfehler an dieser Stelle wird erwartet: SubLane Dieser manuelle Rückfluss funktioniert für lokale und Remote-Bereitstellungen.
• Import auth.json: Wählen Sie eine Codex Abo Credential File oder Einfügen seiner JSON. Beide CLI's verschachtelt tokens Struktur und die flache Codex Das Token-Format wird akzeptiert. Offiziell API Schlüssel werden abgelehnt. SubLane Scannt niemals lokale Client-Verzeichnisse, sondern liest nur den Inhalt, der ausdrücklich vom Administrator eingereicht wurde. Importierte Endpunkt-/Proxy-Einstellungen werden verworfen.

Account Authorization/Import startet die Modellerkennung automatisch. Verbindung überprüfen um den Modellkatalog des Kontos zu aktualisieren und fortzusetzen oder zu öffnen Modelle Eingeführte Nachweise zeigen Nicht überprüft Das Kontomenü bietet Aktivierung/Deaktivierung, Reautorisierung und Löschung. Die Reautorisierung muss die gleiche vorgelagerte Kontoidentität beibehalten. SubLane; es widerruft das ChatGPT-Login selbst nicht.

Codex model discovery sendet die effektive Client-Version der Instanz in den Katalogabfrage- und Anforderungs-Headern. Administration → Systemeinstellungen: eine explizite Version hat Vorrang vor dem letzten synchronisierten offiziellen stabilen Release, mit 0.155.1 Automatische Freigabe überprüft standardmäßig alle sechs Stunden. Dies ändert Protokoll-Metadaten ohne Installation Codex oder Aktualisierung des Embedded SDK; siehe Systemeinstellungen.

Der Upstream-Katalog hängt von dieser Version ab: eine veraltete Version kann zurückkehren HTTP 200 mit nur versteckten Modellen oder einem teilweisen sichtbaren Katalog, wodurch ein leerer oder unvollständiger /v1/models Liste nach Sichtbarkeitsfilterung. Persisted-Kataloge enthalten die eigentliche Discovery-Version, so dass das Ändern der effektiven Version eine Aktualisierung bei der nächsten Kataloglese- oder Modellanforderung auslöst, auch wenn ihre Zeitstempel frisch bleiben. Durch Ändern der Poolberechtigungen wird dieses Kompatibilitätsproblem nicht behoben.

OAuth Versuchsverwendung PKCEDer Rückruf ist an die Sitzung gebunden, die ihn gestartet und vor dem Austausch seines Codes verbraucht hat. Das Schließen des Formulars fordert Stornierung; Ablauf ist das Fallback nach einer verlorenen Verbindung. OAuth Der Zustand wird nur im Gedächtnis gehalten.

Nutzung von Abonnements

Die Kontenseite zeigt Kontingentfenster, verbleibenden Anteil, Reset-Countdown und Beobachtungszeit aktivierter Codex-Konten sowie gemeldete zusätzliche Modellgrenzen. Die Kartenanzahl ist separat: Unbekannt und ausdrücklich null unterscheiden sich. Liste und optionale Nutzung stehen unter Reset-Karten. Fehlende Daten bleiben unbekannt; Fehler erhalten den alten Snapshot mit Warnung. Ein erreichter Reset-Zeitpunkt bestätigt keine Erholung: Aktualisieren Sie die Nutzung.

Der Use Adapter liest https://chatgpt.com/backend-api/wham/usage und die getrennten https://chatgpt.com/backend-api/wham/rate-limit-reset-credits Endpunkt, passend zum amtlicher amtlicher Codex Backend-Client. Beide Anfragen verwenden die Anmeldeinformationen des ausgewählten Kontos, den vorhandenen Aktualisierungs-/Retry-Eigentümer, einen begrenzten Gateway-Eintritt, eine gemeinsame 20-Sekunden-Frist und einen 128-Kib-Band pro Antwort. Wenn die Reset-Karten-Detail-Anfrage fehlschlägt oder eine Zählung auslässt, bleibt das Kontingent verfügbar und jede gültige Zählung aus der Nutzungsantwort bleibt erhalten. Nur normalisierte Kontingentfelder und die Zählung werden zurückgegeben; rohe Upstream-Metadaten, Karten-IDs und Anmeldeinformationen sind ausgeschlossen. Dieser Backend-Vertrag kann sich unabhängig von SubLane.

Das konsolidierte Schema speichert eine begrenzte, normalisierte Quote und einen Reset-Karten-Snapshot pro Konto in SQLiteSnapshots enthalten die letzte erfolgreiche Beobachtungszeit und überleben Prozessneustarts; Löschen eines Kontos Kaskaden zu seinem Snapshot; Der Prozess hält maximal 100 Snapshot-Einträge im Speicher und lahmt sie aus SQLiteIn dieser Tabelle werden keine Anmeldeinformationen oder Roh-Provider-Antworten gespeichert.

GET /api/accounts/{id}/usage einen frischen Snapshot für bis zu zwei Minuten (oder bis zu einem gemeldeten bevorstehenden Reset, falls früher) zurückgibt. stale und refreshing Flags während ein Background Refresh läuft. Ein erster Abruf ohne Snapshot wartet auf das Ergebnis. POST /api/accounts/{id}/usage/refresh Umgeht Frische und wartet auf die gemeinsame Aktualisierung, während eine Abklingzeit von fünf Sekunden eingehalten wird. Beide Routen erfordern eine aktivierte Administratorsitzung; POST erfordert auch den vorhandenen Ursprung /JSON Kontrollen.

Gleichzeitige Anrufer für dasselbe Konto teilen sich eine Upstream-Operation. Refreshes verwenden die konfigurierte Arbeitsbereichskapazität (standardmäßig 128, über SUBLANE_GATEWAY_CAPACITY) und eine 45-Sekunden-Gesamtfrist, überleben eine individuelle Browsertrennung und werden während des Prozessabbruchs abgebrochen/erwartet. Eine fehlgeschlagene Aktualisierung behält die vorherigen Werte und den Zeitstempel bei, markiert sie als veraltet und schaltet sich für 30 Sekunden (oder eine längere gültige Upstream-Wiederholung nach, bis zu einer Stunde) zurück. Die Einlasssättigung erfolgt mit einer Verzögerung von fünf Sekunden. Cache-Treffer prüfen weiterhin die Existenz und Aktivierung des Kontos. Transienter Ausfall/Backoff-Zustand ist prozesslokal; der letzte erfolgreiche Snapshot ist dauerhaft.

Der Browser behält seine einminütige Abfrage-Neuheitsperiode bei. Er befragt den lokalen Snapshot-Endpunkt nur einmal pro Sekunde, während eine Aktualisierung aktiv ist, die nach Abschluss anhält oder ein Netzwerkfehler auftritt. Die Seite befragt den Anbieter nicht regelmäßig im Leerlauf. Anteilszuweisungen Verwenden Sie konfigurierte Token oder interne USD Zeitstempel und Antwortserver sind getrennt, so dass ein wiederhergestellter Snapshot den Countdown nicht neu startet. Deaktivierte Konten werden nicht abgefragt. Modellverkehr erwärmt auch den gemeinsamen Quoten-Cache ohne zu warten. Neue Hauptlimit-Erschöpfung schließt ein Konto von der neuen Auswahl aus; gebundene Gespräche geben eine quotenspezifische Ablehnung zurück. Upstream-Nutzungsgrenzen beschreiben das Abonnement, nicht die Nutzungskontingent eines Mitglieds. quotenbewusste Auswahl.

Reset-Karten

Workspace-Administratoren können Karten aktivierter Codex-Konten anzeigen und verwenden, wenn keine erneute Autorisierung nötig ist. Mitglieder können sie nicht verwalten. Zeitgesteuerte Nutzung und Nutzung bei erschöpftem Kontingent sind standardmäßig aus. Anzeigen und Aktualisieren der Liste verbrauchen keine Karte.

Einrichten und verwenden

1. Öffnen Sie Konten und die Reset-Karten-Einstellungen auf der Codex-Kontokarte. Prüfen Sie Liste, verfügbare Anzahl und Beobachtungszeit. Eine unbekannte Anzahl ist nicht null.
2. Aktivieren Sie zeitgesteuerte Nutzung, Nutzung bei Erschöpfung oder beides. Einmalige Ausführung benötigt Datum und Uhrzeit in der Zukunft, tägliche eine Uhrzeit, wöchentliche Wochentag und Uhrzeit. Prüfen Sie die angezeigte Instanzzeitzone.
3. Speichern Sie das gemeinsame Tageslimit (1–100, Standard 1). Prüfen Sie die Bestätigung und bei Zeitplänen die nächste Ausführung.
4. Speichern Sie vor manueller Nutzung alle Änderungen und wählen Sie die sofortige Nutzung einer Karte. Jeder Versuch verwendet höchstens eine Karte. Das Ergebnis steht im Verlauf; allein das Öffnen der Einstellungen löst keine Einlösung aus.

Liste und Ablaufpriorität

Die Liste zeigt Titel, Status, Vergabezeit und Ablauf. Sie unterscheidet verfügbar, in Einlösung, eingelöst, abgelaufen, unbekannt und nicht unterstützt; rohe Karten-IDs werden nicht angezeigt. Die Markierung der nächsten Karte beschreibt die automatische Auswahl. Es gibt keine manuelle Kartenauswahl; bei offenem Ergebnis wird die Markierung ausgeblendet. Eine positive Anzahl garantiert keine geeignete Karte.

Jeder neue manuelle, geplante oder durch Erschöpfung ausgelöste Versuch liest den Bestand erneut und gibt credit_id ausdrücklich an. Nur verfügbare, unterstützte, nicht abgelaufene Karten kommen infrage. Das früheste Ablaufdatum hat Vorrang, Karten ohne Ablauf kommen zuletzt. Bei gleichem Ablauf entscheidet die ältere Vergabe, danach eine stabile ID-Reihenfolge. Ohne geeignete Karte oder bestätigten Bestand wird übersprungen, ohne die Auswahl dem Anbieter zu überlassen. Anfänglicher Ladefehler und leere Liste sind verschiedene Zustände. Scheitert eine Aktualisierung, bleiben die vorherige Liste und eine Warnung sichtbar; aktualisieren Sie erneut.

Zeitpläne und Grenzen

Erschöpfung wird etwa jede Minute im Hintergrund geprüft. Erforderlich sind aktuelle Kontingentdaten, eine bekannte positive Kartenanzahl und eine ausdrückliche Ablehnung des Hauptkontingents. 100 %, unbekannte Daten oder Netzwerkfehler allein lösen nichts aus. Manuelle und geplante Nutzung benötigen ebenfalls aktuelle Daten und eine bekannte positive Anzahl.

Alle Modi teilen das Tageslimit nach dem lokalen Datum der Instanz; erfolgreiche und offene Versuche belegen Plätze. Deaktivierte oder erneut zu autorisierende Konten werden übersprungen. Mehr als fünf Minuten verpasste Termine werden nicht nachgeholt. Durch Sommerzeit fehlende Uhrzeiten werden übersprungen, doppelte Stunden ergeben eine Ausführung pro lokalem Datum. Eine andere Zeitzone berechnet zukünftige Termine neu. Das Schließen des Browsers beendet keine Hintergrundaufgaben. Die Demo erlaubt weder Automatisierung noch Einlösung.

Ergebnisse und Wiederherstellung

Der Anbieter bestimmt Berechtigung und zurückgesetzte Zeitfenster. Die Einlösung verwendet POST /backend-api/wham/rate-limit-reset-credits/consume; erkannte Ergebnisse sind reset, already_redeemed, nothing_to_reset und no_credit. Erfolg aktualisiert Kontingent und Kartenanzahl, entfernt aber keine anderen Gateway-Grenzen und garantiert nicht die Aufhebung aller Einschränkungen.

Vor dem Senden werden redeem_request_id und ausgewählte Karten-ID gespeichert. Zeitüberschreitungen oder unbekannte Antworten bleiben offen. Eine Prüfung wiederholt beide Werte auch bei geändertem Bestand oder Ablauf; eine andere Anzahl beweist keinen Erfolg. Alte offene Anfragen behalten das ursprüngliche Weglassen von credit_id bei. Nach einem endgültigen Ergebnis wird die ausgewählte ID gelöscht; Kontingent-Snapshots, öffentliche Ausführungsdaten und Audit-Ausgaben enthalten sie nicht. Anmeldedaten, rohe Antworten und Anbieterprofile werden nicht aufgezeichnet. Kontolöschung entfernt Einstellungen und Verlauf.

Administrator-APIs im Browser: GET /api/accounts/{id}/resets für Einstellungen und Verlauf, GET /api/accounts/{id}/resets/cards für normalisierte Metadaten, PUT /api/accounts/{id}/resets zum Speichern und POST /api/accounts/{id}/resets/consume oder POST /api/accounts/{id}/resets/retry zum Nutzen oder Prüfen. Browser-Sitzung und Workspace-Rollen sind nötig; Gateway-Schlüssel gewähren keinen Zugriff. Abfragen verwenden bestehende Prüfungen für Zugangsdaten, Proxy und Kontolebenszyklus und schließen Profilkennungen, Avatar-URLs und rohe Antworten aus. Der interne Vertrag kann sich ändern; synthetische Tests bestätigen keine echte Berechtigung oder erfolgreiche reale Einlösung.

Änderungen und erfolgreiche manuelle Nutzung werden auditiert; automatische Ergebnisse bleiben im begrenzten Ausführungsverlauf.

Aufbewahrung und Aktualisierung von Berechtigungsnachweisen

Das konsolidierte Schema erstellt Workspace-scoped Abonnement-Konten und begrenzte Account-Affinitäts-Datensätze. Zugriff, Aktualisierung und ID-Token werden mit AES-256-GCM und kontogebundenen authentifizierten Daten verschlüsselt. Die Instanz erstellt ein privates 32-Byte credentials.key Datei neben der Datenbank. Der Schlüssel ist kein Setup-Passwort und erfordert keine manuelle Eingabe.

Sichern Sie die Datenbank und credentials.key Eine vorhandene Kontodatenbank beginnt nicht mit einem fehlenden, ungültigen oder nicht übereinstimmenden Schlüssel. Ersetzen Sie den Schlüssel nicht, um den Zugriff wiederherzustellen. Die Verschlüsselung schützt Anmeldeinformationen in einer reinen Datenbankkopie; der Zugriff sowohl auf die Datenbank als auch auf den Schlüssel ermöglicht die Entschlüsselung.

SubLane Es ist der einzige Aktualisierungsbesitzer. Es serialisiert die Aktualisierung von Anmeldeinformationen mit Administratoränderungen und besteht aus gedrehten Token, bevor sie für Anfragen veröffentlicht werden. Tokens, die kurz vor dem Ablauf der Aktualisierung vor der Verwendung sind. Ein vorgeschalteter 401 erlaubt eine Aktualisierung und eine Wiederholung auf demselben Konto; gleichzeitige Ablehnungen eines alten Tokens verwenden die bereits aktualisierten Anmeldeinformationen wieder. Ältere Ergebnisse während des Fluges können eine spätere Aktualisierung oder erneute Autorisierung nicht ungültig machen.

Gateway-Vertrag

Alle Gateway-Routen erfordern eine SubLane Bearer Key, unabhängig von Browser-Cookies:

HTTP Die Anfragen müssen vollständige Eingaben enthalten. HTTP previous_response_id wird abgelehnt, anstatt stillschweigend den Kontext zu verlieren, weil Codex HTTP Backend ist Stateless. WebSocket Continuations verwenden eine begrenzte, verbindungslokale Historie; unbekannte Continuation IDs erfordern eine vollständige Transkripteingabe. WebSocket turn überprüft die Schlüssel- und Member-Enablement-Funktion neu.Ein widerrufener Schlüssel kann eine neue Runde bei einer bestehenden Verbindung nicht starten.

Die Affinität des Kontos wird auf die Sitzung des Mitglieds, des Pools und des Clients/Prompt-Cache-Schlüssels beschränkt, wird 24 Stunden lang beibehalten und ist auf 4.096 Bindungen begrenzt. Native Requests verwenden eine Bindung zwischen Anbietern; explizite Legacy-Präfix-Anforderungen behalten anbieterspezifische Bindungen. Neue Sitzungen verteilen sich auf berechtigte Konten, die das gewünschte Modell innerhalb ihres Pools melden, wobei die Konkurrenz und die Abklingzeit des jeweiligen Kontos respektiert werden. Sessionless Requests werden unabhängig voneinander ausgewählt, ohne Affinität zu erzeugen. Bestehende Sitzungen scheitern, wenn ihr Konto deaktiviert oder entfernt wird, anstatt die vorgelagerte Identität zu wechseln. Für eine absichtliche Änderung des Modells kann ein vollständiger tragbarer Verlauf ein unterstützendes Konto auswählen, wenn das ursprüngliche Konto das neue Modell nicht bedienen kann; Anbieterfortsetzungen bleiben festgeschrieben. Modell-Routing. Starten Sie die Konversation nach anderen absichtlichen Kontoänderungen neu. Wenn Sie eine Anforderung erneut wiederholen, wird sie niemals automatisch in ein anderes Konto verschoben.

Pro Arbeitsbereich gelten standardmäßig 128 Vorgänge einschließlich wartender Anfragen und geteilter Metadatenarbeit, acht WebSocket-Verbindungen, 30 Minuten pro Anfrage oder Runde und fünf Minuten für Inferenz-Antwortheader. Anfragen und rekonstruierter Kontext sind auf 128 MiB begrenzt, Antworten und Ereignisse auf je 8 MiB. Körperlesevorgänge dauern höchstens 30 Sekunden, geteilte Modellerkennung höchstens 45 Sekunden. Dies sind Ressourcengrenzen, keine Leistungszusagen. Siehe Bereitstellung und Gruppenbetrieb. Mitgliedslimits: Teamverwaltung.

Provider-Anmeldeinformationen, Browser-Cookies, beliebige Client-Header und rohe Provider-Fehlerstellen werden nicht an Mitglieder weitergeleitet. Client-Trägerschlüssel werden durch die ausgewählten Upstream-Anmeldeinformationen ersetzt. Die Anwendung protokolliert keine Eingabeaufforderungen, Antworten, Zugriffstokens, Refresh-Tokens oder OAuth Callback URLs.

Prüfgrenze

Automatisierte Tests verwenden temporäre Datenbanken, synthetische Anmeldeinformationen und lokale gefälschte Upstreams. OAuth Eigentum/Verfall/Wiederholung, Verschlüsselung und Schlüsselinkongruenz, Aktualisierungsserialisierung, unveränderliche Identität, Kontoaffinität, Rollen-/Eigentumsisolierung, Streaming-Abbruch; SSE Reparatur von Fertigstellungen und WebSocket Widerruf zwischen den Turns.

Ein Opt-in-Integrationstest führt eine installierte Codex CLI mit einem frischen Kind-Prozess zu Hause, keine geerbten Anmeldeinformationen und eine lokale synthetische Modellantwort:

SUBLANE_TEST_CODEX=1 go test ./internal/server -run TestCodexCLIProtocol -count=1 -v

Codex CLI 0.152.1 bestanden beide HTTP/SSE und WebSocket Tatsächliche Abonnementberechtigung und Live-Modellanforderungen erfordern einen ausdrücklich autorisierten Testaccount. Die reale Desktop-Anwendung wurde noch nicht validiert; gemeinsame Konfigurations- und Protokolltests allein stellen keine Live-Desktop-Kompatibilität her.

Vor dem v7-Upgrade hat eine lokale macOS-arm64-Vorschau (CLIProxyAPI v6.10.9, Go 1.26.0, Produktionsbinär, ein verschlüsseltes synthetisches Konto) 23.376 KiB RSS, ungefähr 22.8 MiB, nach etwa zwölf Minuten im Leerlauf am 2026-09-19 gemessen. Dies ist nur eine Leerlaufbeobachtung; reale Modelle, Parallelität, Nutzlastgröße und Nutzung des Plattformwechselspeichers. Docker Compose lokal validierte Konfiguration, aber die Docker Daemon war für einen lokalen Image Build nicht verfügbar.

Ausführungsnummer

SubLane nutzt die öffentlichen Vollstrecker und Übersetzer von CLIProxyAPI v8.0.35 internal/upstream. SubLane besitzt Autorisierung, verschlüsselte Berechtigungsspeicherung, Aktualisierung, Kontoauswahl und das öffentliche Gateway. SDK Läuft als privates vollstreckerregister ohne live-anmeldeinformationen, einen no-op-beobachter, blockierte loopback-routen und automatische aktualisierung deaktiviert. Architektur für die Ausführungsgrenze und Provider Setup für Schritten der Provider-Verbindung: Die Genehmigungs- und Kontingentdetails dieses Leitfadens beschreiben Codex.