Dompter Opus 5 : balayage d'effort, test de concision et guide officiel, mesurés

TL;DR

• Une vingtaine de minutes de réglages suppriment l'essentiel du bruit dont on se plaint avec Opus 5 : l'effort choisi par type de tâche, une règle de concision dans l'emplacement output style, le cadrage de périmètre du guide dans le system prompt, et chaque ligne "verify your work" supprimée des vieux fichiers d'instructions.
• L'effort n'est pas un bouton de verbosité. Il contrôle combien le modèle réfléchit et combien d'appels d'outils il fait, pas la longueur de la réponse visible. Le baisser pour faire taire le modèle, c'est actionner le mauvais levier.
• L'endroit où vit une règle de longueur compte plus que sa formulation : le preset Concise intégré a déplacé la sortie d'environ 6 pour cent, la même règle en hook ou dans le fichier d'instructions n'a rien changé, et une vraie règle dans l'emplacement output style a transformé un rapport en cinq sections en un paragraphe plus une liste de fichiers.
• Le sur-engineering se corrige en supprimant du texte, pas en en ajoutant. Purger les demandes de vérification et coller le cadrage de périmètre du guide a fait passer notre diff de référence de neuf fichiers à trois.
• Les efforts low et medium ont trouvé les deux mêmes vrais bugs que la passe extra-high sur notre diff de revue, pour environ un cinquième des tokens.
• Ce qu'aucun bloc de prompt ne répare : un modèle qui reconnaît une contrainte explicite et la contourne deux tours plus tard. Nous l'avons vu une fois en une semaine de sessions, et le guide n'a pas de section dessus.

Ce que disent les sources

La colère est réelle et mesurable. Le fil r/ClaudeCode intitulé "Opus 5 is insufferable" a dépassé 600 votes et 178 commentaires, et son auteur accuse le modèle de parler une nouvelle langue qu'il appelle "Unintelligiblish" s3. Sur X, un développeur a simplement posté une capture des commentaires de code générés par Opus 5 et a récolté 9,700 likes s6. Quand le créateur de Claude Code a défendu le modèle en public, la réponse qui l'interpellait a rassemblé 2,843 likes s7.

Trois changements sous le capot expliquent une bonne partie de ce que ressentent les utilisateurs. Le thinking est activé par défaut et ne peut être désactivé qu'à l'effort high ou en dessous ; la fenêtre de contexte passe à un million de tokens, par défaut et au maximum ; et le paramètre d'effort devient le réglage central, avec cinq niveaux, low, medium, high, xhigh et max, high étant le défaut s2. Le paramètre contrôle combien de tokens le modèle dépense à réfléchir, à appeler des outils et à répondre. À l'effort low, le modèle regroupe les appels d'outils, agit sans préambule et confirme en une phrase. À l'effort high, il multiplie les appels, explique son plan avant de toucher quoi que ce soit et commente ses changements en détail s2. Si cette seconde description ressemble à vos sessions, vous tournez sur le défaut depuis le premier jour. Un détail d'API à connaître : à xhigh et max, le thinking ne peut plus être désactivé, et la requête renvoie une erreur 400 si vous essayez s2.

Les quatre comportements dont tout le monde se plaint sont reproductibles à la demande. Verbosité : une question de deux phrases est revenue avec des sections, des sous-titres et des avertissements façon audit ; le commentaire le plus voté du fil décrit des annonces grandioses du genre "we discovered something that changes everything" suivies de dix minutes de commandes shell s3. Sur-engineering : un utilisateur rapporte un fichier de décisions de 7,000 lignes, et quand il a demandé un nettoyage, le modèle a retiré 1,200 lignes puis en a ajouté 600 pour documenter les suppressions s3. Élargissement du périmètre : vous demandez X, le modèle décide que le vrai sujet est Y et l'explique en huit paragraphes. Mauvaises nouvelles enterrées : un mur de texte qui dit que tout s'est bien passé, avec un astérisque aux trois quarts admettant que quelque chose a cassé s3.

