Codex

Codex CLI : rôle de review_model et reasoning_effort

Comprenez review_model, model_reasoning_effort, /review, /model et l’effet de ces paramètres sur le coût et la qualité dans Codex CLI. Conseils pratiques.

Réponse courte

review_model choisit le modèle de /review ; sans ce paramètre, Codex utilise le modèle de la session active. model_reasoning_effort règle l’effort de raisonnement des modèles qui le prennent en charge via la Responses API.

Un effort plus élevé peut aider pour les tâches difficiles, mais ne garantit ni une réponse correcte ni un coût total inférieur. Ce n’est pas un réglage de température ou de longueur de réponse.

Relations entre les champs

Champ	Rôle
`model`	Modèle par défaut pour le travail courant
`review_model`	Modèle utilisé par les flux de revue tels que `/review`
`model_reasoning_effort`	Puissance de raisonnement du modèle principal
`/model`	Point d’entrée dans la session pour modifier le modèle ou le raisonnement
`/review`	Point d’entrée pour demander à Codex de revoir les modifications actuelles

Choisir l’effort selon la tâche

Utilisez ces niveaux comme point de départ, puis évaluez le résultat selon les critères d’acceptation :

Tâche	Point de départ	Points à vérifier
Petite modification bien définie ou explication courte	`low`, si pris en charge	Exactitude et délai de réponse.
Fonction courante ou bug clairement reproductible	`medium`, si pris en charge	Tests, exhaustivité et modifications inutiles.
Diagnostic difficile, modification entre modules ou revue approfondie	`high` ; essayez un niveau supérieur disponible si nécessaire	Contraintes oubliées, faux signalements et délai total avant un résultat exploitable.

Les niveaux disponibles dépendent du modèle, de la version de Codex et du fournisseur. Consultez /model et la référence du modèle avant d’utiliser xhigh ou max. La prise en charge par un modèle ne vaut pas pour un autre. Un effort plus élevé peut augmenter les tokens de raisonnement et la latence ; les nouvelles tentatives, le contexte, les appels d’outils et les tarifs influencent aussi le coût total.

Exemple de configuration

Définissez les valeurs persistantes dans config.toml sous CODEX_HOME, ou dans ~/.codex/config.toml si la variable n’est pas définie. Placez ces clés au niveau supérieur, avant les tables TOML, et conservez la configuration du fournisseur et de l’authentification :

model = "gpt-6-astra"
review_model = "gpt-6-astra"
model_reasoning_effort = "high"

Paramètres de configuration

Paramètre	Rôle et emplacement	Valeurs par défaut et exemples
`model`	Racine ; Model ID complet de la place des modèles.	Exemple : `gpt-6-astra`, à remplacer au besoin.
`review_model`	Racine ; modèle utilisé par `/review`.	Facultatif ; modèle de la session actuelle par défaut.
`model_reasoning_effort`	Racine ; effort de raisonnement du modèle.	Exemple : `high` ; niveaux et valeurs par défaut dépendent du modèle.

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.

Valeurs du fichier et réglages de session

Au démarrage, les arguments CLI et les options -c priment sur la configuration du projet approuvé, le profil choisi et les valeurs utilisateur. Dans les versions actuelles, --profile NAME charge NAME.config.toml depuis CODEX_HOME. Les anciennes versions utilisaient un autre format de profil.

Pour modifier uniquement l’effort lors d’un lancement :

codex -c 'model_reasoning_effort="medium"'

Dans une session, utilisez /model pour sélectionner le modèle actif et un niveau disponible. Modifier le fichier ne garantit pas la mise à jour immédiate d’une session en cours ; démarrez une nouvelle session pour vérifier les valeurs enregistrées. Le mode Plan peut utiliser plan_mode_reasoning_effort ou son propre préréglage : vérifiez-le séparément.

Vérifier le réglage effectif

Exécutez codex --version, puis démarrez une nouvelle session depuis le répertoire du projet visé.
Vérifiez l’effort sélectionné avec /model et le modèle actif ainsi que la configuration avec /status. En cas d’écart avec le fichier, examinez les arguments de lancement, le profil, la configuration du projet et /debug-config si disponible.
Comparez une même tâche représentative à deux niveaux pris en charge, dans des sessions distinctes. Examinez le diff, les tests, la durée et les relevés d’utilisation BetterToken. Gardez le réglage qui atteint votre objectif de qualité ; un effort réduit ne garantit pas un coût total inférieur.

Erreurs fréquentes

Penser que review_model remplace le modèle principal pour toutes les tâches.
Traiter l’effort de raisonnement comme un réglage de température.
Utiliser un Model ID non pris en charge par le fournisseur actuel.
Utiliser l’effort de raisonnement maximal pour chaque tâche.
Ne regarder que les noms de modèles sans vérifier l’utilisation réelle ni la qualité du résultat.