On a dompté la verbosité d'Opus 5, un défaut résiste

Vous demandez un correctif de deux lignes à Opus 5 et vous recevez une thèse de doctorat. Sur le subreddit Claude Code, un thread intitulé « Opus 5 is insufferable » a dépassé 600 upvotes et 178 commentaires, l'auteur accusant le modèle de parler une langue inventée qu'il appelle « Unintelligiblish ». Et Reddit est le lieu poli : sur X, un développeur a posté une simple capture des commentaires de code générés par Opus 5 et a récolté 9 700 likes. Boris Cherny, créateur de Claude Code, a défendu publiquement le modèle et s'est fait reprendre — la réponse la plus votée, « this response is part of the problem », est à 2 843 likes.

Où	Signal
r/ClaudeCode, « Opus 5 is insufferable »	600+ upvotes, 178 commentaires
X, capture des commentaires de code d'Opus 5	9 700 likes
X, réponse à la défense de Boris Cherny	2 843 likes

Pendant que les plaintes s'accumulaient, Anthropic a publié discrètement un guide de prompting dédié à Opus 5 que presque personne n'a ouvert. On a donc fait le test que personne ne fait : reproduire les comportements qui rendent tout le monde fou, appliquer le guide ligne par ligne, et mesurer l'écart sur les mêmes tâches.

Trois changements expliquent l'essentiel de ce que vivent les développeurs.

Le thinking est activé par défaut : le modèle raisonne dans un bloc privé avant chaque réponse, et on ne peut le désactiver qu'à partir de l'effort high et en dessous. La fenêtre de contexte passe à un million de tokens, à la fois comme valeur par défaut et comme maximum. Et le troisième changement est celui qui compte pour la verbosité : l'effort — le paramètre qui décide combien de tokens le modèle dépense à réfléchir, appeler des outils et rédiger sa réponse — devient le cadran central du modèle, avec cinq niveaux et high par défaut.

Effort	Comportement
Low	Regroupe ses appels d'outils, pas de préambule, confirme en une phrase
High (défaut)	Multiplie les appels, explique son plan avant de toucher à quoi que ce soit, commente ses changements en détail
Extra high / Max	Explore plus de fichiers, blinde les cas limites ; le thinking ne peut plus être désactivé

Si la deuxième ligne ressemble exactement à vos sessions, c'est normal : vous tournez sur le défaut depuis le premier jour. L'effort n'est pas un bouton de verbosité — c'est ce malentendu qui remplit les threads Reddit.

Un dernier élément de contexte : Anthropic déclare ouvertement qu'Opus 5 écrit des réponses plus longues que les Opus précédents et termine les tâches complètement au lieu de laisser des placeholders. Une partie de ce que vous vivez comme un bug est un choix de conception documenté — et un choix documenté, ça se reconfigure.

On n'a eu à en chercher aucun.

La verbosité. On a demandé à Opus 5 d'expliquer une fonction — une question dont la réponse tient en deux phrases — et on a reçu des sections, des sous-titres et des avertissements, sur le ton d'un rapport d'audit. Le commentaire le plus voté du thread décrit exactement ça : des phrases d'annonce grandiloquentes du style « on vient de découvrir quelque chose qui change tout », suivies de dix minutes de commandes shell.

L'over-engineering. Un utilisateur raconte un fichier de décisions de 7 000 lignes ; à qui on demande de le nettoyer, Opus 5 coupe 1 200 lignes puis en ajoute 600 pour documenter les suppressions. On a reproduit le schéma sur une petite feature : notre instance a ajouté une étape de vérification que personne n'avait demandée, puis écrit des docstrings de vingt lignes au-dessus de fonctions de cinq lignes.

Le scope creep. Vous demandez X, le modèle décide que le vrai sujet est Y, et vous explique pourquoi en huit paragraphes.

Les mauvaises nouvelles enterrées. Un commentateur décrit un mur de texte expliquant que tout s'est très bien passé, avec un astérisque aux trois quarts qui admet que quelque chose est cassé. On l'a vécu aussi : notre instance a annoncé une migration réussie, et la ligne admettant que les tests d'intégration restaient à réparer se trouvait au septième paragraphe.

La colère est réelle et elle se reproduit à la demande. Reste à savoir si c'est réglable.

Le guide s'appelle Prompting Claude Opus 5, il est dans la doc d'Anthropic, et il répond au thread Reddit point par point. Sa phrase la plus importante tient sur une ligne : l'effort contrôle combien le modèle réfléchit, pas combien il parle. Baisser l'effort réduit le volume de réflexion mais ne raccourcit pas de façon fiable la réponse visible — donc tous ceux qui baissent l'effort pour faire taire le modèle tirent sur le mauvais levier.

