Claude Code utilise un effort moyen par défaut. Passer au maximum ne vous sauvera pas.
Grosse session de code. 60 messages. J'ai tapé /effort max trois fois, et trois fois j'ai tout planté. Résultat : "partially_achieved." Trois rounds de 25 minutes à regarder Claude tourner en rond pendant que ma vraie tâche restait là, intouchée.
Voici le truc. J'ai fait ce qu'il fallait faire. Claude Code suggère /effort medium à l'installation, je n'y réfléchis même pas, je passe direct en high. Parce que je ne peux pas griller tous mes tokens de toute façon, et parce que Boris Cherny (le mec qui a créé Claude Code) a dit d'utiliser toujours la config la plus performante.
Ça n'a rien arrangé. Parce que le problème n'a jamais été le niveau d'effort. C'était ce que je mettais devant. Et personne ne parle de cette partie. Les influenceurs préfèrent se féliciter mutuellement d'avoir trouvé la bonne position de curseur.
TLDR : /effort max ne compense pas un mauvais contexte. Mes données de 25 commandes effort le confirment. Les sessions qui ont réussi des tâches complexes du premier coup partagent toutes le même pattern d'ouverture : un plan structuré avant la première frappe. Changez votre défaut de medium à high, oui. Mais si c'est tout ce que vous changez, vous dépenserez plus de tokens à boucler sur les mêmes erreurs. La vraie séquence : plan structuré d'abord, puis effort max. Dans cet ordre.
Ce que Boris Cherny a compris avant nous tous, et ce que mes propres données de session ont confirmé après une semaine de tracking, c'est que le curseur est la dernière chose à toucher. Pas la première.
La Session Qui M'a Fait Douter du Curseur
Session 271c43dd. Je m'en souviens parce que /insights l'a signalée plus tard comme une de mes plus longues.
60 messages. Trois fois j'ai escaladé vers /effort max pendant la même session, espérant forcer le passage sur un bug d'image de couverture qui aurait dû être simple. Claude s'est enfoncé dans les problèmes de sync iCloud. Puis a pivoté sur les conflits de path fnm. Puis a plongé dans la résolution node_modules. Douze heures de contexte, et le modèle réfléchissait de plus en plus fort aux mauvaises choses.
Les couvertures n'ont jamais été réparées.
C'est comme combattre un boss dans un RPG où vous continuez à utiliser le même sort maxé, encore et encore, et le boss se soigne juste. À un moment vous devez vous arrêter et lire la vraie entrée du bestiaire. Le sort n'a jamais été le problème. Vous tapiez sur la mauvaise faiblesse.
Je n'avais pas le mauvais réglage. J'avais le mauvais couloir.
Cette réalisation fait bizarre, parce que ça veut dire que le truc que tout le monde s'occupe à optimiser (le curseur) est la dernière variable qui compte, pas la première.
Effort max dans le mauvais couloir, c'est juste pagayer plus vite.
Avant de comprendre ce qui répare vraiment ça, vous devez piger ce que le curseur est censé faire, et pourquoi même son créateur ne s'arrête pas là.
Le Créateur de Claude Code Tourne en Max. Mais Ce N'est Pas Son Vrai Move.
Boris Cherny est une sorte de demi-dieu pour moi. Moitié humain, moitié processus daemon qui n'arrête jamais de shipper.
Le mec shippe 20 à 30 pull requests chaque jour. Pas une seule ligne éditée à la main depuis novembre. Opus 4.6, extended thinking, maximum effort, toujours allumé. Avant Anthropic, il a passé 7 ans chez Meta à diriger la qualité du code sur Facebook, Instagram, WhatsApp et Messenger. Il a créé Claude Code tout seul en septembre 2024, en commençant par un chatbot terminal qui pouvait lui dire quelle musique il écoutait. Le tout était, selon ses propres mots, accidentel.
Son raisonnement pour toujours faire tourner le modèle le plus cher est contre-intuitif : c'est en fait moins cher. Sonnet a besoin de trois itérations pour tomber sur le bon résultat. Opus en a besoin d'une. Le coût total en tokens pour Opus finit plus bas malgré le prix par token plus élevé, parce que vous arrêtez de payer pour les boucles de correction. La plupart des gens regardent le prix par token et choisissent le modèle moins cher. Boris regarde le coût total par tâche terminée et choisit le plus malin.
Mais ça c'est la partie que tout le monde cite déjà de ses interviews. La partie qu'ils sautent, c'est ce qui se passe avant que tout ça compte.
Boris commence environ 80% de ses sessions en mode plan. Et le mode plan n'est pas un système d'orchestration sophistiqué. Il l'a décrit lui-même : tout ce que ça fait c'est injecter une phrase dans le prompt qui dit "please don't write any code yet." C'est tout. Il a codé la feature en 30 minutes un dimanche soir après avoir lu des issues GitHub où les utilisateurs faisaient déjà ça naturellement dans leurs prompts. Shippé lundi matin.
Le principe en dessous : une fois que le plan est bon, le code est bon. Ses mots, pas les miens. Et c'est probablement la chose la plus importante qu'il ait dite sur Claude Code que personne ne semble vraiment intérioriser. Le modèle, le niveau d'effort, l'extended thinking, tout ça vient après le plan. Toujours après.
Il a même dit que le mode plan a probablement une durée de vie limitée. Peut-être un mois. Parce qu'au final le modèle va juste comprendre tout seul quand planifier. Mais maintenant, dans cette fenêtre, le boulot de l'humain c'est de bien faire le plan. Le prep work avant de commencer à cuisiner. Tout le reste suit de là.
(À noter : Boris bosse chez Anthropic avec un accès privilégié au modèle. Il shippe à une vélocité que la plupart d'entre nous n'égaleront pas, et son workflow est optimisé pour la livraison haute vélocité de 20-30 PRs par jour. Le pattern se transfère à vos projets. Les chiffres exacts probablement pas.)
Boris fait effort max. Mais il fait mode plan d'abord.
21 Sur 25 : Ce Que Mes Commandes Effort Montrent Vraiment
Les chiffres bruts d'abord.
/insights a audité mes 25 dernières commandes effort depuis le 16 mars. 21 fois j'ai utilisé /effort max. Une fois /effort medium. Une fois /effort high. Deux vérifications. Je ne suis pas quelqu'un qui commence bas et escalade graduellement. Je vais direct au max sur tout ce qui a l'air même légèrement non-trivial.
Et maintenant, ça arrive partout. Anthropic vient officiellement de passer Opus 4.6 en "medium effort" comme défaut pour les abonnés Max et Team. Le post changelog a collecté plus de mille likes. Les devs partout découvrent que ce réglage existe et se ruent pour le monter. Comme l'a dit Todd Saunders : la plupart des gens qui utilisent Claude Code récupèrent peut-être 40% de ce que le modèle peut faire avec les défauts.
Donc oui. Changez le défaut. Cette partie est réglée.
Maintenant le chiffre qui compte vraiment : mes pires sessions, les marathons de 60 messages qui finissent en "partially_achieved," celles-là tournaient en /effort max aussi. Même position de curseur que mes meilleures sessions. Même modèle. Même extended thinking. La différence de résultat n'était pas le niveau d'effort.
C'est comme avoir deux cuisines avec exactement le même four professionnel. Un chef a fait le prep work en amont avec des contrats de prompt structurés. L'autre a juste monté la température et espéré le meilleur. Même four. Dîners très différents.
(Les données /insights ne loggent pas quel niveau d'effort est actif par tour de conversation, seulement quand vous tapez la commande slash. Donc cette analyse est basée sur des patterns observés, pas une corrélation directe effort-vers-résultat par message. Le pattern reste difficile à ignorer.)
21 fois effort max. Mes pires sessions aussi.
Qu'est-ce qui sépare les sessions qui one-shot de celles qui spiralent ? La réponse est apparue dans les sessions à 2 messages.
La Vraie Variable : Ce Qui Se Passe Avant de Taper la Tâche
Voici ce que mon historique de session révèle vraiment quand vous triez par efficacité.
Sessions où /effort max a changé le résultat : refactoring complexe avec tests de non-régression (session 8fd1e558). Écriture du squelette pour mon livre sur les contrats de prompt (session ae7d6686). Bugs architecturaux où Claude devait raisonner à travers plusieurs fichiers à la fois. Tâches avec une vraie ambiguïté où le raisonnement plus profond du modèle avait vraiment quelque chose d'utile à mâcher.
Sessions où /effort max n'a rien changé : mauvais contexte de repo ("non, le blog Astro, pas celui-ci"), dérive de scope où Claude a commencé à modifier des fichiers que je n'ai jamais mentionnés ("pourquoi tu as touché ollama, je n'ai pas demandé ça"), prompts d'ouverture ambigus où j'ai décrit ma frustration au lieu de décrire la tâche.
Et les sessions qui ont one-shot ? Les sessions de 2 à 4 messages qui ont résolu des tâches complexes du premier coup ?
Elles ouvrent toutes pareil.
"Implement the following plan:" suivi d'un bloc de contexte structuré.
Quatre de mes dix sessions les plus efficaces utilisent exactement ce préfixe. Une session à 2 messages avec un plan structuré surpasse systématiquement une session à 60 messages avec /effort max et pas de contexte initial. À chaque fois dans mes données. C'est même pas proche. Les sessions à 2 messages semblent presque ennuyeuses, comme regarder quelqu'un suivre une recette. Les sessions à 60 messages ressemblent à un raid sans tank et sans healer. Tout le monde a son DPS maxé mais le groupe wipe quand même.
La breakdown qui est sortie de ça n'est pas compliquée :
/effort max compte quand la tâche a une vraie ambiguïté architecturale. Plusieurs fichiers, dépendances non-évidentes, raisonnement qui nécessite de tenir plusieurs contraintes en parallèle. Pour ces tâches, effort max vaut le temps de réponse supplémentaire.
Un plan structuré en amont compte sur tout le reste. Features de routine, corrections de bugs, migrations, tout ce où vous savez à quoi le résultat devrait ressembler mais le modèle n'a pas assez de contexte pour aller dans la bonne direction.
Pour les tâches critiques, vous voulez les deux. Plan d'abord, effort max ensuite. Cette combinaison, c'est ce qui one-shot.
(Une mise en garde qui compte : "Implement the following plan:" marche quand le plan est vraiment structuré. Un plan vague plus effort max vous donne le même résultat qu'un prompt vague plus effort max. La qualité du plan est la variable, pas sa présence formelle.)
"Implement the following plan:" bat /effort max sans contexte. À chaque fois.
Ce que Boris appelle mode plan, ce que mes données appellent "Implement the following plan:", c'est le même principe. Et ça manque dans 90% des workflows Claude Code que je vois en ligne.
Changez le Défaut. Puis Changez Ce Que Vous Mettez Devant.
Le défaut medium est une décision qu'Anthropic a prise pour la gestion des coûts à l'échelle. Pas une recommandation pour votre workflow. Le changelog le confirme. Si vous êtes sur un plan Max ou Team et que vous tournez encore en medium, vous laissez de la capacité sur la table. Passez en high comme baseline. Réservez /effort max pour les tâches avec une vraie complexité architecturale, le genre où Claude doit raisonner à travers plusieurs fichiers et tenir plusieurs contraintes dans sa tête. Sur le travail mécanique (déploiements, pushs, migrations répétitives), high suffit et est nettement plus rapide.
Mais si changer le curseur est la seule chose que vous changez, vous dépenserez plus de tokens pour arriver à la même mauvaise réponse avec plus de confiance.
Garry Tan a optimisé la couche de review, attraper les erreurs après que Claude écrit le code. La plupart des devs optimisent le curseur, la puissance brute du modèle. Aucun des deux n'adresse le vrai goulot d'étranglement : ce que Claude comprend avant de commencer à bosser. La couche d'input. Celle qui détermine si toute cette puissance de traitement va dans la bonne direction ou dans un mur.
Trois trucs à retenir.
Un : changez le défaut de medium à high à l'installation. C'est une décision d'Anthropic pour gérer les coûts d'infrastructure, pas une recommandation pour votre workflow. Le changelog le confirme, c'est fait, suivant.
Deux : /effort max ne compense pas un mauvais contexte de départ. Mes 25 commandes le montrent. Boris Cherny le savait dès le début. C'est pour ça qu'il a codé le mode plan un dimanche soir avant même de parler de quel modèle utiliser.
Trois : la séquence qui marche est désespérément banale. Un plan structuré. "Implement the following plan:". /effort max. Dans cet ordre. C'est pas glamour. Mais c'est ce que mes sessions à 2 messages qui one-shot ont en commun, et ce que mes sessions à 60 messages n'ont pas.
Le curseur /effort est la dernière chose à toucher, pas la première.
Sources & liens
Boris Cherny sur les workflows Claude Code, le mode plan, et le paradoxe du coût Opus : YC Light Cone podcast, Pragmatic Engineer podcast, Lenny's Podcast (2025-2026).
Changelog Anthropic sur le défaut Opus 4.6 medium effort pour les abonnés Max/Team : @ClaudeCodeLog.
(*) La couverture est générée par IA. Le mode plan de Boris a aussi été généré en 30 minutes, donc au moins la couverture est en bonne compagnie.