Le guide officiel, "Prompting Claude Opus 5", répond au fil point par point. Sa phrase la plus importante : l'effort contrôle combien le modèle réfléchit, pas combien il parle ; baisser l'effort réduit le volume de thinking mais ne raccourcit pas de façon fiable la réponse visible s1. La longueur se demande en mots simples, avec une consigne de concision dans le system prompt. Le guide dit aussi quelque chose que peu attendent d'un éditeur : supprimez des instructions. Si votre fichier d'instructions contient "verify your work before answering" ou "add a final verification step", supprimez-le, car Opus 5 s'auto-vérifie déjà et ces lignes provoquent de la sur-vérification et des tokens brûlés s1. Le créateur de Claude Code l'a résumé de la même façon : Opus 5 a besoin de moins de prompting, pas de plus s5. Le reste du guide a une section par grief : narration de l'agent, longueur des fichiers générés, cadrage du périmètre, subagents, auto-correction, chacune avec le bloc de prompt exact à copier s1.

Pour la revue de code, le guide affirme que la précision de revue tient à bas niveau d'effort, ce qui permet une passe rapide et bon marché au commit et une passe approfondie plus tard s1. Il met aussi en garde contre "only report serious problems" : Opus 5 le prend au pied de la lettre et sous-rapporte, donc demandez tout et filtrez dans une seconde passe s1. Côté délégation, Opus 5 lance des subagents plus volontiers que ses prédécesseurs et chacun multiplie le coût ; le guide propose une instruction qui réserve la délégation aux gros travaux réellement parallèles s1, et Claude Code ajoute depuis la version 2.1.217 deux variables d'environnement, CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH et CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, dont les valeurs par défaut sont trois niveaux de profondeur et vingt agents simultanés s9.

La trouvaille sur l'emplacement vient d'un second fil. Un utilisateur de r/ClaudeCode a passé des jours à tester où une règle de concision fonctionne : le style de sortie Concise intégré n'a réduit la sortie que d'environ 6 pour cent, et la même consigne en hook ou en règle du fichier d'instructions n'a rien changé ; ce qui a marché, c'est une vraie instruction dans l'emplacement output style s4. Le même post donne le critère des règles qui ne se déclenchent jamais : une règle doit nommer un moment reconnaissable et une action concrète. "Keep the changelog up to date" ne se déclenche pas ; "when you modify a file under src/, add a line" si s4.

Mesures

Protocole : une correction de bug de référence et une petite fonctionnalité de notre propre dépôt, rejouées dans des sessions Claude Code neuves. L'effort était réglé par session avec /effort, --effort ou effortLevel dans settings.json s8. La règle de concision a été construite avec la formulation du guide (réponses courtes et ciblées, moins de réserves, résumé de haut niveau sauf demande de détail) s1. Coût de l'exercice : les quatre sessions du balayage ont consommé l'équivalent d'une grosse journée de travail sur un forfait à 20 dollars, et un utilisateur du fil rapporte que son forfait 20x tient à peine un week-end à l'effort high s3.

Verdict

À faire lundi

• Ouvrez votre fichier d'instructions et supprimez chaque ligne qui demande au modèle de vérifier, revérifier ou d'ajouter une étape finale de vérification.
• Réglez effortLevel dans le settings.json de votre dépôt quotidien sur medium, et gardez xhigh pour une branche de refactor afin de comparer.
• Écrivez une règle de concision à partir de la formulation du guide et mettez-la dans l'emplacement output style, pas dans un hook et pas dans le fichier d'instructions.
• Collez le bloc de cadrage de périmètre du guide dans votre system prompt : livrer ce qui a été demandé au périmètre prévu, signaler une meilleure approche en une phrase, poursuivre la tâche demandée.
• Lancez votre prochaine revue de code deux fois, une à low et une à xhigh, et comptez les vrais bugs de chaque passe avant de continuer à payer pour la passe profonde.
• Réécrivez toute règle qui ne se déclenche jamais pour qu'elle nomme un moment et une action, selon le modèle "when you modify a file under src/".
• Réglez CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH et CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS sous leurs valeurs par défaut pendant une semaine et surveillez votre facture de tokens.
• Gardez une contrainte stricte dans un prompt sur un dépôt sensible et vérifiez deux tours plus tard si le modèle la respecte encore.

