Reasoning effort, fast mode ou ultracode : lequel choisir ?

Qu’est-ce que l’effort et comment règle-t-il la réflexion du modèle ?

L’effort est le réglage qui fixe combien de travail le modèle met dans une réponse ; OpenAI parle de reasoning effort, Google de thinking level. Dans l’article sur SWE-bench, nous avons montré qu’un même modèle obtient un autre score quand seul l’effort change, et dans l’article sur les sous-agents, comment les sous-agents héritent de l’effort. Cet article place l’effort à côté de deux réglages avec lesquels on le confond souvent :

Les trois fournisseurs règlent désormais la réflexion par un niveau nommé, et non plus par un nombre de tokens. La documentation d’Anthropic dit clairement ce qu’est ce niveau : pas un budget, mais une indication donnée au modèle (« a behavioral signal, not a strict token budget »). Il agit non seulement sur la réflexion, mais aussi sur le texte et les appels d’outils ; plus l’effort baisse, moins le modèle fait d’appels d’outils, et plus ils sont courts.

Source : documentation des API des trois fournisseurs, 20 octobre 2026. GPT-6.1 Sol ne prend pas en charge les niveaux none et minimal. Chez Google, le niveau minimal ne garantit pas que la réflexion soit coupée, même sur les modèles qui le prennent en charge.

Chez les trois, la limite stricte est celle des tokens de sortie : max_tokens chez Anthropic, max_output_tokens chez OpenAI et Google. Anthropic le dit en peu de mots : l’effort est une indication souple, max_tokens une limite stricte. Si le modèle atteint cette limite pendant qu’il réfléchit, la réponse est coupée ou revient vide ; OpenAI et Google écrivent clairement que la réflexion consommée est facturée quand même.

Deux choses ont changé cette année. D’abord, l’ancien budget de tokens disparaît : chez Anthropic, budget_tokens est déprécié sur les modèles 4.6 et refusé par 4.7 et les suivants ; chez Google, thinking_budget est déprécié pour Gemini 4 Argon. Sur Opus 5.5 et Gemini 4 Argon, on ne peut même pas désactiver la réflexion ; le niveau est le seul bouton dont vous disposez. Ensuite, les valeurs par défaut ont baissé. Opus 5.5, Haiku 5.5, GPT-6.1 Sol et Gemini 4 Argon démarrent à medium ; Opus 5.5 démarre ainsi un niveau en dessous d’Opus 5. La valeur par défaut de Sonnet 5.5 dépend de l’endroit où il tourne : high sur l’API Claude, medium dans Claude Code.

Ne comparez pas les noms de niveaux d’un modèle à l’autre. La documentation de Claude Code indique que l’échelle est calibrée pour chaque modèle séparément, et que le même nom ne correspond pas à la même quantité de réflexion d’un modèle à l’autre ; les niveaux de Sonnet 5.5 ont été recalibrés par rapport à Sonnet 5. La documentation de Codex dit aussi que les niveaux ne se correspondent pas exactement d’une génération de modèles à l’autre.

Changer l’effort en pleine conversation a un prix. Chez Anthropic, changer l’effort à l’échelle de la requête invalide le cache du prompt ; l’effort par message (bêta) change le niveau en conservant le cache, et fonctionne sur Opus 5.5, Sonnet 5.5 et Haiku 5.5. Chez OpenAI, configuration_update fait la même chose depuis le 3 septembre. Pourquoi le cache se casse, nous l’avons expliqué dans l’article sur le prompt caching.

Comment régler l’effort dans les cinq outils ?

Les cinq outils font choisir le niveau par une commande ou un réglage. Ils diffèrent par la valeur par défaut, et par l’existence ou non d’un mode supérieur qui répartit le travail entre des sous-agents. Nous avons tiré le tableau de la documentation et des notes de version de chaque outil, le 20 octobre 2026 :

Source : documentation et notes de version de chaque outil, 20 octobre 2026. « Pas dans la documentation » : nous n’avons trouvé aucune phrase le disant dans les pages lues ce jour-là. --effort est arrivé dans Copilot CLI avec la version 1.0.10 (20 mars), et max pour les modèles Anthropic avec la 1.0.60 (5 juin). /effort est arrivé dans Antigravity CLI avec la version 1.1.5 (21 juillet), et /boost dans l’application Antigravity avec la 2.12.0 (2 septembre). HydraFusion Max a été annoncé le 14 octobre.

