Claude Opus 4.8 : un modèle qui rattrape ses propres bugs

Anthropic a publié Claude Opus 4.8 le 28 mai 2026, et la phrase qui mérite d’être lue lentement est celle-ci : le modèle est “around four times less likely than its predecessor to allow flaws in code it has written to pass unremarked”. C’est une amélioration mesurée, pas un slogan marketing, sur la métrique qui compte le plus quand on shippe du code généré : la fréquence à laquelle le modèle laisse passer ses propres bugs. Le reste du release, subagents parallèles dans Claude Code, défauts d’effort déplacés, mid-conversation system messages, découle de cette même direction : un modèle plus discipliné, qu’on doit moins surveiller, et qui prend plus d’initiative quand on le laisse faire.

Trois changements méritent qu’on adapte ses habitudes. Le reste est incrémental.

Les chiffres derrière la sensation

Avant le récit pratique, les nombres. Anthropic publie quatre repères qui cadrent ce dont on parle :

Terminal-Bench 2.1 : 92,3 %. C’est la suite qui mesure la capacité à conduire une session shell complète, installer des dépendances, parser des erreurs, corriger un build. C’est là qu’Opus 4.8 est sans équivalent au moment de la sortie.
OSWorld-Verified : 84,2 %. Tâches d’agent navigateur et de manipulation d’environnement de bureau. C’est le score “agent assis devant un OS”.
Online-Mind2Web : 84 %. Tâches de navigateur en ligne, formulaires, requêtes, suivi de processus multi-pages.
Super-Agent benchmark : 100 % de complétion. Anthropic décrit 4.8 comme “the only model to complete every case end-to-end” sur cette suite.
Legal Agent Benchmark : premier modèle au-dessus de 10 % au standard “tout-passe” (chaque sous-tâche doit réussir).

Ce qui mérite d’être noté : Anthropic positionne 4.8 comme battant “GPT-5.5 at parity on cost” sur Super-Agent. Ce n’est pas qu’un benchmark de qualité ; c’est un benchmark de qualité-par-dollar, et c’est la première fois depuis longtemps qu’un release d’Opus est positionné en frontière de Pareto plutôt qu’en plafond de qualité.

Trois choses ne sont pas mises en avant dans le release et c’est notable. SWE-bench n’est pas le chiffre headline (Terminal-Bench le remplace, ce qui dit quelque chose de la maturation des benchmarks de code). Aucun pourcentage de “gain par rapport à 4.7” sur les benchmarks classiques de raisonnement pur. Et aucune comparaison avec Sonnet 4.6 dans le release, Anthropic semble assumer que la lecture se fait dans la verticale Opus.

Le défaut d’effort descend de `xhigh` à `high`

Sur Opus 4.7, le défaut recommandé était xhigh. Sur 4.8, il est high, sur toutes les surfaces (Claude API, Claude Code).

The effort parameter default on Claude Opus 4.8 is high on all surfaces, including the Claude API and Claude Code.

Pas parce que le modèle est moins capable, l’inverse. Anthropic dit explicitement que la calibration par niveau est désormais plus fiable : “reasoning effort calibration, with more reliable behavior at each effort level across a range of domains”. Concrètement : high sur 4.8 fait ce que xhigh faisait sur 4.7, pour moins de tokens.

Si vous aviez fixé manuellement xhigh, votre réglage reste actif. Sinon, vous êtes passé à high automatiquement. Le réflexe à avoir avant de remonter à xhigh : essayez la tâche au défaut une fois. Sur les cas que j’ai testés cette semaine, la baisse de tokens à qualité égale est nette.

Quatre fois moins de défauts laissés passer

C’est la statistique qui change le plus la façon de l’utiliser :

Opus 4.8 is around four times less likely than its predecessor to allow flaws in code it has written to pass unremarked.

Et la formulation qui va avec, sur le comportement agentique dans Claude Code :

Better judgment. In Claude Code, it asks the right questions, catches its own mistakes, pushes back when a plan isn’t sound.