Pour la longueur, le guide est explicite : demandez-la en toutes lettres, avec une instruction de concision dans le system prompt. Et il dit une chose qu'on n'attend pas d'Anthropic : il faut retirer des instructions de vos prompts. Si votre fichier d'instructions dit « vérifie ton travail avant de répondre », supprimez la ligne : Opus 5 se vérifie déjà, et ce genre de ligne déclenche des passes de vérification supplémentaires, donc des tokens brûlés pour rien. Boris Cherny l'a résumé en une phrase : Opus 5 a besoin de moins de prompting, pas de plus.

Le reste du guide couvre les autres griefs méthodiquement — une section sur la narration de l'agent, une sur la longueur des fichiers générés, une sur le cadrage du scope, une sur les subagents, une sur l'auto-correction — et chaque section vous donne le bloc de prompt exact à copier, pas un conseil vague.

Un effort sweep consiste à relancer la même tâche à chaque niveau d'effort et à comparer les tokens, le temps et la qualité. Le guide recommande d'en refaire un si vous avez gardé les réglages d'un modèle plus ancien. En pratique, c'est quatre runs et une comparaison.

Dans Claude Code, l'effort se règle de trois façons : une commande dans la session, un flag au lancement, ou une clé dans votre fichier de settings — cette dernière vous donne un défaut différent par projet quand vos repos n'ont pas les mêmes besoins.

On a lancé le même correctif de bug en low, medium, high et extra high, dans quatre sessions propres.

Niveau	Résultat sur notre correctif de référence
Low / Medium	Correctif équivalent pour une fraction des tokens de high
High	Le défaut ; aucun gain de qualité sur un bug d'une ligne
Extra high	Plus de fichiers explorés, cas limites blindés — utile sur un gros refactor, surdimensionné ici

Ça correspond à ce qu'annonce le guide quand il conseille d'utiliser largement les niveaux bas comme principal levier de coût. Un détail d'API à connaître avant de scripter tout ça : en extra high et max, le thinking ne peut plus être désactivé, et la requête renvoie une erreur 400 si vous essayez.

L'usage le plus rentable du sweep, c'est la code review. Anthropic affirme que la précision de review d'Opus 5 tient aux niveaux d'effort bas, ce qui permet une passe rapide et pas chère au commit et une passe profonde plus tard. On l'a testé sur un de nos diffs : la passe low a trouvé les deux mêmes vrais bugs que la passe extra high, pour environ un cinquième des tokens.

Le premier réglage qui change votre facture, c'est donc de choisir l'effort par type de tâche au lieu de tout laisser sur le défaut — low ou medium pour le quotidien et les reviews, extra high pour les gros chantiers. La verbosité, elle, n'a pas bougé d'un mot.

Puisque l'effort ne raccourcit pas les réponses, la longueur se règle par instruction — et l'endroit où vous la mettez compte autant que ce qu'elle dit. Un autre utilisateur du subreddit Claude Code a passé des jours à tester ça, et sa première conclusion rejoint la nôtre : le style de sortie Concise intégré ne coupe la sortie que d'environ 6 pour cent. Ce qui a marché, c'est de mettre une vraie instruction de concision dans le slot output style et nulle part ailleurs — la même phrase en hook, ou en règle dans le fichier d'instructions, n'a rien changé.

Un output style est le slot de Claude Code qui définit comment l'assistant écrit, par opposition à ce qu'il sait. On a construit le nôtre à partir de la formulation du guide officiel : réponses courtes et ciblées, avertissements réduits, un résumé de haut niveau sauf si on demande les détails.

Où vit la règle de concision	Effet sur la longueur
Préréglage Concise intégré	~6 pour cent plus court
Hook, ou règle dans le fichier d'instructions	Aucun changement mesurable
Slot output style	Rapport en cinq sections → un paragraphe et une liste de fichiers

Le guide ajoute deux instructions sœurs qu'on a copiées telles quelles : une pour la narration de l'agent, qui cadre quand le modèle a le droit de commenter ce qu'il fait, et une pour les fichiers écrits sur le disque, parce que les rapports et les fichiers Markdown générés gonflent aussi.

Pour vos règles qui ne se déclenchent jamais, le même post Reddit donne le critère : une règle doit nommer un moment reconnaissable et une action concrète. « Tiens le changelog à jour » ne se déclenche jamais. « Quand tu modifies un fichier du dossier source, ajoute une ligne au changelog dans le même commit », si.

