Codex CLI : utilisez votre propre clé plutôt qu'un abonnement

Codex n'est pas un assistant de saisie dans l'éditeur, mais un exécuteur autonome. Vous formulez une tâche avec vos mots, et il décide lui-même quels fichiers lire, quelles commandes exécuter et quoi modifier. Il dispose d'une dizaine d'outils : exécution de commandes, lecture de fichiers, tenue d'un plan de travail, demande de précision à l'utilisateur, et génération d'agents subordonnés pour des sous-tâches.

Il propose deux modes de fonctionnement. Interactif : codex sans arguments, un dialogue dans le terminal affichant chaque étape. Non-interactif : codex exec «tâche», une exécution unique jusqu'au résultat : pratique dans les scripts et CI.

La sécurité est intégrée : par défaut, l'agent fonctionne dans un sandbox et demande confirmation avant toute modification. Le niveau de contrôle se définit dans la configuration — de « tout demander » à une exécution entièrement autonome avec droit d'écriture dans le répertoire de travail.

Une autre particularité est l'état du dialogue. Codex ne demande pas au serveur de mémoriser quoi que ce soit : il conserve tout l'historique et l'envoie intégralement à chaque étape. Pour vous, cela signifie que la conversation n'est pas stockée chez le fournisseur du modèle, et qu'un changement d'endpoint n'interrompt pas la session en cours.

La différence avec Claude Code et d'autres agents de terminal réside précisément dans le protocole. Codex communique avec le modèle via Responses API, où la conversation n'est pas décrite comme une simple liste de messages, mais comme une suite d'éléments : texte, appel d'outil, résultat d'appel, bloc de raisonnement. Cela confère à l'outil un modèle de dialogue plus rigoureux, et vous impose d'avoir un endpoint qui comprend ce protocole.

Codex conserve ses paramètres dans ~/.codex/config.toml. Votre propre fournisseur se définit dans un bloc [model_providers.*], et le champ clé ici est wire_api : sans lui, Codex essaiera de communiquer via Chat Completions et ne pourra pas créer la boucle d'agent.

# ~/.codex/config.toml
model_provider = "joingonka"
model = "deepseek-ai/DeepSeek-V4-Flash-0731"

[model_providers.joingonka]
name = "JoinGonka Gateway"
base_url = "https://gate.joingonka.ai/v1"
env_key = "JOINGONKA_API_KEY"
wire_api = "responses"

La clé n'est pas écrite dans le fichier : env_key nomme la variable d'environnement dans laquelle Codex ira la chercher. Le nom de la variable est unique, ce n'est pas OPENAI_API_KEY — ainsi, ce réglage n'interfère pas avec vos autres outils utilisant OpenAI.

export JOINGONKA_API_KEY=jg-votre-clé

Le champ model définit le modèle par défaut, et model_provider le bloc à utiliser. Les deux peuvent être surchargés au moment de l'exécution, ce qui permet à une seule configuration de gérer plusieurs fournisseurs : production, expérimental et secours.

La clé est fournie dans l'espace client après l'inscription, où vous pouvez également consulter le solde et la consommation. Si vous préférez ne pas modifier la configuration générale, le même bloc peut être transmis ponctuellement via -c : codex -c model_provider=joingonka …. Et pour conserver plusieurs configurations indépendantes, indiquez le répertoire des paramètres via la variable CODEX_HOME.

Le moyen le plus rapide de vérifier que le lien fonctionne est d'effectuer un test unique :

codex exec "Réponds en une ligne : combien font 17*3 ?"

Dans l'en-tête de la réponse, Codex affiche avec qui il travaille : model, provider: joingonka, le mode bac à sable (sandbox) et l'identifiant de session. Si votre fournisseur s'y trouve et que la réponse s'affiche en dessous, la connexion est active.

Ensuite, il convient de vérifier la fonctionnalité principale pour laquelle Codex est installé : le travail sur les fichiers. Placez un petit fichier avec une erreur évidente dans le répertoire et demandez-lui de la trouver :

