Codex abonnements et passerelle

Avec une clé personnelle prête, configurez votre client ci-dessous. Si vous n'en avez pas, remplissez Première demande ou demandez à votre administrateur de vous connecter.

Configuration du client

Créer une personnalité API clé dans Clés API. Utilisez l'origine de l'instance plus /v1 comme URL de base. Configurer un ID de modèle retourné par GET /v1/models.

Jeu SUBLANE_API_KEY dans l'environnement du processus client. Fusionner les paramètres suivants dans le niveau utilisateur ~/.codex/config.toml, en remplaçant les valeurs correspondantes existantes:

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

Utilisez l'URL réelle de votre instance, avec HTTPS pour les déploiements de réseau. HTTP/SSE transport, ensemble supports_websockets = false. Codex Une application de bureau déjà en cours d'exécution n'hérite pas automatiquement des variables d'environnement exportées dans un autre terminal; redémarrez-la dans un environnement où la clé est disponible.

Les API la page clés fournit un extrait de configuration sans intégrer ou conserver le secret. Il offre également une option CC Switch Importation qui passe la clé choisie à l'application installée localement après une préparation explicite. CC Switch génère ses propres Codex configuration du fichier d'authentification; il ne préserve pas la variable d'environnement ou WebSocket paramètres dans l'extrait de manuel ci-dessus. Voir le officiel configuration avancée et authentification des conseils pour la configuration du client et le stockage des justificatifs.

Les catalogues de comptes sont mis en cache et survivent aux redémarrages. catalogues de modèles.

Après la configuration : envoyer un message et vérifier la réponse, puis continuer avec Utilisation quotidienne. Les détails du compte, du contingent et du protocole ci-dessous sont des références pour plus tard.

Ajouter un compte

Se connecter en tant qu'administrateur, ouvrir Comptes, et choisir Ajouter un compte. Les membres ne peuvent pas accéder aux paramètres de gestion d'abonnement ou aux identifiants.

• Autorisation du navigateur & #160;: nom du compte, l'autorisation de démarrage, et ouvrir le OpenAI lien. Après la signature, copiez le complet http://localhost:1455/auth/callback?... adresse de la barre d'adresse du navigateur et le coller dans SubLane. Une erreur de connexion locale est attendue à ce stade: SubLane intentionnellement n'ouvre pas un autre auditeur callback. Ce flux de retour manuel fonctionne pour les déploiements locaux et à distance.
• Importation auth.json: choisir un Codex par abonnement, ou par collage de son JSON. Les deux CLI sont nichés tokens la structure et l'appartement Codex format jeton sont acceptés. API les clés sont rejetées. SubLane ne scanne jamais les répertoires clients locaux ; il ne lit que le contenu explicitement soumis par l'administrateur. Les paramètres de paramètre/proxy importés sont rejetés.

L'autorisation de compte/importation commence automatiquement la découverte du modèle. Vérifier la connexion pour actualiser et maintenir le catalogue modèle du compte, ou ouvrir Modèles pour l'inspecter. Imported identifications montrer Non vérifié jusqu'à une utilisation réussie. Le menu compte fournit activer/désactiver, réautoriser et supprimer. La réautorisation doit conserver la même identité de compte en amont. SubLane; il ne révoque pas la connexion ChatGPT elle-même.

Codex model discovery envoie la version client efficace de l'instance dans la requête catalogue et les en-têtes de requête. Administration → Paramètres du système: une version explicite prend la priorité sur la dernière version officielle synchronisée stable, avec 0.155.1 comme le repli intégré. La version automatique vérifie par défaut toutes les six heures. Codex ou la mise à jour de l'intégré SDK; voir paramètres du système.

Le catalogue en amont dépend de cette version : une version obsolète peut retourner HTTP 200 avec seulement des modèles cachés ou un catalogue partiellement visible, produisant un vide ou incomplet /v1/models liste après filtrage de la visibilité. Catalogues Persisted incluent la version de découverte réelle, donc changer les déclencheurs de version effective rafraîchir sur la prochaine demande de lecture ou de modèle de catalogue même lorsque leurs horodatages restent frais.

OAuth tentatives d'utilisation PKCE, 256-bit état aléatoire, une expiration de dix minutes, une tentative active par session de navigateur administrateur, et un maximum de huit tentatives en attente. Le callback est lié à la session qui l'a commencé et consommé avant d'échanger son code. OAuth l'état n'est tenu qu'en mémoire.

Utilisation de l'abonnement

