Codex : model_provider, Base URL et wire_api

Réponse courte

model_provider indique à Codex CLI quel fournisseur utiliser. Sa valeur doit correspondre à un ID de fournisseur défini sous [model_providers.<id>].

base_url est le point de terminaison API vers lequel les requêtes de modèles sont envoyées. Pour un fournisseur compatible OpenAI, il pointe généralement vers un point de terminaison de type /v1.

wire_api définit le protocole. Codex accepte actuellement uniquement responses, également utilisé quand ce paramètre est omis.

Quand cela importe

• Vous configurez un fournisseur personnalisé compatible OpenAI
• Codex indique que le fournisseur est introuvable ou que les requêtes de modèles échouent
• Vous ne savez pas en quoi model_provider diffère de model
• Vous placez BetterToken, OpenAI ou un autre fournisseur dans un même fichier config.toml
• Vous devez distinguer Base URL, API Key et Model ID

Relations entre les champs

Champ	Rôle
model_provider	Sélectionne l’ID du fournisseur actif
[model_providers.<id>]	Définit la configuration détaillée d’un fournisseur
name	Nom d’affichage du fournisseur
base_url	Point de terminaison API racine
wire_api	Protocole du provider ; seul responses est actuellement accepté.
model	Model ID principal par défaut
review_model	Modèle utilisé par les flux de revue de code tels que /review

Localisez les fichiers et sauvegardez-les

Si vous avez défini un CODEX_HOME personnalisé, modifiez config.toml et auth.json dans ce répertoire. Sinon, utilisez ~/.codex sur macOS / Linux ou %USERPROFILE%\.codex sur Windows. CLI et App doivent utiliser le même répertoire. WSL possède son propre répertoire utilisateur.

Quittez complètement Codex avant toute modification. Sauvegardez les deux fichiers dans un emplacement privé. Créez les fichiers manquants. Remplacez les paramètres existants sans dupliquer les clés ni les tables ; conservez les autres paramètres.

Cette configuration remplace la connexion ChatGPT par l’authentification avec une API Key. Elle ne conserve pas l’accès au compte officiel. Protégez auth.json et ses sauvegardes ; ne les partagez pas et ne les ajoutez pas au dépôt.

Modèle recommandé

Modifiez config.toml

Cette page utilise le config.toml utilisateur. Placez les clés racine avant toutes les tables TOML, pas dans [projects."<path>"] ; cette table contient le trust_level du projet. L’ID sélectionné doit correspondre au nom de la table. Pour l’authentification par fichier, retirez env_key et experimental_bearer_token du provider sélectionné.

model_provider = "bettertoken"
model = "gpt-6-astra"
cli_auth_credentials_store = "file"

[model_providers.bettertoken]
name = "BetterToken"
base_url = "https://bettertoken.ai/v1"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

L’exemple utilise GPT-6 Astra (gpt-6-astra). Pour un autre modèle, copiez son ID complet depuis la model plaza et remplacez model. GPT, Kimi et GLM utilisent la même structure d’authentification par fichiers ; la configuration automatique est disponible pour GPT.

Modifiez auth.json

auth.json se trouve dans le même répertoire que config.toml. Si auth.json n’existe pas, créez ce fichier dans ce répertoire. Utilisez le JSON suivant comme contenu du fichier, remplacez YOUR_API_KEY par votre BetterToken API Key, puis enregistrez le fichier.

{
  "auth_mode": "apikey",
  "OPENAI_API_KEY": "YOUR_API_KEY"
}

Paramètres de configuration