codex exec "Lis calc.py et dis-moi en une phrase s'il y a une erreur."

L'agent doit appeler lui-même l'outil de lecture, ouvrir le fichier et répondre de manière pertinente, en précisant la ligne. Si cela se produit, le cycle complet de l'agent (requête → appel d'outil → résultat → réponse) via la passerelle est correctement configuré.

Si quelque chose ne fonctionne pas, le diagnostic se lit généralement directement dans le message :

La première requête d'une session peut prendre quelques secondes : Codex envoie un prompt système volumineux et la description de tous ses outils, et le nœud du réseau doit accepter la tâche. Les réponses suivantes sont plus rapides.

Tous les modèles du réseau sont disponibles au même prix, le choix concerne donc le comportement et non le budget. Voici le résultat d'un test réel de la même tâche (lecture de fichier et recherche d'erreur) via Codex sur chaque modèle.

La recommandation par défaut est DeepSeek V4 Flash : le travail d'agent sature rapidement le contexte, et 380K jetons permettent de garder beaucoup de fichiers en mémoire simultanément. Si vous souhaitez des réponses extrêmement courtes, choisissez Kimi K2.6. Le modèle peut être modifié via une seule ligne model dans la configuration ou via le flag -c model=… sans éditer le fichier.

La liste actuelle des modèles du réseau est toujours disponible sur GET https://gate.joingonka.ai/v1/models.

Les outils d'agent consomment des jetons différemment du chat : pour chaque phrase, Codex ajoute un prompt système et une description de tous les outils, puis mène un dialogue complexe avec le modèle. Dans un test réel, une tâche simple consistant à « lire un fichier et trouver une erreur » a coûté environ 18 à 20 mille jetons. C'est un prix normal pour l'autonomie, et c'est pourquoi le prix par jeton est déterminant.

Via la passerelle JoinGonka, les jetons coûtent $0.0047 par million en entrée et $0.014 par million en sortie — le prix est identique pour tous les modèles du réseau et est mis à jour en temps réel sur cette page.

Pour comparer, voici comment fonctionnent les options payantes chez Codex et ses concurrents :

Le paiement s'effectue à la consommation réelle, sans abonnement mensuel ni quotas sur le nombre de requêtes : pas de fenêtres de cinq heures, de limite de « prompts » ou de multiplicateurs aux heures de pointe. Le solde est rechargé en cryptomonnaie, et le solde restant ainsi que la consommation journalière sont visibles dans le tableau de bord. Analyse détaillée de l'économie dans l'article sur l'API la moins chère.

L'historique de la conversation est conservé par Codex lui-même. Il l'envoie en entier à chaque requête et ne demande pas au serveur de mémoriser quoi que ce soit — et nous ne stockons pas non plus les correspondances. Votre code et vos prompts ne restent pas sur la passerelle après la réponse.

La recherche web fonctionne. Codex déclare l'outil de recherche à chaque requête et la passerelle l'accepte : la recherche est effectuée de notre côté, les résultats sont intégrés à la réponse du modèle.

Les outils sont locaux, pas cloud. Codex exécute les commandes et lit les fichiers localement, sur votre machine, donc l'accès au projet ne dépend pas du fournisseur du modèle.

Sandbox. Sous Linux, Codex utilise bubblewrap pour isoler les commandes exécutées. S'il n'est pas présent sur le système, Codex vous avertira et utilisera une copie intégrée — cela n'affecte pas le travail, mais il est plus pratique d'installer le paquet via le gestionnaire standard.

Si vous devez travailler avec des images — une capture d'écran d'interface, un schéma sur une photo — utilisez un outil avec un modèle capable de vision pour ces tâches : les modèles du réseau Gonka sont textuels. Pour le code, les commandes et les fichiers, ce n'est pas une limitation.

Si Codex ne convient pas, essayez d'autres agents terminaux : le démarrage rapide de l'API montre comment connecter n'importe quel outil compatible en quelques minutes.