OpenAI Codex via un abonnement ChatGPT

Exécute un agent sur le slot openai, facturé via un abonnement ChatGPT plutôt que par la facturation à l’usage avec OPENAI_API_KEY. L’agent est un modèle GPT-5.x Codex qui pilote les outils de ZeroClaw, authentifié par votre connexion Codex plutôt que par une clé API. La facturation suit votre forfait ChatGPT : l’usage inclus dans votre abonnement est consommé en premier, et l’usage Codex au-delà de cette allocation incluse puise dans les crédits flexibles de votre compte aux tarifs par token et par modèle d’OpenAI. Ce n’est pas un parcours forfaitaire à $0 par appel une fois l’allocation incluse dépassée.

Cette page couvre la configuration des slots, les chaînes de modèles servis, les implications en matière de coût et de routage, ainsi que le câblage OAuth. Pour les champs de fournisseur universels, consultez Configuration ; pour l’entrée de catalogue en une ligne, consultez le Catalogue des fournisseurs.

Config

L’authentification d’abonnement Codex se trouve sur le slot openai. Définissez wire_api = "responses" pour acheminer les requêtes via POST /v1/responses (le backend Codex, et non l’API de complétions de chat) et requires_openai_auth = true pour récupérer les identifiants depuis le profil d’authentification openai-codex stocké dans ZeroClaw, au lieu d’un champ api_key :

# Réutiliser une connexion Codex CLI existante :
zeroclaw auth login --model-provider openai-codex --import ~/.codex/auth.json

# Ou lancer le flux de connexion OpenAI Codex propre à ZeroClaw :
zeroclaw auth login --model-provider openai-codex

Le démarrage rapide peut écrire l’entrée du fournisseur pour vous :

zeroclaw quickstart --model-provider openai-codex --model gpt-5.4

La configuration manuelle utilise le même emplacement canonique OpenAI :

[providers.models.openai.coding]
model                = "gpt-5.4"
wire_api             = "responses"
requires_openai_auth = true

[providers.models.openai.review]
model                = "codex-auto-review"
wire_api             = "responses"
requires_openai_auth = true

Il n’y a pas de champ api_key ; requires_openai_auth = true est le commutateur qui lit l’identifiant de connexion Codex stocké plutôt qu’une clé sur l’entrée. Voir Configuration → OAuth and subscription auth.

La partie alias (coding, review) est choisie par l’opérateur ; choisissez celle qui convient. Référencez-la depuis un agent avec model_provider = "openai.coding".

Modèles

L’API wire responses interroge directement le backend Codex, donc la valeur de model doit être un ID servi exact : les alias côté client de la CLI Codex (gpt-5, gpt-5.3, instant, gpt-5.5-instant) ne sont pas résolus ici et échouent avec une erreur 400.

Considérez le catalogue fourni comme volatile. Interrogez-le plutôt que de vous fier à une liste codée en dur, y compris celle-ci :

# Les noms de champs correspondent au fichier ~/.codex/auth.json actif (vérifiez avec le fichier lui-même ;
# the layout has shifted across Codex versions).
AT=$(jq -r .tokens.access_token ~/.codex/auth.json)
# account_id est FACULTATIF dans auth.json ; ZeroClaw se rabat sur le JWT OAuth lorsque
# it is absent. `// empty` keeps jq from emitting the literal string null, and
# l'en-tête n'est envoyé que lorsque le champ est réellement présent. Après un import, vous
# can also read the resolved id from `zeroclaw auth status`.
ACC=$(jq -r '.tokens.account_id // empty' ~/.codex/auth.json)
curl -s https://chatgpt.com/backend-api/codex/models?client_version=1.0.0 \
  -H "Authorization: Bearer ${AT}" \
  ${ACC:+-H "chatgpt-account-id: ${ACC}"} \
  -H "originator: pi" | jq -r '.models[].slug'

client_version est requis et soumis à une restriction : une valeur obsolète ou trop basse renvoie un {"models": []} vide sans erreur. Utilisez une version client à jour (par exemple 1.0.0) si la liste revient vide.

Catalogue fourni (2026-06-02 ; vérifiez avant de figer la version par rapport au point de terminaison) :

GPT-5.5 Instant et GPT-5.3 sont des modèles ChatGPT-app, un espace de noms différent qui n’est pas pris en charge par le backend Codex, ils ne sont donc pas utilisables depuis cet emplacement.

Pour éviter de modifier la configuration à chaque montée de version de modèle, résolvez les rôles vers les ID actuellement servis de manière dynamique (énumérez codex/models, choisissez la correspondance la plus récente par rôle) plutôt que d’épingler une version.

Coût et routage

Comment OpenAI facture cette utilisation (consultez la documentation actuelle de facturation des forfaits Codex / ChatGPT d’OpenAI, qui prévaut sur tout chiffre indiqué ici) :