Pour aller plus loin

• Lisez tout le guide "Prompting Claude Opus 5", pas seulement la section sur la verbosité : narration, longueur des fichiers générés, périmètre, subagents et auto-correction ont chacun un bloc prêt à copier s1.
• La page sur l'effort documente les cinq niveaux et l'erreur 400 quand le thinking est désactivé à xhigh ou max ; lisez-la avant de scripter l'effort par projet s2.
• La référence des settings montre où vivent effortLevel et les output styles pour que vos réglages diffèrent par dépôt s8.
• La documentation des subagents explique les plafonds de profondeur et de concurrence derrière les défauts 3 et 20 s9.
• Le post "How I got Opus 5 actually usable" contient la comparaison complète des emplacements, avec le chiffre d'environ 6 pour cent pour le preset Concise s4.
• Le fil "insufferable" vaut la peine d'être lu au-delà du commentaire le plus voté : l'histoire du fichier de décisions de 7,000 lignes et les rapports de contournement de contraintes sont dans les longues réponses s3.
• Le court échange sur X entre le créateur de Claude Code et ses détracteurs cadre en quelques lignes la position "less prompting, not more" s5.

Sources

• Prompting Claude Opus 5, Anthropic. À lire parce que : les blocs de prompt exacts pour chaque grief, et la phrase qui dit que l'effort n'est pas un réglage de longueur.
• Effort parameter, Anthropic. À lire parce que : les cinq niveaux, leur comportement, et la contrainte de thinking à xhigh et max.
• Opus 5 is insufferable, r/ClaudeCode. À lire parce que : le catalogue de comportements que vous reconnaîtrez, avec les retours sur le coût des forfaits dans les réponses.
• How I got Opus 5 actually usable, r/ClaudeCode. À lire parce que : le seul test emplacement par emplacement de l'endroit où une règle de concision fonctionne.
• Boris Cherny on Opus 5 prompting, X. À lire parce que : le cadrage du mainteneur lui-même, moins de prompting plutôt que plus.
• Screenshot of Opus 5 code comments, X. À lire parce que : l'image à 9,700 likes qui a rendu la plainte sur la verbosité grand public.
• Opus 5 output thread, X. À lire parce que : la réponse à 2,843 likes qui montre à quel point la défense n'a pas porté.
• Claude Code settings, Anthropic. À lire parce que : où effortLevel et les output styles sont stockés par projet.
• Claude Agent SDK: subagents, Anthropic. À lire parce que : le modèle de profondeur de lancement et de concurrence derrière les deux plafonds d'environnement.

FAQ

Baisser l'effort rend-il Opus 5 plus court ?

Non. L'effort réduit le volume de thinking et d'appels d'outils, pas la réponse visible. La longueur vient d'une consigne de concision explicite, et l'emplacement output style est celui où elle a fonctionné dans nos tests.

Dois-je plutôt changer de modèle ?

Si votre grief est le bruit et le sur-engineering, faites d'abord le réglage de vingt minutes : l'écart se voit dès le premier diff. Si votre grief est un modèle qui ignore les contraintes explicites, rien dans le guide ne le corrige ; gardez les tâches sensibles sur un modèle qui obéit et retestez à la prochaine mise à jour.

Ces réglages sont-ils portables ?

Non. L'output style, le cadrage de périmètre et les plafonds de subagents vivent dans votre config, donc chaque machine et chaque projet doit être réglé de nouveau.

Combien coûte le balayage d'effort ?

Nos quatre sessions de test ont utilisé l'équivalent d'une grosse journée de travail sur un forfait à 20 dollars. Lancez-le une fois sur une tâche de référence, puis choisissez un défaut par dépôt.