Claude Opus 4.8 : prix, nouveautés et activation

Documentation de référence Ailoot : ailoot.ai/docs/.

Ce qui est sorti dans Claude Code le 28 mai#

Le 28 mai, Anthropic a lancé Opus 4.8, 41 jours après Opus 4.7. Claude Code v2.1.154 et l’article de blog « Introducing dynamic workflows in Claude Code » sont sortis le même jour. Le lendemain, v2.1.156 a corrigé un bug lié aux thinking blocks qui faisait échouer l’API avec Opus 4.8.

Quatre changements qui concernent toute personne qui code avec Claude Code :

1. Le nouveau modèle Opus 4.8 — les mêmes tarifs ($5/$25 par million de tokens), mais de meilleurs résultats aux benchmarks et il manque 4 fois moins souvent des bugs dans son propre code.
2. Dynamic Workflows — Claude écrit un script JS pouvant lancer jusqu’à 1000 sous-agents sur une exécution, avec 16 actifs au maximum à la fois. Le déclencheur est le mot workflow dans le prompt.
3. xhigh effort — un nouveau niveau de raisonnement. Par défaut, Opus 4.8 est désormais en high ; pour les tâches exigeantes, vous pouvez passer à xhigh.
4. Fast Mode est devenu 3 fois moins cher — il coûtait 6× le tarif standard ; il coûte désormais 2× pour une vitesse multipliée par 2,5.

Anthropic elle-même présente cette sortie avec retenue :

Dans ce guide, je vais montrer exactement ce qui a changé, combien cela coûte en pratique et s’il vaut mieux passer à cette version maintenant ou attendre.

En quoi Claude Opus 4.8 diffère-t-il d’Opus 4.7 ?#

Les chiffres en hausse

Anthropic a publié les benchmarks dans son annonce officielle et dans la Claude API Docs. Tableau récapitulatif :

⚠️ Ce sont des chiffres publiés par le fournisseur — des chiffres d’Anthropic, pas une mesure indépendante.

La principale promesse : « 4× moins susceptible de manquer des bugs »

Anthropic affirme :

Cela semble formidable, mais il y a une nuance sous-jacente : selon la System Card d’Anthropic, Claude Opus 4.8 a affiché le taux de réponses incorrectes le plus bas parmi six modèles sur chacun des benchmarks, parce qu’il s’abstient lorsqu’il n’est pas sûr.

Traduction du langage de la System Card en langage de vibe coder : le modèle n’est pas devenu 4 fois plus intelligent. Il est devenu plus enclin à dire « Je ne suis pas sûr, vérifie » au lieu de produire une hallucination plausible. De l’honnêteté plutôt qu’une hausse de QI : voilà son évolution.

En pratique, cela signifie que pour les mêmes tâches où Claude avait l’habitude de mentir avec assurance, il dira maintenant : « Je ne suis pas sûr de ça. » Cela réduit le risque, mais n’augmente pas la couverture.

Ce qui n’a pas changé

• Le tarif standard ($5 par million de tokens en entrée, $25 par million de tokens en sortie) — inchangé.
• La date limite des connaissances — janvier 2026, comme pour 4.7.
• Le contexte par défaut — 1 million de tokens sur l’API Anthropic, AWS Bedrock et GCP Vertex AI. Sur Microsoft Foundry — 200K.
• La sortie maximale — 128K tokens.
• Les paramètres d’échantillonnage (temperature, top_p, top_k) — toujours non pris en charge ; ils renvoient une erreur 400.

Les points faibles d’Opus 4.8

Pour être honnête : sur Terminal-Bench 2.1, Opus 4.8 obtient 74,6 % — ce n’est pas mauvais, mais il ne domine pas la catégorie. Si la majeure partie de votre travail se fait dans le terminal, gardez-le en tête : Codex est souvent un peu plus performant sur les tâches exclusivement réalisées dans le terminal. Opus 4.8 devance les autres modèles sur les autres benchmarks, mais cette différence est réelle.

Deuxième point sans détour : sur les pipelines agentiques complexes avec des entrées non vérifiées (analyse de sites web, lecture de flux RSS), la protection contre les injections de prompt dans Opus 4.8 n’est pas garantie. Si vous créez une automatisation qui lit les documents d’autrui, conservez un assainisseur distinct pour les entrées.