1. Utilisation incluse dans le forfait en priorité. Chaque forfait ChatGPT inclut un quota d’utilisation Codex qui se renouvelle sur une fenêtre glissante. Tant que vous restez dans cette limite, les requêtes Codex n’entraînent aucuns frais supplémentaires.
2. Crédits flexibles après l’allocation incluse. Une fois l’utilisation incluse épuisée, l’utilisation de Codex puise dans le solde de crédits de votre compte lorsque le forfait le permet. Les entrées, les entrées mises en cache et les sorties sont facturées en crédits par 1M de tokens, de sorte que la consommation d’une tâche dépend de sa répartition de tokens et du modèle utilisé.
3. Options en cas de dépassement. Lorsque le quota inclus et les crédits éventuels sont épuisés, OpenAI propose d’ajouter des crédits, de passer à un forfait supérieur ou d’attendre la réinitialisation de la fenêtre.

Les niveaux de forfait ci-dessous sont donc des multiplicateurs de quota d’utilisation, et non une garantie de coût nul par appel.

Suivi des coûts ZeroClaw

ZeroClaw enregistre cet emplacement à $0 par appel. Il s’agit d’une limitation de comptabilité locale, et non d’un fait de facturation OpenAI : ZeroClaw ne peut pas voir le compteur d’utilisation incluse de votre forfait ChatGPT ni votre solde de crédit, il ne peut donc pas attribuer le coût en jetons par appel à une requête d’abonnement. Interprétez le $0 comme « non comptabilisé par ZeroClaw », et surveillez l’état réel de votre allocation / crédit dans votre compte OpenAI. Gardez les classes abonnement et comptabilisées (api-key) séparées dans la comptabilité ; voir Suivi des coûts.

Le routage consiste donc à dépenser délibérément l’allocation incluse et à conserver une solution de repli pour les moments où vous l’avez dépassée, à la fois pour éviter de consommer des crédits aux tarifs des tokens par modèle et pour survivre à un arrêt brutal. Ce n’est pas « gratuit par token » une fois que vous êtes en dehors de l’utilisation incluse.

Le routage se fait par agent (voir Routing) : définissez un alias d’agent par rôle, chacun pointant vers une entrée Codex openai, et dirigez les canaux vers l’agent qui doit gérer leur trafic.

Conservez un secours facturé à l’usage pour les cas où l’abonnement ne peut pas répondre : quota épuisé (429), rafraîchissement du token en backoff (voir ci-dessous) ou chaîne de modèle indisponible. Le secours s’applique par token, il doit donc rester l’exception. Les fournisseurs faisant partie de cet ensemble de secours dépendent de l’environnement ; configurez-les dans votre propre routage, pas ici.

Niveaux d’abonnement et limites

Niveaux ChatGPT pertinents pour cet emplacement (au 2026-06). La colonne « allowance » correspond au multiplicateur d’utilisation incluse, et non à un plafond d’appels gratuits : au-delà de l’allocation incluse, chaque niveau bascule vers des crédits flexibles facturés par token aux tarifs Codex publiés par OpenAI. Un niveau supérieur augmente le multiplicateur inclus ; il ne rend pas l’utilisation gratuite.

Les deux niveaux Pro proposent la même gamme de modèles et de fonctionnalités ; ils ne diffèrent que par le volume de l’allocation incluse.

Le palier à 100 $ a été rétrogradé le 2026-06-01. Jusqu’au 2026-05-31, il bénéficiait d’une promotion de lancement à 10× Plus, puis est revenu au standard 5×. Le nombre de messages par modèle enregistré avant cette date incluait un bonus temporaire de 2× et n’est plus exact.

OpenAI ne publie pas de décompte strict de messages Codex par palier, et n’associe pas la mention « illimité » à des noms de modèles spécifiques ; la page tarifaire publique présente une seule carte « Pro » (« À partir de 100 $ », titre « 5x ou 20x plus d’utilisation ») avec la formule fourre-tout « illimité, sous réserve de garde-fous anti-abus ». Considérez tout décompte spécifique par modèle, issu d’anciennes docs ou d’autres sources, comme non faisant autorité. Le modèle de raisonnement phare Pro est GPT-5.5 Pro.

Les valeurs de fenêtre de contexte 128K / 400K et ~680 pages de la page tarifaire décrivent les modèles GPT Instant / GPT Reasoning de l’application ChatGPT, un espace de noms différent du backend responses de Codex utilisé par cet emplacement. Ne les interprétez pas comme des limites du backend Codex.

Importation du jeton

Importer le jeton Codex-CLI existant de manière non interactive plutôt que de démarrer un flux de navigateur :

zeroclaw auth login --model-provider openai-codex --import ~/.codex/auth.json
zeroclaw auth status   # openai-codex:default kind=OAuth account=... expires=...