Dans Claude Code, /effort ouvre un curseur ; vous pouvez aussi taper le niveau directement, comme /effort high. effortLevel dans le fichier de paramètres accepte les valeurs de low à xhigh ; max n’y est pas accepté et ne se choisit que pour une session. On peut aussi écrire effort dans la définition d’un skill ou d’un sous-agent ; tant que ce skill ou ce sous-agent tourne, cette valeur remplace le niveau de la session.

Dans Codex, c’est model_reasoning_effort dans ~/.codex/config.toml qui fixe le niveau ; les niveaux disponibles dépendent du modèle et du client. Vous pouvez donner une valeur à part au mode Plan ; si vous la laissez vide, le mode Plan utilise sa propre valeur par défaut. Exemple :

model_reasoning_effort = "high"
plan_mode_reasoning_effort = "xhigh"

La page des modèles de Codex distingue les deux niveaux du haut : Max donne plus de temps de réflexion à une seule tâche, Ultra répartit les parties distinctes d’un travail complexe entre des sous-agents en parallèle. La même page précise que la plupart des tâches n’ont besoin ni de l’un ni de l’autre.

Dans Copilot CLI, --effort (nom long --reasoning-effort) prend cinq niveaux, de low à max ; max n’existe que sur les modèles Anthropic. Depuis la version 1.0.88, le reasoningEffort de la définition d’un agent personnalisé s’applique quand cet agent est sélectionné ; un niveau passé explicitement en ligne de commande reste prioritaire. Dans VS Code, le niveau se choisit dans le sous-menu « Thinking Effort », qui s’ouvre en cliquant sur la flèche à côté du nom du modèle dans le sélecteur, et il est mémorisé par session. La documentation de GitHub donne aussi le prix : un niveau plus élevé consomme plus de tokens, donc plus de crédits IA ; commencez au niveau normal et ne montez que pour les tâches difficiles.

Dans Cursor, le forfait Plus fait tourner les modèles maison de Cursor avec des réglages fixes : effort medium, Fast désactivé. Pour choisir un niveau d’effort et Fast, il faut Premium ou plus. Le Max Mode des anciens forfaits à la requête n’est pas un niveau d’effort ; c’est une option à part qui élargit la fenêtre de contexte du modèle.

Dans Antigravity CLI, /effort choisit le niveau et le garde pour les sessions suivantes ; --effort ne vaut que pour l’exécution en cours. La plupart des modèles proposent low, medium et high ; xhigh et max n’existent que sur certains. Si vous utilisez encore Gemini CLI : sa liste de commandes n’a aucune commande pour l’effort, et le réglage de la réflexion ne se trouve que dans les définitions de modèles de la configuration. Google a remplacé Gemini CLI par Antigravity CLI pour les utilisateurs du niveau gratuit et de Google One le 18 juin 2026 ; avec des clés d’API payantes, Gemini CLI reste utilisable.

Qu’est-ce qu’ultracode et en quoi diffère-t-il de l’effort ?

D’après la documentation de Claude Code, ultracode n’est pas un niveau d’effort, mais un réglage de Claude Code. Quand il est activé, Claude planifie un workflow dynamique (dynamic workflow) pour chaque tâche substantielle : il écrit un script JavaScript qui découpe le travail en parties et pilote de nombreux sous-agents, puis l’exécute en arrière-plan. D’après la documentation des workflows, une seule demande peut devenir plusieurs workflows à la suite : un pour comprendre le code, un pour faire le changement, un pour le vérifier.

L’effort, lui, fixe combien un seul agent réfléchit. Les deux sont indépendants : ultracode tourne au niveau où se trouve la session. Cette séparation est récente. Quand ultracode a été annoncé avec les workflows dynamiques le 28 mai, il passait l’effort à xhigh. Depuis la version 2.1.284 (28 septembre), c’est un interrupteur à part dans /effort, qui ne touche plus au niveau. Les textes antérieurs à cette date décrivent l’ancien comportement. Une exception demeure : si vous lancez la session avec claude --effort ultracode, le niveau passe aussi à xhigh. Les quatre façons d’activer ultracode sont dans l’article sur les sous-agents.