Combien coûte Opus 4.8 en 2026 ?#

Grille tarifaire

Le tarif standard est resté le même que pour 4.7 et 4.6. C’est rare : les nouvelles générations coûtent généralement plus cher. Fast Mode est devenu 3 fois moins cher : sur 4.6 et 4.7, le mode rapide coûtait 6× le tarif standard. Sur 4.8, il coûte 2×.

Ce que cela représente par heure de travail

Une heure de codage actif dans Claude Code avec Opus 4.8 représente environ 1 à 2 millions de tokens en entrée et 100 à 300 mille tokens en sortie. Aux tarifs standard, cela revient à $5–10 pour l’entrée et $2,5–7,5 pour la sortie. En arrondissant, cela fait $8–15 par heure pour l’API seule.

Avec les abonnements :

• Pro ($20/mois) — assez pour 1 à 2 heures de travail actif par jour. Une seule requête exigeante avec un Dynamic Workflow épuise la limite.
• Max 5x ($100/mois) — 4 à 6 heures par jour de façon régulière. Le juste milieu pour la plupart des vibe coders.
• Max 20x ($200/mois) — une journée complète de travail sans se soucier de la limite. Cela a du sens si vous lancez beaucoup de workflows ou travaillez avec l’Agent SDK.

Pour en savoir plus, consultez les guides comment ne pas épuiser les limites de Claude Code et où vont les tokens.

⚠️ Un détail important signalé par Anthropic : un workflow de 1000 agents consomme « nettement plus de tokens qu’une session type ». Une grosse exécution peut consommer beaucoup de quota même avec 16 agents simultanés au maximum. Vérifiez le quota disponible et fixez un budget avant lancement ; la concurrence seule ne détermine pas le coût total.

⚠️ Fast Mode n’est pas inclus dans les forfaits Pro / Max / Team / Enterprise. Il nécessite l’activation de crédits d’utilisation et est facturé séparément, à $10/$50 par million de tokens, en plus de l’abonnement. Si vous êtes sur Max et activez Fast Mode sans crédits, un message vous demandera de recharger votre solde. Ce détail est souvent oublié à la lecture de la documentation.

Que sont les Dynamic Workflows dans Claude Code ?#

Différence entre un workflow, un sous-agent et une skill

Auparavant, tout ce que Claude Code faisait de façon autonome reposait sur une orchestration tour par tour. À chaque tour, Claude décidait quel outil appeler, et les résultats intermédiaires restaient dans son contexte. Cela fonctionne jusqu’à 4 ou 5 sous-agents ; au-delà, le contexte déborde.

Dynamic Workflow change cette méthode. Claude écrit un script JavaScript qui orchestre lui-même les agents. Les résultats intermédiaires se trouvent dans les variables du script, pas dans le contexte de Claude. Seul le résultat final revient dans le contexte. Cela produit trois effets :

1. Vous pouvez lancer jusqu’à 16 agents en parallèle, et jusqu’à 1000 au total par exécution.
2. Le contexte de Claude ne déborde pas — chaque sous-agent travaille dans son propre bac à sable.
3. Le script est réutilisable — après une exécution réussie, appuyez sur s dans /workflows pour l’enregistrer comme commande slash.

La documentation d’Anthropic sur les workflows le formule ainsi :

Limites du runtime

Trois façons d’activer un workflow

1. Le mot workflow dans le prompt. « Run a workflow to audit every API endpoint under src/routes/ for missing auth checks ». Claude détecte le déclencheur, écrit un script et le lance.
2. /effort ultracode — combine le raisonnement xhigh et l’orchestration automatique de workflows. Cela s’applique à toutes les tâches substantielles de la session. La documentation indique :

3. /deep-research [question] — un workflow intégré pour la recherche, avec recherche sur le Web et vérification croisée des sources.

Exemple : Bun et 750 000 lignes de Rust en 11 jours

L’équipe de Bun a utilisé Dynamic Workflows pour une expérience : porter Bun de Zig à Rust. D’après le blog d’Anthropic :

• ~750 000 lignes de Rust générées.
• 11 jours entre le premier commit et la fusion.
• 99,8 % des tests de la suite existante ont réussi.
• ~300 règles pour traduire Zig → Rust.

Le schéma technique comportait trois workflows successifs :