(Alternatives interactives : zeroclaw auth login sans --import, ou --device-code.)

Exécutez le démon depuis le config-dir par défaut (~/.zeroclaw). Le profil d’authentification y est stocké nativement et les commandes zeroclaw auth l’utilisent par défaut ; pointer le démon vers un répertoire personnalisé signifie que le profil doit y être placé également, et comme il est chiffré par config-dir (ci-dessous), c’est là que les ennuis commencent.

Deux choses qui posent problème

Les profils d’authentification ne sont pas portables. auth-profiles.json est chiffré (enc2:) avec la .secret_key du répertoire de configuration. Vous ne pouvez pas copier le profil d’un hôte vers un autre, car la cible ne peut pas le déchiffrer ; le runtime journalise enc2: decryption failed (wrong `.secret_key` or tampered ciphertext) (la clause or tampered ciphertext partage ce chemin d’erreur, donc le message seul ne permet pas de distinguer un profil étranger d’un blob corrompu). Chaque hôte importe son propre profil depuis un ~/.codex/auth.json brut. Si un auth-profiles.json étranger est déjà présent, déplacez-le d’abord ailleurs, sinon l’import échouera en essayant de le charger :

mv ~/.zeroclaw/auth-profiles.json ~/.zeroclaw/auth-profiles.json.foreign 2>/dev/null
zeroclaw auth login --model-provider openai-codex --import ~/.codex/auth.json

Les jetons de rafraîchissement effectuent une rotation, un seul propriétaire. Chaque rafraîchissement réussi invalide le jeton de rafraîchissement précédent. Si deux hôtes rafraîchissent le même compte indépendamment, ils s’invalident mutuellement :

error=OpenAI token refresh is in backoff for 9s due to previous failures

Le modèle qui fonctionne sur plus d’un hôte, strictement limité aux machines que vous possédez sous le même compte OpenAI :

⚠️ Limite des informations d’identification. ~/.codex/auth.json contient des informations d’identification bearer et refresh actives pour votre compte OpenAI. Distribuez-le uniquement à vos propres hôtes, via un canal privé et chiffré : un gestionnaire de secrets, un transport chiffré ou un pull SSH uniquement. Ne le validez jamais dans un dépôt, ne le publiez pas, ne le collez pas dans un chat ou un ticket, et ne le partagez pas avec un autre utilisateur ou une équipe. Les conditions d’OpenAI interdisent le partage des informations d’identification de compte ou la mise à disposition d’un compte à une autre personne, et un point de pull auth.json brut constitue à lui seul un secret de grande valeur. Il s’agit de conseils de gestion des informations d’identification destinés aux opérateurs ; le code d’exécution ne le modifie pas.

1. Un hôte est propriétaire de l’actualisation (par exemple celui qui exécute l’actualisation en arrière-plan de Codex CLI) et maintient ~/.codex/auth.json à jour.
2. Cet hôte publie le fichier brut ~/.codex/auth.json vers un point de récupération privé (gestionnaire de secrets ou canal chiffré/SSH uniquement), accessible uniquement par vos propres hôtes.
3. Tous les autres hôtes récupèrent le fichier auth.json brut (portable, ce n’est que le jeton) et le réimportent localement, ce qui le rechiffre avec la propre .secret_key de cet hôte.
4. Les autres hôtes ne s’actualisent pas indépendamment.

L’artefact que vous distribuez est le fichier brut ~/.codex/auth.json, jamais le fichier chiffré auth-profiles.json, et uniquement vers vos propres machines via un canal privé et chiffré.

Vérification

zeroclaw auth status   # présent et non expiré
# then drive the agent once against the local gateway

Une exécution réussie renvoie la sortie du modèle avec exit_code=0. Deux signatures d’échec :

• ... token refresh in backoff : token périmé ou ayant subi une rotation ; récupérez à nouveau le fichier auth.json brut et réimportez-le.
• model=<x> ... 400 : chaîne de modèle non prise en charge ; utilisez un ID servi exact.

Liste de contrôle pour nouvel hôte

1. ~/.codex/auth.json présent et à jour (récupéré depuis le propriétaire du rafraîchissement).
2. zeroclaw auth login --model-provider openai-codex --import ~/.codex/auth.json (déplacez d’abord tout fichier auth-profiles.json étranger).
3. zeroclaw auth status affiche openai-codex:default ... kind=OAuth ... expires=<future>.
4. Une entrée openai avec wire_api = "responses", requires_openai_auth = true, et un ID de modèle servi exact.
5. Démon sur --config-dir ~/.zeroclaw (la valeur par défaut).
6. Exécutez l’agent une fois → exit_code=0 avec une sortie réelle.
7. Le routeur associe les rôles aux ID actuellement servis (n’épinglez pas une version que vous devrez ensuite traquer).