Il n’y a pas de multiplicateur pour le coût. Anthropic ne publie pas par combien ultracode multiplie les tokens ; la documentation dit que chaque demande consommera plus de tokens et prendra plus de temps, et qu’avec un abonnement vous atteindrez plus tôt une limite de session ou hebdomadaire. Avec ultracode activé, deux freins sautent : l’avertissement « Large workflow », qui concerne les workflows prévoyant plus de 25 agents ou 1,5 million de tokens, ne s’affiche pas, et la limite de sous-agents simultanés de la session ne s’applique pas aux sous-agents lancés avec l’outil Agent. Les limites propres au workflow restent en place : par défaut 16 à la fois, et au plus 1 000 agents par exécution. Ultracode ne s’active pas si les workflows sont désactivés ou si le modèle ne prend pas en charge xhigh.

Les autres outils ont leurs équivalents de la même idée. Aucun n’est la même chose que l’effort :

Source : documentation de Claude Code, de Codex, d’HydraFusion et d’Antigravity, 20 octobre 2026. Dans Codex, Ultra figure comme un niveau du curseur d’effort (de Light à Ultra) ; il ne fait pas partie des valeurs de reasoning.effort de l’API OpenAI.

Ultrathink, au nom voisin, est autre chose. Quand vous écrivez ultrathink dans un prompt, Claude Code ajoute pour ce tour une consigne demandant une réflexion plus poussée, mais le niveau d’effort envoyé à l’API ne change pas. Ultrathink est donc une demande valable pour un message, l’effort le réglage de la session, et ultracode le nombre d’agents qui font le travail.

Les sources que nous avons lues ne contiennent aucune mesure comparant ultracode activé et désactivé, ni pour les modes similaires. Essayez donc ultracode sur un gros travail divisible, et d’abord sur une petite tranche. La documentation des workflows conseille elle aussi de commencer dans un seul dossier, pour voir la dépense avant de lancer un gros travail.

Qu’accélère le fast mode et combien coûte-t-il ?

L’effort change combien le même modèle réfléchit ; le fast mode, à quelle vitesse le même modèle écrit sa réponse. Les fournisseurs vendent le même modèle à plusieurs vitesses : moins cher pour qui peut attendre, plus cher pour qui est pressé. Nous avons lu les informations du tableau dans la documentation des tarifs et des niveaux de service des fournisseurs, le 20 octobre 2026 :

Source : documentation des tarifs et des niveaux de service des fournisseurs, 20 octobre 2026. Prix par MTok, entrée / sortie. Chez OpenAI, Priority a été renommé Fast mode le 30 juillet. Le Flex de Google est en préversion. Chez Anthropic, le fast mode ne peut pas être utilisé avec l’API Batch.

La documentation d’Anthropic précise ce que le fast mode accélère : il augmente le nombre de tokens de sortie par seconde, pas le délai avant le premier token. Le modèle et son intelligence restent les mêmes. La différence se voit sur une longue réponse ou un long diff ; sur des questions courtes, vous la remarquerez à peine. Il y a un autre coût : les requêtes à des vitesses différentes ne partagent pas le cache. La documentation de Claude Code en tire la conséquence : la première fois que vous activez le fast mode dans une conversation, vous payez tout le contexte accumulé au prix du fast mode sans cache. Le moment le moins cher pour l’activer est donc le début de la session.

Voici où en sont les cinq outils :