La page des comptes affiche les fenêtres de quota, le pourcentage restant, le décompte et l’heure d’observation des comptes Codex activés, ainsi que les limites supplémentaires signalées. Le nombre de cartes est séparé : inconnu et zéro explicite sont distincts. Voir Cartes de réinitialisation pour la liste et l’utilisation facultative. Les champs absents restent inconnus ; un échec conserve l’ancien instantané avec avertissement. L’heure de réinitialisation ne prouve pas le rétablissement : actualisez l’utilisation.

L'adaptateur d'utilisation lit https://chatgpt.com/backend-api/wham/usage et les https://chatgpt.com/backend-api/wham/rate-limit-reset-credits en fin de compte, correspondant au fonctionnaire Codex client moteur. Les deux demandes utilisent le justificatif de compte sélectionné, le propriétaire de la mise à jour/réessayer, l'entrée de passerelle limitée, une date limite partagée de 20 secondes et une limite de 128 KiB par réponse. Si la demande de détail de la carte de réinitialisation échoue ou omet un nombre, le quota reste disponible et tout nombre valide de la réponse d'utilisation est conservé. Seuls les champs de quota normalisés et le nombre sont retournés; les métadonnées brutes en amont, les identifiants de carte et les identifiants sont exclus. SubLane.

Le schéma consolidé stocke un quota limité, normalisé et un instantané de réinitialisation par compte dans SQLite. Les snapshots incluent la dernière période d'observation réussie et survivre redémarrages de processus; la suppression d'une cascade de compte à son snapshot. Le processus conserve au plus 100 entrées de snapshot dans la mémoire et les recharge paresseusement de SQLite. Aucune identification ou réponse brute du fournisseur ne sont stockées dans ce tableau.

GET /api/accounts/{id}/usage retourne un instantané neuf pendant jusqu'à deux minutes (ou jusqu'à ce qu'une réinitialisation à venir rapportée, si plus tôt). stale et refreshing flags pendant qu'un fond de rafraîchissement s'exécute. Une première récupération sans instantané attend le résultat. POST /api/accounts/{id}/usage/refresh contourne la fraîcheur et attend le rafraîchissement partagé, tout en honorant un refroidissement de cinq secondes. Les deux itinéraires nécessitent une session d'administrateur activée; POST exige également l'origine existante/JSON des vérifications.