1. Le workflow #1 détermine la durée de vie Rust correcte pour chaque champ de struct dans la base de code Zig.
2. Le workflow #2 écrit chaque fichier .rs comme un port au comportement identique de son homologue .zig. Des centaines de tâches de fichiers réparties par lots, avec au plus 16 agents simultanés et deux réviseurs par fichier.
3. Le workflow #3 est une boucle de correction : il lance build + test jusqu’à ce que tout réussisse.

Le principal piège : les workflows épuisent la limite sur les petites tâches

Conclusion pratique : si une tâche peut être traitée par 1 ou 2 sous-agents simples, ne lancez pas de workflow ; utilisez les sous-agents manuellement. Les workflows sont rentables pour 50 fichiers ou plus, pas pour 5.

Dynamic Workflow est l’étape suivante de l’ingénierie du contexte. Un workflow peut distribuer le travail sur 1000 lancements au total, en programmant au plus 16 agents simultanément. Sans contexte commun du projet, les erreurs peuvent s’accumuler entre lots, car chaque agent ne voit que sa partie.

Quand activer xhigh effort ?#

Dans les notes de version de Claude Code v2.1.154, Anthropic indique explicitement qu’Opus 4.8 fonctionne par défaut avec effort=high — c’est la nouvelle norme depuis sa sortie. Auparavant, le niveau standard était inférieur. Le nouveau niveau xhigh est disponible en supplément pour les tâches les plus exigeantes, où le modèle dépense davantage de tokens de réflexion à chaque tour.

Quand utiliser xhigh :

• Migrations (nouveau modèle architectural → 50 fichiers ou plus).
• Audits de sécurité (revue de sécurité de 200 points de terminaison ou plus).
• Refactorings planifiés avec vérification des invariants.
• Longues sessions de débogage complexes, où le modèle doit se souvenir de tout le parcours.

Quand NE PAS l’utiliser :

• Modifications courantes dans un seul fichier (écrire un test, renommer une méthode).
• Prompts simples à structure claire.
• Documentation / commentaires — xhigh coûte plus cher sans raison.

Dans Claude Code v2.1.154, le curseur effort a été renommé de « Speed/Intelligence » en « Faster/Smarter ». Le niveau par défaut /effort high s’applique désormais en arrière-plan ; il n’est pas nécessaire de le sélectionner explicitement.

Quand utiliser Fast Mode ?#

Tarifs :

Quand l’utiliser :

• Tâches interactives où le temps de réponse compte davantage que la précision (revue de code en direct pendant un stream).
• Modifications rapides et test d’hypothèses.
• Démonstration / présentation à un client.

Quand NE PAS l’utiliser :

• Travail agentique à long horizon — le tarif 2× sur un contexte de 1M nuit à l’équilibre économique.
• Grand Dynamic Workflow — Fast Mode double les tarifs de tokens applicables et la consommation s’additionne sur les agents lancés. La limite de 1000 lancements n’est pas un multiplicateur fixe de coût : budgétez les entrées et sorties cumulées réelles.
• Sessions en arrière-plan où la vitesse n’est pas essentielle.

Comment passer à Opus 4.8 sans perdre vos paramètres ?#

Étape 1. Mettre Claude Code à jour

Dans le terminal :

claude upgrade

Ou le réinstaller en suivant la documentation d’Anthropic.

⚠️ La version cible est v2.1.156 ou ultérieure. La version v2.1.154 comportait un bug : avec Opus 4.8, les thinking blocks étaient modifiés, ce qui provoquait des erreurs d’API. Le bug a été corrigé dans v2.1.156.

Vérifiez la version :

claude --version

Étape 2. Changer de modèle dans /config

Dans Claude Code :

/model claude-opus-4-8

Ou ouvrez /config → section Model → choisissez Opus 4.8 dans la liste. L’identifiant du modèle sur l’endpoint API est claude-opus-4-8.

Étape 3. Activer Dynamic Workflows (abonnement Pro)

Dynamic Workflows sont désactivés par défaut avec l’abonnement Pro. Ouvrez /config → section Workflows → activez-les. Ils sont activés par défaut avec Max, Team et Enterprise personnel. Avec Enterprise et un administrateur, ils peuvent être désactivés par celui-ci ; demandez-lui de les autoriser.

Étape 4. Faire un test