• Claude Code : /fast l’active et le désactive. Sur Opus 5.5, la vitesse de sortie est jusqu’à 2,5 fois plus élevée, au prix de $8 / $40 par MTok. Avec les forfaits d’abonnement, il se paie sur les crédits d’usage (usage credits), pas sur la limite du forfait. Sur l’API, le fast mode d’Opus 5.5 est sorti de la research preview le 15 octobre ; la page fast mode de Claude Code indiquait encore « research preview » le 20 octobre 2026.
• Codex : /fast dans la CLI ; de façon permanente, service_tier = "fast", qui part dans la requête sous la forme priority. D’après la documentation, le fast mode consomme la limite d’abonnement à 2,5 fois le tarif standard, et les crédits achetés à 2 fois. Depuis le 8 octobre, GPT-6.1 Sol a aussi Ultrafast : 8 fois sur la limite, 6 fois sur les crédits ; seulement avec Pro $500 et les forfaits Enterprise et Edu éligibles.
• GitHub Copilot : pas d’interrupteur de vitesse pour tout l’outil ; la version rapide figure dans le sélecteur de modèle comme un modèle à part. « Claude Opus 4.8 (fast mode) » est en préversion depuis le 29 juin 2026 et coûte plus cher qu’Opus 4.8 standard ; avec Business et Enterprise, un administrateur doit l’activer.
• Cursor : Fast est une option à part dans le tableau des modèles ; sur des modèles comme Grok 4.7, on peut le choisir pour deux fois le prix. Il est désactivé avec le forfait Plus.
• Antigravity : la documentation ne dit rien d’un niveau de vitesse payant.

Le prix des niveaux bon marché, c’est l’attente ou le refus. Le niveau flex d’OpenAI peut renvoyer 429 sous charge ; ces requêtes ne sont pas facturées. Le Flex de Google ne fait pas passer de lui-même une requête au niveau standard quand la capacité est pleine ; il vous laisse la relancer. Pour un travail qu’une personne attend devant son écran, c’est une surprise ; pour un traitement par lots qui tourne la nuit, c’est la moitié du prix.

Plus d’effort donne-t-il un meilleur résultat ?

Jusqu’à un certain point. Nous avons regardé trois types de preuves : la mesure de l’éditeur lui-même, un index indépendant et nos propres journaux. Les résultats déclarés par l’éditeur sont signalés comme tels.

Le balayage d’effort de la documentation d’Anthropic sur les coûts, nous l’avons tracé dans l’article sur SWE-bench : sur un sous-ensemble de SWE-bench Pro qu’Anthropic a choisi lui-même, Opus 5.5 résout de plus en plus de tâches de low à xhigh, et le coût par tâche se multiplie. Le même document contient une idée plus utile : au lieu de tout lancer à un niveau élevé, lancer d’abord en low et ne refaire en high que les échecs. En low, 13 % des tâches ont échoué ; une fois celles-ci refaites en high, environ 97 % des tâches ont été résolues, pour environ $0,17 par tâche. Tout en high, le résultat était de 95,3 % pour $0,29. C’est un résultat déclaré par l’éditeur, sous deux conditions : il faut un signal qui indique l’échec (là, les tests du benchmark lui-même), et chaque tâche qui échoue au premier essai attend deux exécutions.

Du côté indépendant, le Coding Agent Index d’Artificial Analysis mesure le même modèle à chaque niveau d’effort, dans un outil de codage : 303 tâches, 3 essais par tâche. Les résultats du 20 octobre 2026 :

Source : Artificial Analysis, la page en ligne le 20 octobre 2026 ; un seul instantané. Chaque cellule donne le score de l’index et le coût moyen par tâche. La page ne donne pas d’intervalle de confiance ; quelques points d’écart peuvent être du bruit. Quand un modèle refuse pour des raisons de sécurité, un autre modèle peut terminer l’essai, et l’essai compte quand même : dans les lignes de Sonnet 5.5, c’est le cas de 18 à 45 essais sur 909. Les noms de niveaux sont calibrés pour chaque modèle séparément : lisez le tableau colonne par colonne, pas ligne par ligne.

Les trois modèles montrent trois choses différentes. Sonnet 5.5 progresse à chaque niveau, mais le coût par tâche passe de $0,48 en low à $14,19 en max ; la durée moyenne d’une tâche passe aussi d’environ 6 minutes à 87 minutes. Sur Haiku 5.5, max coûte 4,2 fois plus que xhigh, pour un score plus bas. GPT-6.1 Sol est presque plat d’un niveau à l’autre : 5,7 points séparent son score le plus bas de son score le plus haut.

Dans les mesures de l’éditeur aussi, le gain s’aplatit aux niveaux les plus hauts. D’après la system card d’Opus 5.5 (déclaré par l’éditeur), le modèle a obtenu 66,4 % sur Terminal-Bench 4.0 en xhigh et 64,8 % en max ; Anthropic considère l’écart comme du bruit (erreur standard ±2,6 points). Sur la même fiche, le meilleur score d’Opus 5.5 sur FrontierCode (54,6 %) est en medium ; au-dessus de medium le score baisse, et en max il revient en grande partie. FrontierCode pénalise les changements que la tâche ne demandait pas ; comment le modèle sort du périmètre à effort élevé, nous l’avons décrit dans l’article sur SWE-bench.