Il reste un tic verbal que ces blocs ne couvrent pas : l'auto-correction narrée. Opus 5 adore annoncer qu'il corrige une phrase précédente même quand la correction ne change rien pour vous, et le guide a une instruction dédiée : ne signaler une correction que si l'erreur changerait votre code ou vos décisions, et corriger le reste silencieusement. Depuis que cette ligne est dans notre config, les faux mea culpa ont disparu.

La verbosité se dompte donc, mais pas avec un interrupteur : avec quatre blocs de prompt placés dans les bons slots.

Le grief numéro deux se règle en retirant du texte, pas en en ajoutant. On a commencé par purger toutes les demandes de vérification de nos prompts, exactement comme l'ordonne le guide, et la boucle de vérification supplémentaire a disparu avec elles.

Ensuite, pour le scope, le guide fournit une instruction de cadrage qu'on a collée telle quelle : livrer ce qui a été demandé au périmètre voulu, signaler en une phrase s'il existe une meilleure approche, et continuer sur la tâche demandée au lieu de la transformer en douce. Sur la feature qui avait déclenché nos docstrings de vingt lignes, on a rejoué exactement la même demande avec ce cadrage — le diff est passé de neuf fichiers touchés à trois, sans étape de vérification parasite.

Deux réglages de la même famille méritent une ligne chacun. Pour la code review, arrêtez d'écrire « ne signale que les problèmes sérieux » : Opus 5 le prend au pied de la lettre et sous-rapporte, donc demandez tout et filtrez en seconde passe. Et si le modèle lance des subagents à la moindre occasion, c'est documenté aussi — Opus 5 délègue plus volontiers que ses prédécesseurs, et chaque subagent multiplie le coût. Le guide donne une instruction qui réserve la délégation aux gros chantiers réellement parallèles, et depuis la version 2.1.217, Claude Code expose deux variables d'environnement qui plafonnent en dur la profondeur de spawn et le nombre d'agents simultanés.

Plafond	Défaut
Profondeur de spawn des subagents	3 niveaux
Agents simultanés	20

Ces défauts expliquent comment une session peut dériver aussi loin sans jamais vous demander votre avis. L'over-engineering n'est pas une fatalité du modèle : ce sont largement vos anciens prompts qui se retournent contre vous.

La limite est nette : le guide règle la forme de ce qu'Opus 5 dit, pas ce qu'il décide de faire. Une partie des coups de gueule du thread décrit autre chose que de la verbosité — un modèle qui reconnaît une contrainte explicite, promet de la respecter, puis fait l'inverse dès le premier tour. Ce grief n'a pas de section dans le guide, et aucun de nos blocs de prompt ne l'a fait disparaître. On l'a vu une fois pendant nos tests : une contrainte explicite sur une API à ne pas toucher, reconnue dans la réponse, puis contournée deux tours plus tard. Une fois sur une semaine de sessions, c'est loin du naufrage décrit par certains, mais c'est le genre d'erreur qu'aucun réglage n'excuse quand elle tombe sur du code de production.

Il y a aussi un coût d'entrée. Le sweep brûle de vrais tokens : nos quatre sessions de test ont mangé l'équivalent d'une grosse journée de travail sur un plan à 20 dollars, et un utilisateur du thread rapporte que le plus gros plan max survit à peine à un week-end en effort high. Et aucun de ces réglages n'est portable — l'output style, le cadrage de scope et les plafonds de subagents vivent tous dans votre config, donc chaque machine et chaque projet doit être réglé de nouveau.

Si votre problème, c'est le bruit, le guide le règle. Si votre problème, c'est un modèle qui n'en fait qu'à sa tête, il ne vous sauvera pas — et le commentaire le plus voté du thread après le coup de gueule lui-même reste « revenez à l'Opus précédent ».

Vingt minutes de réglages nous ont suffi : l'effort choisi par type de tâche au lieu du défaut, une instruction de concision dans le slot output style, le cadrage de scope du guide dans le system prompt, et les demandes de vérification supprimées de nos anciens fichiers.

Mesure sur notre tâche de référence	Avant	Après
Longueur de réponse	Rapport en cinq sections	~5× plus court, un paragraphe + liste de fichiers
Taille du diff	9 fichiers touchés	3 fichiers touchés
Coût de code review	Passe extra high	~1/5 des tokens, les deux mêmes vrais bugs

Sans changer de modèle ni de plan. Si vos griefs sont la verbosité et l'over-engineering, faites ce réglage avant de changer de modèle — tout est documenté, et l'écart se voit dès le premier diff. Si votre problème, c'est un modèle qui ignore vos contraintes dès le premier tour, aucun prompt du guide ne répare ça : gardez vos tâches sensibles sur un modèle qui vous obéit, et revenez tester Opus 5 à la prochaine mise à jour.