C’est exactement le type d’amélioration qui transforme un assistant en relecteur. Sur 4.7, mon réflexe en review d’un diff généré était de chercher activement les chemins d’erreur muets, que va-t-il avoir manqué ?. Sur 4.8, le modèle écrit lui-même “je ne suis pas certain de ce comportement, je propose un test pour vérifier” avec une régularité que je n’avais pas vue auparavant.

Ça ne supprime pas la revue humaine. Ça déplace ce qu’on cherche : moins les erreurs muettes, plus les choix d’architecture que le modèle ne peut pas évaluer. C’est aussi un argument concret pour traiter les modèles comme des composants à privilèges scopés, un modèle qui flag ses propres incertitudes est plus utilisable dans un agent automatisé.

L’amélioration ne s’arrête pas au catch des bugs de code. Le release note un “reaches new highs on measures of prosocial traits like supporting user autonomy” et un taux de désalignement “substantially lower” qu’Opus 4.7, à un niveau qu’Anthropic décrit comme “similar to Claude Mythos Preview”. Pour qui suit la trajectoire d’alignement, c’est la première fois qu’un modèle production-ready de la lignée Opus est posé au même niveau qu’un modèle de recherche. La conséquence pratique : la marge de confiance qu’on peut accorder à 4.8 dans une boucle agentique non supervisée est qualitativement différente, pas infinie, mais déplacée vers le haut.

Dynamic workflows : la parallélisation devient massive

Le mot “subagent” change d’échelle sur 4.8. Anthropic décrit Claude Code 4.8 comme capable de :

run hundreds of parallel subagents in a single session

avec pour cas d’usage cité :

codebase-scale migrations across hundreds of thousands of lines of code

Ce n’est pas un raffinement de l’orchestration existante : c’est un changement de design. Sur 4.7, et c’est ce que j’ai écrit ce matin, il fallait demander la parallélisation explicitement et le modèle restait conservateur. Sur 4.8, les dynamic workflows font de la décomposition agressive un comportement par défaut quand le travail s’y prête.

Trois conséquences pratiques :

La mémoire partagée entre subagents redevient un problème de premier ordre. Cent subagents en parallèle qui ne se voient pas peut être pire que dix subagents qui se coordonnent. Le sujet du wiki qu’on partage entre eux, qu’on a abordé pour les agents humains avec la fragmentation mémoire, vaut littéralement à l’échelle de la session.
Le brief initial pèse encore plus lourd. Un agent qui spawn cent enfants à partir d’une consigne floue produit cent dérives. Anthropic insiste sur la dépendance au premier tour ; sur 4.8, c’est multiplié.
L’observabilité doit suivre. Cent subagents qui modifient le repo en parallèle, c’est cent diffs à comprendre. La discipline de log par subagent et de PR atomique devient un prérequis, pas une bonne pratique.

L’autre amélioration silencieuse qui rend ces sessions massives tenables : Anthropic cible explicitement un meilleur long-horizon avec “better long-context handling, fewer compactions, and better compaction recovery”. Sur 4.7, une session agentique de plusieurs heures dérivait souvent après une compaction, le modèle perdait le fil de ce qu’il faisait. Sur 4.8, la compaction est moins fréquente et la reprise post-compaction préserve mieux la tâche en cours. Pour un claude -p qui tourne la nuit, c’est la différence entre revoir vingt commits cohérents et trier les dérives.

Mieux déclencher les outils, la régression de 4.7 est corrigée

Un point que les release notes mentionnent mais qui mérite d’être isolé : Opus 4.7 avait un défaut signalé par les utilisateurs, il sautait parfois un appel d’outil que la tâche exigeait. Le modèle “réfléchissait” la réponse au lieu d’aller chercher l’information.

Anthropic dit explicitement que 4.8 corrige ça :

Better tool triggering. The model is less likely to skip a tool call the task required, an issue some users reported on Claude Opus 4.7.

Concrètement, sur un agent qui doit Read avant d’éditer, ou Bash avant de déclarer un test cassé, le taux de “raté silencieux” baisse. Si vous aviez rajouté des instructions défensives en CLAUDE.md (“toujours lire le fichier avant de proposer un edit”), elles deviennent moins critiques, mais je ne les retirerais pas par précaution, le coût d’un appel d’outil défensif étant nul.