Dans Claude Code, demandez une tâche simple avec un résultat clair pour vérifier que le modèle répond correctement :

Écris une fonction TypeScript qui découpe un tableau en blocs de longueur fixe.
Donne-moi des tests avec vitest.

Si la réponse est appropriée et que la phrase « using claude-opus-4-8 » apparaît au début, le changement a fonctionné. En cas d’erreur 400, vérifiez la version de Claude Code (revenez à l’étape 1).

Ce qu’il n’est PAS nécessaire de migrer

• CLAUDE.md fonctionne avec n’importe quel modèle sans modification. Plus de détails dans le guide comment configurer CLAUDE.md.
• Skills sont automatiquement prises en charge par Opus 4.8. Plus de détails dans le guide Claude Code Skills.
• Les serveurs MCP fonctionnent de façon identique. Le guide MCP est 7 combinaisons prêtes à l’emploi.
• Les sous-agents et Plan Mode ne changent pas. Le résumé des choix entre Skills, Subagents, MCP et Plugins se trouve dans le pillar correspondant.

Faut-il passer de Sonnet 4.6 ou Haiku 4.5 ?#

J’ai déjà abordé le choix entre Sonnet et Opus dans un ancien guide, mais il portait sur 4.7. Avec Opus 4.8, les règles changent légèrement.

Matrice de décision pour 2026 :

Pour la plupart des vibe coders, le meilleur équilibre est Sonnet 4.6 comme modèle par défaut, plus Opus 4.8 pour les tâches exigeantes via le sélecteur /model. Vous payez ainsi moins tout en traitant correctement les tâches difficiles.

Qu’est-ce qui ne fonctionne PAS dans Opus 4.8 ?#

Trois domaines dans lesquels Opus 4.8 montre des faiblesses d’après les retours pratiques :

1. Stratégie et feuilles de route axées sur les données. Les retours pratiques indiquent que 4.7 reste préférable pour l’analyse. Si votre cas d’usage principal consiste à établir un tableau de métriques et à proposer une feuille de route, essayez d’abord 4.8 ; si le résultat n’est pas satisfaisant, revenez à 4.7 avec /model claude-opus-4-7.

2. « Les derniers 10 % » dans les bases de code existantes. Le modèle est excellent pour le greenfield (un nouveau projet créé de zéro), mais montre des faiblesses quand il faut faire mûrir du code ancien — cas limites et particularités propres à l’architecture. C’est une faiblesse typique des modèles de raisonnement : ils génèrent bien, mais sont mauvais pour « terminer » ce qui existe déjà.

3. Les hallucinations persistent. « 4× moins susceptible de manquer des bugs » signifie que le modèle dit plus souvent « je ne sais pas », mais lorsque le contexte manque, il peut toujours produire une invention plausible. La protection, c’est le contexte du projet : plus CLAUDE.md est complet, moins il reste de place pour les hallucinations.

Cela ne signifie pas « ne faites pas la mise à jour ». Cela signifie : comprenez les limites et gardez Sonnet 4.6 et Opus 4.7 sous la main comme solutions de repli.

Que se passe-t-il après Opus 4.8 ?#

Dans les formulations d’Anthropic, « prochaines semaines » signifie généralement 4 à 8 semaines. Autrement dit, un modèle de classe Mythos sortira très probablement en juin-juillet 2026. Cela change la stratégie :

• Si vos projets actuels utilisent Sonnet 4.6 ou Opus 4.7 — passez à 4.8 et essayez xhigh et les workflows sur des tâches précises. Il s’agit d’une mise à niveau gratuite en termes de prix.
• Si vous prévoyiez une grande migration au moyen d’un workflow — ne vous précipitez pas. Un modèle capable de faire encore mieux pourrait sortir dans un mois ou deux. Vous pouvez commencer par une expérience sur un module pour comprendre son fonctionnement.
• Si vous comptiez réorganiser votre infrastructure autour de Dynamic Workflows — attendez. Mythos pourrait modifier les modèles fondamentaux.

Face à cette incertitude, le principal conseil est de rester flexible. Opus 4.8 est une bonne mise à niveau incrémentale. Mythos pourrait représenter un bond en avant. N’investissez pas dans une refonte majeure un mois avant la sortie possible d’un nouveau modèle.

Continuez à découvrir Ailoot sur ailoot.ai.