Documentation

Codex CLI

Codex utilise exclusivement l’API Responses. Un seul bloc de fournisseur dans config.toml le dirige vers l’interface native /v1/responses de Kunavo, et la clé est stockée dans une variable d’environnement plutôt que dans le fichier.

Un bloc [model_providers.kunavo] dans ~/.codex/config.toml avec env_key, afin que la clé reste dans l’environnement et jamais dans le fichier de configuration.

~/.codex/config.toml

model = "gpt-5-6-sol"
model_provider = "kunavo"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"     # the NAME of the variable, not the key
# wire_api defaults to "responses", which is the only supported value

wire_api n’admet désormais qu’une seule valeur : "responses", qui est également utilisée par défaut si elle est omise. La prise en charge de Chat Completions a été supprimée de Codex. Tout guide antérieur qui vous conseille d’écrire wire_api = "chat" est donc obsolète, et aucun point de terminaison dépourvu d’une véritable route /v1/responses ne peut être utilisé avec Codex. Kunavo l’implémente nativement.

env_key contient le nom d’une variable d’environnement, et non la clé elle-même. C’est intentionnel du côté d’OpenAI : config.toml est un fichier que l’on valide dans un dépôt et que l’on colle dans des tickets.

Pas encore de clé ? Créez un compte Kunavo, créez une clé (elle commence par sk-kn-) et ajoutez un crédit à partir de 10 $ — les appels sont payés sur ce solde et les appels échoués ne sont pas facturés. Le tableau de bord s’ouvre ensuite sur la configuration Codex CLI.

Étape par étape

Créez une clé sur /app/keys et copiez-la — elle n’est affichée qu’une seule fois.
Ajoutez le bloc ci-dessus à ~/.codex/config.toml, en créant le fichier s’il n’existe pas.
Exportez la variable indiquée par env_key : export KUNAVO_API_KEY=sk-kn-...
Exécutez codex. Le model_provider de premier niveau sélectionne le bloc ; model sélectionne l’identifiant à l’intérieur de celui-ci.
Pour changer de modèle à chaque session plutôt que de modifier le fichier, utilisez codex -m <model id>, ou conservez plusieurs blocs de fournisseurs et modifiez model_provider.

Vérifié avec la référence du fichier de configuration de Codex le 6 septembre 2026. Les paramètres tiers évoluent ; si le nom d’un champ ne correspond plus à ce que vous voyez ici, cette page fait autorité, pas celle-ci.

Voici la version courte. Le guide complet — choix du modèle, coût d’une session réelle et modes d’échec — se trouve dans le guide de Codex CLI sur les clés API.

Vérifiez avant de déboguer le client

Une requête suffit à déterminer si l’échec vient de l’endpoint, de la clé ou du fichier de configuration. Si cette requête renvoie du JSON, la même URL de base et la même clé fonctionnent dans Codex CLI.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Quel identifiant de modèle saisir dans le champ

Tous les modèles textuels sont accessibles sous forme d’identifiant de modèle — la liste à jour se trouve sur GET /v1/models, et le catalogue avec les prix sur la page des modèles. Les tarifs sont en USD par million de tokens, entrée / sortie.

Identifiant du modèle	Entrée / sortie sur Kunavo	Où cela s’intègre dans Codex CLI
`gpt-5-6-sol`	$2.00 / $12.00	l’association Codex par défaut — native Responses, sans intermédiaire
`gpt-6-sol`	$0.80 / $4.00	GPT-6 d’OpenAI pour le codage complexe et les agents — le même chemin Responses, à un tarif inférieur à celui de 5.6 Sol
`gpt-6-luna`	$0.04 / $0.20	le GPT-6 le moins cher, pour les traitements à grand volume ou à faible effort
`gpt-5-6-terra`	$0.70 / $4.20	une gamme GPT moins chère pour les sessions axées sur l’édition
`claude-sonnet-5`	$1.40 / $7.00	un modèle non GPT via Responses — traduit par la passerelle
`claude-opus-5`	$3.50 / $17.50	les phases de planification où la profondeur de raisonnement justifie le tarif

La facturation se fait au token à partir d’un solde prépayé, sans frais mensuels — consultez la facturation. Avec un contexte répété — ce qu’envoient la plupart des éditeurs et clients de chat — la mise en cache des prompts influe davantage sur la facture que le choix du modèle.

Questions fréquentes

Comment diriger Codex CLI vers un point de terminaison API personnalisé ?

Ajoutez une table [model_providers.<id>] à ~/.codex/config.toml avec name, base_url et env_key, puis définissez le model_provider de premier niveau sur cet identifiant et model sur l’identifiant du modèle à exécuter. base_url est la racine /v1 du service ; env_key désigne la variable d’environnement contenant la clé, qui ne figure donc jamais dans le fichier lui-même.

Quelle valeur de wire_api Codex CLI doit-il utiliser ?

« responses » — la référence de configuration précise que c’est la seule valeur prise en charge et la valeur par défaut si elle est omise. Codex a supprimé la prise en charge de Chat Completions ; un point de terminaison qui implémente uniquement /v1/chat/completions ne peut donc pas être utilisé avec Codex, quelle que soit la configuration. Le point de terminaison doit fournir une véritable route /v1/responses.

Codex CLI peut-il exécuter des modèles Claude ?

Oui, si le point de terminaison les expose via l’API Responses. Codex envoie une requête au format Responses à l’URL indiquée par base_url et transmet l’identifiant du modèle. Une passerelle qui convertit les requêtes Responses au format propre au modèle peut donc fournir à Codex des identifiants Claude ou Gemini. Codex ne sait pas lui-même quel fournisseur répond.

Où Codex CLI stocke-t-il la clé API ?

Dans une variable d’environnement dont le nom est indiqué par le champ env_key du bloc de fournisseur, et non dans config.toml. Codex lit cette variable au démarrage ; la clé se trouve donc dans votre profil shell ou votre gestionnaire de secrets, et le fichier de configuration peut être validé dans un dépôt ou collé dans un rapport de bogue sans risque.