Dans nos propres journaux, nous avons vu autre chose. diffox est un outil de revue de code par IA ; nous avons fait tourner plusieurs fois le modèle Claude que nous utilisons sur les pull requests d’un jeu de benchmark public, en ne changeant que l’effort. Chaque exécution comprend les mêmes 100 appels au modèle. Comme les tokens de réflexion sont facturés dans les tokens de sortie, nous avons compté si un appel avait réfléchi en regardant si sa réponse contenait un bloc thinking :

En medium, aucun appel n’a réfléchi ; le modèle a écrit la réponse directement. En high, la plupart des appels ont réfléchi, en xhigh tous, et la sortie et la durée par appel ont grandi en conséquence. Avec l’adaptive thinking, l’effort change donc surtout le fait que le modèle réfléchisse ou non, plus que la durée de sa réflexion. La documentation d’Anthropic dit la même chose : en mode adaptatif, l’effort fixe à quelle fréquence et à quelle profondeur le modèle réfléchit ; aux niveaux bas, il peut sauter complètement la réflexion sur les problèmes simples. Un second jeu de benchmark a donné le même tableau : en medium, aucun des 200 appels n’a réfléchi, en high 88 sur 200. Nous n’avons essayé max que sur deux appels : les deux ont réfléchi, avec 61 470 et 83 150 tokens, 423 et 745 secondes par appel.

Que monter l’effort fasse détecter plus de bugs, nos journaux ne le montrent pas. Pour l’affirmer, il faut des exécutions répétées à chaque réglage ; nous avons une ou deux exécutions par réglage, et l’écart n’est pas plus grand que la variation habituelle entre deux exécutions. Pourquoi nous ne comptons pas le résultat d’une seule exécution comme un résultat, nous l’avons expliqué dans l’article sur le LLM-as-a-judge.

Quel réglage choisir pour quel travail ?

Les sources s’accordent : commencez par la valeur par défaut du modèle, et ne montez qu’en mesurant sur votre propre travail. OpenAI conseille de voir l’effort comme un bouton de réglage fin, pas comme le moyen principal de retrouver de la qualité. Google propose d’essayer les trois niveaux dans votre propre évaluation et de choisir le plus bas qui atteint votre exigence. Un résumé pour les travaux courants :

Les raisons derrière les cartes sont dans la documentation. La documentation de Claude Code prévient que max peut donner des rendements décroissants et trop réfléchir, et demande de le tester avant de le généraliser ; celle de Codex écrit aussi que la plupart des tâches n’ont besoin ni de Max ni d’Ultra. OpenAI cite la sécurité et la revue de code parmi les usages courants de xhigh, mais seulement quand votre propre évaluation montre un bénéfice clair. Les modes ultra servent quand vous pouvez découper le travail en parties qui ont du sens ; sur un seul problème difficile qu’on ne peut pas découper, il vaut mieux qu’un agent réfléchisse plus longtemps. Pour les bots de pull request et les jobs de CI, choisissez le niveau standard : flex peut refuser sous charge, et batch peut prendre des heures.

Trois autres habitudes aident :

• Ajoutez une consigne de périmètre. Si la sortie doit être un diff à merger, ajoutez au prompt une courte phrase qui demande au modèle de rester dans le périmètre de la tâche. D’après Anthropic, au-dessus de high, Opus 5 a fait plus de changements que la tâche n’en demandait, et avec cette consigne le score est revenu sur la plupart de ces tâches.
• Changez l’effort par message. Dans une longue session, changer le niveau à l’échelle de la requête invalide le cache. L’effort par message d’Anthropic et le configuration_update d’OpenAI changent le niveau en conservant le cache.
• D’abord le niveau bon marché, puis le cher. Si vous pouvez vérifier la sortie avec un test ou un vérificateur, lancer d’abord à un niveau bas et ne refaire à un niveau élevé que les échecs est revenu moins cher dans la mesure d’Anthropic que de tout lancer en high.