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

Codex n'est pas un simple assistant de saisie dans l'éditeur, mais un véritable exécutant autonome. Vous formulez la tâche en mots, et il décide lui-même quels fichiers lire, quelles commandes exécuter et ce qu'il faut 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, génération d'agents enfants pour les sous-tâches.

Deux modes de fonctionnement. Interactif — codex sans arguments, un dialogue dans le terminal avec affichage de chaque étape. Non interactif — codex exec "task", une exécution unique jusqu'au résultat : pratique dans les scripts et la CI.

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

Autre particularité — l'état du dialogue. Codex ne demande pas au serveur de mémoriser quoi que ce soit : il conserve tout le fil de conversation de son côté et l'envoie intégralement à chaque tour. Pour vous, cela signifie que la conversation ne reste pas stockée chez le fournisseur du modèle, et qu'un changement d'endpoint ne casse pas la session entamée.

La différence avec Claude Code et les autres agents en terminal, c'est précisément le protocole. Codex communique avec le modèle via la Responses API, où la conversation n'est pas décrite comme une liste plate de messages, mais comme un fil d'éléments : texte, appel d'outil, résultat d'appel, bloc de raisonnement. Cela offre à l'outil un modèle de dialogue plus rigoureux, et à vous — la nécessité de disposer d'un endpoint qui comprend ce protocole.

La voie rapide — l'installeur. La commande npx @joingonka/setup --tool codex ajoute elle-même dans ~/.codex/config.toml un bloc fournisseur avec wire_api = "responses", le modèle et sa fenêtre de contexte réelle, tout en préservant vos commentaires et vos autres réglages, puis vérifie la clé et le modèle par une requête en direct. Si un autre fournisseur est déjà sélectionné dans la config, l'installeur n'y touche pas et vous indique la commande pour un lancement ponctuel. Il place la clé directement dans le fichier (droits 600), dans le champ experimental_bearer_token — le seul où Codex peut stocker une clé en clair ; Codex lui-même le considère comme expérimental. La variante manuelle ci-dessous passe par une variable d'environnement.

Codex stocke ses réglages dans ~/.codex/config.toml. Un fournisseur personnalisé se décrit par un bloc [model_providers.*], et le champ clé ici est wire_api : sans lui, Codex tentera de parler en Chat Completions et ne bouclera pas la boucle agentique.

# ~/.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 le vôtre, pas OPENAI_API_KEY — ainsi, la configuration n'intercepte pas vos autres outils qui fonctionnent avec OpenAI.

export JOINGONKA_API_KEY=jg-your-key

Le champ model définit le modèle par défaut, et model_provider indique lequel des blocs décrits utiliser. Les deux sont redéfinissables au lancement, si bien qu'une seule config sert sans problème plusieurs fournisseurs : celui de production, celui d'expérimentation et celui de secours.

La clé s'obtient dans votre espace personnel après inscription ; vous y voyez aussi le solde et la consommation. Si vous préférez ne pas toucher à la config globale, le même bloc peut être transmis ponctuellement via -c : codex -c model_provider=joingonka …. Et pour gérer plusieurs configurations indépendantes, indiquez un répertoire de réglages via la variable CODEX_HOME.

Le moyen le plus rapide de vérifier que la connexion fonctionne : un seul essai.

codex exec "Answer in one line: what is 17*3?"

En tête de sa réponse, Codex indique avec qui il travaille : model, provider: joingonka, le mode sandbox et l'identifiant de session. Si votre fournisseur y figure et qu'une réponse arrive en bas, la connexion est active.

Ensuite, il faut tester l'essentiel, ce pour quoi on installe Codex : le travail avec les fichiers. Placez dans le répertoire un petit fichier contenant une erreur évidente et demandez-lui de la repérer :

codex exec "Read calc.py and tell me in one sentence whether it has a bug."

L'agent doit appeler lui-même l'outil de lecture, ouvrir le fichier et répondre de façon concrète — en indiquant la ligne. Si c'est le cas, le cycle agentique complet (requête → appel d'outil → résultat → réponse) passe correctement par la passerelle.

En cas de problème, le diagnostic se lit généralement directement dans le message :

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

Tous les modèles du réseau sont disponibles au même prix, donc le choix concerne le comportement et non le budget. Voici le résultat d'un test en temps réel d'une même tâche (lecture de fichier et recherche d'erreur) via Codex sur DeepSeek V4 Flash et MiniMax M2.7 ; GLM-5.3 Flash a rejoint le réseau après le test — ses propriétés de modèle sont indiquées pour lui.

La recommandation par défaut est DeepSeek V4 Flash : le travail de l'agent atteint rapidement la limite du volume de contexte, et 380K jetons permettent de garder beaucoup de fichiers en mémoire simultanément. Si la tâche nécessite de réfléchir à une logique complexe, choisissez GLM-5.3 Flash, mais prévoyez une marge pour max_tokens : une partie du budget de réponse est utilisée pour le raisonnement. Le modèle se change avec une seule ligne model dans la configuration ou avec l'indicateur -c model=… sans modifier le fichier.

La liste actuelle des modèles du réseau est toujours disponible via 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.0069 par million en entrée et $0.021 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.