Les appelants concomitants pour le même compte partagent une opération en amont. Rafraîchit l'utilisation de la capacité configurée de l’espace de travail (128 par défaut, via SUBLANE_GATEWAY_CAPACITY) et d'une date limite globale de 45 secondes, survivent à une déconnexion individuelle du navigateur et sont annulés/attendus pendant l'arrêt du processus. Un rafraîchissement échoué préserve les valeurs et l'horodatage précédents, les marque en suspens et recule pendant 30 secondes (ou une période plus longue valide en amont Retry-After, jusqu'à une heure).

Le navigateur conserve sa période de fraîcheur de requête d'une minute. Il ne consulte le paramètre instantané local qu'une fois par seconde pendant qu'un rafraîchissement est actif, s'arrête à la fin ou une erreur réseau. La page ne sondage pas périodiquement le fournisseur pendant qu'il est inactif. Répartition des parts utiliser un jeton configuré ou interne USD Les comptes désactivés ne sont pas interrogés. Le trafic modèle réchauffe également le cache de quota partagé sans attendre. L'épuisement de la limite principale ne tient pas compte d'une nouvelle sélection; les conversations liées renvoient un rejet spécifique de quota. Les limites d'utilisation en amont décrivent l'abonnement, et non l'allocation d’usage d'un membre. Voir sélection des quotas-concepteurs.

Cartes de réinitialisation

Les administrateurs de l’espace de travail peuvent consulter et utiliser les cartes des comptes Codex activés ne nécessitant pas de nouvelle autorisation. Les membres ne peuvent pas les gérer. L’utilisation programmée et celle à épuisement du quota sont désactivées par défaut. Consulter ou actualiser la liste ne consomme aucune carte.

Configuration et utilisation

1. Ouvrez Comptes, puis les paramètres des cartes sur la fiche du compte Codex. Vérifiez la liste, le nombre disponible et l’heure d’observation. Un nombre inconnu ne signifie pas zéro.
2. Activez la programmation, l’utilisation à épuisement du quota ou les deux. Choisissez une date et une heure futures pour une exécution unique, une heure pour chaque jour, ou un jour et une heure pour chaque semaine. Vérifiez le fuseau horaire de l’instance affiché.
3. Enregistrez le plafond quotidien commun (1 à 100, 1 par défaut). Vérifiez la confirmation et, si la programmation est active, la prochaine exécution.
4. Pour utiliser une carte immédiatement, enregistrez d’abord les modifications puis choisissez cette action. Chaque tentative utilise au maximum une carte. Consultez le résultat dans l’historique ; ouvrir les paramètres ne lance aucun échange.

Liste et priorité d’expiration

La liste affiche le nom, l’état, la date d’attribution et l’expiration. Elle distingue les cartes disponibles, en cours d’échange, utilisées, expirées, inconnues et non prises en charge, sans afficher les identifiants bruts. La marque de prochaine carte décrit la sélection automatique ; aucun choix manuel n’est proposé et la marque est masquée lorsqu’un résultat reste en attente. Un nombre positif ne garantit pas de carte admissible.

Chaque nouvelle tentative manuelle, programmée ou à épuisement relit l’inventaire et précise credit_id. Seules les cartes disponibles, compatibles et non expirées sont admissibles. L’expiration la plus proche est prioritaire ; les cartes sans expiration passent en dernier. Les égalités sont départagées par attribution la plus ancienne, puis par ordre stable d’identifiant. Sans carte admissible ou inventaire confirmé, l’échange est ignoré, sans sélection implicite du fournisseur. Un échec initial est distinct d’une liste vide. Une actualisation échouée conserve la liste précédente avec un avertissement ; relancez l’actualisation des cartes.

Programmation et limites

L’épuisement est vérifié en arrière-plan environ chaque minute. Il faut des données récentes, un nombre de cartes connu et positif et un refus explicite du quota principal. Un affichage à 100 %, des données inconnues ou une erreur réseau ne suffisent pas. Les tentatives manuelles et programmées exigent aussi des données récentes et un nombre connu et positif.

Tous les modes partagent le plafond quotidien selon la date locale de l’instance ; les tentatives réussies et en attente réservent des places. Les comptes désactivés ou à réautoriser sont ignorés. Les exécutions manquées de plus de cinq minutes ne sont pas rattrapées. Les heures inexistantes au changement d’heure sont ignorées ; une heure répétée produit une seule occurrence par date locale. Changer de fuseau recalcule les futures exécutions. Fermer le navigateur n’arrête pas les tâches. La démo interdit l’automatisation et les échanges.

Résultats et récupération

Le fournisseur détermine l’admissibilité et les fenêtres réinitialisées. L’échange utilise POST /backend-api/wham/rate-limit-reset-credits/consume, avec les résultats reconnus reset, already_redeemed, nothing_to_reset et no_credit. Un succès actualise quota et nombre de cartes sans lever les autres limites de la passerelle ni garantir leur suppression complète.

Avant l’envoi, redeem_request_id et l’identifiant sélectionné sont persistés. Un délai dépassé ou une réponse inconnue laisse le résultat en attente. La vérification renvoie les deux mêmes valeurs même si inventaire ou expiration changent ; une variation du nombre ne prouve pas le succès. Les anciennes requêtes en attente conservent l’omission initiale de credit_id. L’identifiant sélectionné est effacé après un résultat définitif et exclu des instantanés de quota, historiques publics et sorties d’audit. Aucun identifiant de connexion, réponse brute ou profil du fournisseur n’est enregistré. Supprimer le compte supprime paramètres et historique.

Les API navigateur administrateur sont GET /api/accounts/{id}/resets (paramètres et historique), GET /api/accounts/{id}/resets/cards (liste normalisée), PUT /api/accounts/{id}/resets (enregistrement) et POST /api/accounts/{id}/resets/consume ou POST /api/accounts/{id}/resets/retry (utilisation ou confirmation). Elles exigent une session navigateur et les rôles de l’espace ; les clés de passerelle ne les autorisent pas. La lecture réutilise les contrôles des identifiants, du proxy et du cycle de vie, en excluant identifiants de profil, URL d’avatar et réponses brutes. Le contrat interne peut évoluer ; les tests synthétiques ne valident ni l’admissibilité réelle ni un échange en production.

Les changements et utilisations manuelles réussies sont audités ; les résultats automatiques restent dans un historique borné.

Stockage et mise à jour des titres de créance

Le schéma consolidé crée des comptes d'abonnement à l'espace de travail et des enregistrements d'affinité de compte délimités. Les jetons d'accès, de mise à jour et d'identification sont cryptés avec des données authentifiées AES-256-GCM et liées à un compte. credentials.key fichier à côté de sa base de données. La clé n'est pas un mot de passe d'installation et ne nécessite aucune entrée manuelle.

Sauvegarder la base de données et credentials.key Une base de données de compte existante ne commence pas avec une clé manquante, invalide ou mal jumelée. Ne remplacez pas la clé pour récupérer l'accès. Le chiffrement protège le contenu des justificatifs dans une copie de base de données seulement; l'accès à la fois à la base de données et à la clé permet le déchiffrement.

SubLane Il sérialise le rafraîchissement des titres de compétence avec les modifications de l'administrateur et persiste à tourner les jetons avant de les publier sur les requêtes. Les jetons sont presque rafraîchissants avant l'utilisation. Un 401 en amont permet un rafraîchissement et un réessayer sur le même compte; les refus simultanés d'un vieux jeton réutiliser le rafraîchissement des titres de compétence déjà rafraîchis.

Contrat de passerelle

Toutes les routes de passerelle nécessitent une SubLane clé au porteur, indépendamment des cookies du navigateur:

HTTP Les demandes doivent comprendre des commentaires complets. HTTP previous_response_id est rejeté au lieu de perdre silencieusement le contexte parce que Codex HTTP Le moteur est apatride. WebSocket les continuations utilisent l'historique local-connection délimité; les ID de continuation inconnus nécessitent une transcription complète. WebSocket tour revérifie l'activation de la clé et du membre. Une clé révoquée ne peut pas démarrer un nouveau tour sur une connexion existante.

L'affinité du compte est étendue au membre, au pool et à la clé de session/cache de client, conservée pendant 24 heures d'activité, et limitée à 4 096 liaisons. Les demandes autochtones utilisent une liaison entre fournisseurs; les demandes de préfixe de legs explicites conservent des liaisons spécifiques au fournisseur. Les nouvelles sessions distribuent sur les comptes admissibles des rapports sur le modèle demandé dans leur pool, en respectant la concordance et le refroidissement par compte. Les demandes sans session sélectionnent indépendamment sans créer d'affinité. Les sessions existantes échouent lorsque leur compte est désactivé ou supprimé au lieu de changer d'identité en amont. routage du modèle. Recommencer la conversation après d'autres changements intentionnels de compte. Reessayer une requête ne la déplace jamais automatiquement sur un autre compte.

Chaque espace de travail dispose par défaut de 128 opérations, attentes et métadonnées partagées comprises, de huit connexions WebSocket, d’un délai total de 30 minutes par requête ou tour et de cinq minutes pour les en-têtes d’inférence. Requêtes et contexte reconstruit sont limités à 128 MiB ; réponses et événements, à 8 MiB chacun. La lecture du corps est limitée à 30 secondes et la découverte partagée à 45 secondes. Ce sont des limites de ressources, pas des garanties de performance. Voir déploiement et fonctionnement des groupes. Limites des membres : gestion de l’équipe.

Les identifiants du fournisseur, les cookies de navigateur, les en-têtes arbitraires du client et les corps d'erreur bruts du fournisseur ne sont pas transmis aux membres. Les clés du porteur du client sont remplacées par le justificatif en amont sélectionné. OAuth URLs de rappel.

Limite de vérification

Les tests automatisés utilisent des bases de données temporaires, des références synthétiques et des données locales de faux en amont. OAuth propriété/expiration/rejouement, cryptage et inadéquation des clés, mise à jour de la sérialisation, identité immuable, affinité de compte, isolation du rôle/propriété, annulation en continu, SSE réparation complète, et WebSocket La révocation entre deux tours.

Un test d'intégration opt-in exécute un installé Codex CLI avec un nouveau foyer pour enfants, pas de références héritées, et une réponse de modèle synthétique locale:

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

Codex CLI 0.152.1 passé les deux HTTP/SSE et WebSocket Les demandes d'autorisation d'abonnement et les demandes de modèle en direct nécessitent un compte de test explicitement autorisé. L'application de bureau réel n'a pas encore été validée; les tests de configuration et de protocole partagés à eux seuls n'établissent pas la compatibilité de bureau en direct.

Avant la mise à niveau v7, un aperçu local macOS arm64 (CLIProxyAPI v6.10.9, Go 1.26.0, binaire de production, un compte synthétique chiffré) mesurait 23 376 KiB RSS, environ 22,8 Mio, après environ douze minutes au ralenti sur 2026-09-19. Il s'agit d'une observation au ralenti seulement; des modèles réels, de la convergence, de la taille de la charge utile, et de l'utilisation de la mémoire de changement de plate-forme. Docker Compose la configuration validée localement, mais Docker démon n'était pas disponible pour une construction d'image locale.

Référence d'exécution

SubLane utilise CLIProxyAPI v8.0.35.35s les exécuteurs et traducteurs publics derrière internal/upstream. SubLane possède l'autorisation, le stockage crypté des justificatifs, la mise à jour, la sélection des comptes et la passerelle publique. SDK fonctionne comme un registre d'exécuteur privé sans identifiants en direct, un watcher non-op, des itinéraires de boucle bloqués, et de rafraîchissement automatique désactivé. Voir architecture pour la limite d'exécution et configuration du fournisseur pour les étapes de connexion du fournisseur. Ce guide décrit l'autorisation et les détails de quota Codex.