Mid-conversation system messages : petit détail d’API, gros impact

Le release contient un changement d’API qui n’a pas la une mais qui change les boucles agentiques longues : Opus 4.8 accepte désormais role: "system" après un tour utilisateur dans le messages array. Aucune en-tête beta requise.

L’effet pratique :

This lets you append updated instructions later in a long-running conversation without restating the full system prompt, which preserves prompt cache hits on the earlier turns and reduces input cost on agentic loops.

Concrètement, vous pouvez raffiner les instructions au milieu d’un run de plusieurs heures sans casser le cache. Sur un agent qui tourne en claude -p toute la nuit, c’est la différence entre payer chaque tour plein tarif et payer le cache. Combiné au minimum de cache qui descend à 1 024 tokens (contre plus haut sur 4.7), c’est un vrai gain de coût pour les workloads agentiques.

L’autre ajout discret qui sert les agents en production : l’objet stop_details sur les refus est désormais documenté publiquement. Quand Claude décline une requête, le stop_reason: "refusal" s’accompagne d’une catégorie qui dit pourquoi. Pour qui route les refus vers une UI différente selon la classe (politique de contenu, demande hors périmètre, manque de contexte), c’était jusqu’ici un comportement non-stable. Il est maintenant contractuel, pas de beta header, pas de risque de breaking change silencieux.

Fast mode et le contrat tarifaire qui ne bouge pas

Le release contient aussi un changement de plomberie qui n’avait pas son équivalent sur 4.7 : fast mode est ouvert en research preview sur l’API Claude pour 4.8. On l’active avec speed: "fast" et on obtient jusqu’à 2,5× de tokens de sortie par seconde, sur le même modèle, au tarif premium.

La grille concrète vaut la peine d’être posée :

Standard. 5 $ / million de tokens en entrée, 25 $ / million en sortie. Inchangé depuis Opus 4.7.
Fast mode. 10 $ / million en entrée, 50 $ / million en sortie. 2,5× plus rapide.

Le double signal, meilleure qualité, prix identique, est ce qu’Anthropic met en avant pour positionner 4.8 comme un upgrade gratuit pour la facture mensuelle de quiconque tourne déjà en Opus. Pour les charges latency-sensitives (assistant interactif, agent qui doit répondre en quelques secondes), fast mode ajoute une option payante qui n’existait pas avant. La décision est binaire : si la latence vous coûte de l’utilisateur, le 2× de prix est négligeable ; sinon, n’y touchez pas.

À noter aussi sur le contrat technique : 1M de tokens de contexte par défaut sur l’API Claude, Amazon Bedrock et Vertex AI (200k sur Microsoft Foundry), 128k tokens max en sortie. Les paramètres de sampling (temperature, top_p, top_k) restent verrouillés à leur défaut, comme sur 4.7, le contrôle passe par le prompt et par le paramètre effort.

Ce que ça change pour vos évals

Un modèle qui catch ses propres erreurs change ce qu’on doit mesurer.

Mon ancien set d’évals testait : est-ce que le modèle écrit le bon code ?. Sur 4.8, la question devient : est-ce qu’il signale quand il ne sait pas ?. Les évals binaires (réussi/échoué) sous-mesurent l’amélioration, il faut des évals qui notent séparément la qualité du code et la calibration de la confiance affichée.

C’est aussi une amélioration qu’on perd si on ne la mesure pas. Le réflexe utilisateur de couper court (“réponds vite, pas de blabla”) va supprimer le comportement qui justifiait la moitié de l’upgrade. Si vous écrivez un système prompt qui dit “sois concis, ne pose pas de questions”, vous reculez 4.8 vers 4.7.

Le résumé, pour mon usage : garder high comme défaut, réécrire le prompt système pour autoriser le modèle à signaler ses incertitudes, scoper les subagents avec une couche mémoire commune, et profiter du mid-conversation system message pour les claude -p longs. Quatre disciplines. Pas un changement de méthode.

Si cela vous a parlé, vous aimerez Claude Opus 4.7 dans Claude Code : ce qui change vraiment et Mémoire partagée entre agents IA : la fragmentation est un choix. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.