Paramètre	Rôle et emplacement	Valeurs par défaut et exemples
model_provider	Racine du fichier utilisateur ; sélectionne l’ID défini ci-dessous.	Par défaut openai ; ici bettertoken.
model	Racine ; Model ID complet de la place des modèles.	Exemple : gpt-6-astra, à remplacer au besoin.
cli_auth_credentials_store	Racine ; stockage des identifiants de connexion.	Ici file : lit auth.json dans le même répertoire.
name	Table du provider ; nom affiché uniquement.	BetterToken n’est pas un Model ID.
base_url	Table du provider ; Base URL de l’API du modèle.	Utilisez https://bettertoken.ai/v1 ; Codex ajoute /responses.
wire_api	Table du provider ; protocole des requêtes.	Seul responses est actuellement accepté ; c’est aussi la valeur par défaut.
requires_openai_auth	Table du provider ; authentification OpenAI et stockage associé.	Par défaut false ; ici true. Ce n’est pas un bouton de conservation du fichier de connexion.
supports_websockets	Table du provider ; prise en charge de Responses WebSocket.	Par défaut false ; cette configuration conserve HTTP/SSE.
auth_mode	Dans auth.json ; mode d’authentification.	Ici apikey : remplace l’authentification officielle ChatGPT.
OPENAI_API_KEY	Dans auth.json ; clé pour l’authentification API.	Remplacez YOUR_API_KEY par BetterToken API Key.

L’authentification par fichier passe ici au mode API Key. Pour conserver le compte officiel, utilisez la configuration dédiée ; ne mélangez pas les modes. Ils diffèrent par l’objectif d’authentification, pas par CLI, App ou Extension.

Réglages facultatifs

Ces trois réglages sont facultatifs et ne conditionnent pas la connexion. Ajoutez-les à la table existante [model_providers.bettertoken] au besoin ; ne créez pas de doublon.

request_max_retries = 4
stream_max_retries = 8
stream_idle_timeout_ms = 300000

Paramètre	Rôle et emplacement	Valeurs par défaut et exemples
request_max_retries	Table du provider ; nombre maximal de nouvelles tentatives HTTP.	Par défaut 4 ; adaptez à la connexion.
stream_max_retries	Table du provider ; reconnexions après interruption du flux.	Par défaut 5 ; 8 est un réglage personnalisé facultatif.
stream_idle_timeout_ms	Table du provider ; délai d’inactivité du flux en millisecondes.	Par défaut 300000 ; ce n’est pas la durée totale de la tâche.

Couches de configuration et anciennes clés

Ne placez pas modèle ou raisonnement dans [projects."<path>"]. Un modèle propre au projet peut utiliser les clés racine de .codex/config.toml dans un projet approuvé ; provider et authentification restent dans le fichier utilisateur. Les profils actuels utilisent NAME.config.toml sous CODEX_HOME, choisi avec codex --profile NAME, pas les anciennes tables [profiles.NAME] ni le sélecteur racine profile.

Redémarrez et vérifiez

Enregistrez les deux fichiers. Lancez une nouvelle session Codex CLI directement dans le terminal :

codex

Quittez complètement Codex App, y compris les processus en arrière-plan. Rouvrez l’application et créez une nouvelle tâche locale. Envoyez une courte consigne dans chaque client utilisé. Une réponse normale vérifie la connexion de ce client.

Dépannage

En cas de 401, 403 ou de demande de connexion, vérifiez le répertoire actif, la Key dans auth.json, auth_mode = apikey, cli_auth_credentials_store = file et requires_openai_auth = true. Pour une erreur de fournisseur ou de modèle, vérifiez l’ID du fournisseur, https://bettertoken.ai/v1, wire_api = responses et la disponibilité du modèle. Si les changements ne s’appliquent pas, vérifiez les paramètres prioritaires et assurez-vous que CLI et App utilisent le même CODEX_HOME.

Documentation associée

• Comment configurer config.toml de Codex CLI
• Guide de configuration BetterToken pour Codex
• Quels sont les modes sandbox et approbation de Codex CLI ?
• API compatible OpenAI et API compatible Anthropic : différences

Références

• Référence de configuration Codex
• Exemple de configuration Codex
• Configuration avancée de Codex