Claude Opus 5 face à Opus 4.8, mesures à l’appui : même tarif, coût multiplié par 3

Claude Opus 5 et Claude Opus 4.8 sont tous deux facturés $5 par million de tokens en entrée et $25 par million en sortie. Pourtant, à prompts identiques, la configuration par défaut d’Opus 5 nous a coûté 3,1 fois plus cher. La cause : l’adaptive thinking. Opus 5 raisonne par défaut, facture ce raisonnement comme de la sortie et ne vous le montre jamais. Un seul paramètre permet de revenir exactement au même coût, mais le modèle plus puissant Fable 5 refuse ce paramètre. Opus 5 est passé en disponibilité générale le 2026-07-24, avec la promesse d’une intelligence comparable à Fable 5 pour moitié moins cher par token. Dans les faits, la division par deux de la facture dépend presque entièrement de ce choix.

TL;DR

• Avec sa configuration par défaut, Opus 5 nous a coûté 3,1 fois plus cher qu’Opus 4.8, pourtant affiché au même tarif, sur notre matrice de cinq tâches ; 42 à 95 % de ses tokens de sortie correspondaient à du raisonnement masqué.
• thinking: {"type": "disabled"} a ramené Opus 5 à une parité exacte avec 4.8 (384 tokens de sortie contre 384), sans baisse de précision ; Fable 5 refuse ce paramètre.
• Sur du trafic agentique, le surcoût tombe à +33 %, et les scénarios avec tools ou en batch sont proches de la parité : l’adaptive thinking se déclenche très peu dans les boucles d’outils.
• La fenêtre de contexte de 1M est bien réelle (aiguille retrouvée à 969,950 tokens) et le seuil minimal du cache est de 512 tokens, contre 1,024 pour 4.8.

Quelles différences entre Opus 5, Opus 4.8 et Fable 5 en tant que plateformes ?

Avant d’analyser les coûts, voici une vue d’ensemble des trois niveaux actuels de Claude, selon deux axes : les tarifs et la forme des requêtes. Les éléments que nous avons mesurés sont indiqués comme tels ; les autres viennent de la documentation des modèles.

Trois lignes méritent une précision. La ligne thinking: disabled représente le principal piège lors d’une migration : sur Opus 5, ce paramètre dépend du niveau d’effort et n’est accepté qu’avec high ou moins, d’après la documentation. Avec 4.8, les deux paramètres étaient indépendants. Les scripts de migration doivent donc vérifier la version. La ligne Fast mode prépare une comparaison importante pour la suite : en mode rapide, Opus 5 coûte exactement le tarif de Fable 5. Comparer « Opus 5 rapide » à « Fable 5 par défaut » revient donc à arbitrer entre vitesse et capacités, à prix identique par token. Enfin, la ligne sur la conservation des données apporte un avantage discret côté conformité : Opus 5 offre une intelligence de classe Fable sans l’obligation de conservation pendant 30 jours de Fable 5.

Deux autres points se prêtent moins bien à un tableau. Anthropic documente certains cas limites lorsque le thinking est désactivé : les appels d’outils peuvent parfois être écrits dans le texte visible et des tags internes peuvent fuiter. Nous n’avons rencontré aucun de ces problèmes sur les 84 appels sans thinking de la suite agentique mesurée ci-dessous. Cette recommandation confirme néanmoins la règle de routage : gardez le thinking activé sur les routes qui utilisent beaucoup d’outils, puisque son surcoût y est de toute façon faible. Par ailleurs, la modification des tools en cours de conversation, disponible en bêta sur Opus 5, permet d’ajouter ou de retirer des outils entre deux tours sans invalider le prompt cache. Cela préserve l’économie des préfixes mis en cache sur laquelle repose notre guide du prompt caching pour les longues sessions agentiques.

Combien coûte Opus 5 par défaut par rapport à Opus 4.8 ?

3,1 fois plus cher pour le même travail, au même tarif public. Nous avons testé les trois niveaux actuels de Claude sur une matrice de cinq tâches (n=3 par cellule, prompts salés), avec leur configuration par défaut, via l’API Messages native. Fable 5 sert de point de comparaison :

Mêmes réponses, même tarif que 4.8, facture trois fois plus élevée. Opus 4.8 ne raisonne que si vous le demandez. Opus 5 active l’adaptive thinking par défaut et facture ce raisonnement au plein tarif de sortie, soit $25/M.

La colonne Fable 5 donne un résultat contre-intuitif : malgré des tarifs deux fois plus élevés ($10/$50), le modèle nous a coûté 35 % de moins qu’Opus 5 par défaut en valeur absolue. Il a répondu aux mêmes tâches avec 383 tokens de sortie, contre 1,305 pour Opus 5. Les trois modèles utilisent le même effort par défaut documenté (high) ; l’écart vient donc du calibrage du thinking, pas de la configuration. Deux mécanismes expliquent ces chiffres. D’abord, un modèle plus capable a besoin de moins délibérer pour valider une réponse simple : Fable 5 a consacré 52 tokens au problème, contre 152 pour Opus 5, et 264 tokens au paragraphe, contre 1,031. Ensuite, la promesse centrale d’Opus 5 repose sur la mise à l’échelle du calcul à l’inférence : davantage de délibération améliore la qualité sur les problèmes difficiles. Son calibrage par défaut paie cette marge de sécurité sur chaque requête, y compris quand elle ne sert à rien. Sur du trafic simple, vous payez donc une assurance inutilisée ; Fable 5 choisit le plus souvent de s’en passer.

Où part le surcoût ?

Dans un raisonnement que vous ne pouvez pas lire. En comparant les tokens de sortie facturés au texte visible de la réponse, 42 à 95 % des dépenses de sortie d’Opus 5 par défaut correspondaient à du thinking masqué. Il se déclenche même sur des questions qui n’en ont pas besoin : la réponse à 17*23 comportait 11 tokens de raisonnement derrière une réponse d’un seul token, et la tâche de rédaction de 120 mots a consacré environ 806 de ses 1,031 tokens de sortie à délibérer. Le contenu du raisonnement n’est jamais renvoyé, sous aucune forme : ni résumé, ni trace. Opus 5 se place donc, avec Fable 5, tout au bout du spectre fermé que nous avions décrit dans notre étude sur l’anatomie de la consommation de tokens. Le détail d’usage vous donne le nombre de tokens, mais pas ce qu’ils ont apporté.

Que fait réellement le paramètre de thinking ?

Il ramène la facture d’Opus 5 au niveau d’Opus 4.8. Avec thinking: {"type": "disabled"}, le nombre de tokens de thinking est tombé à zéro sur toutes les tâches. Les totaux ont atteint une parité exacte avec 4.8 : 384 tokens de sortie contre 384, et $0.01130 contre $0.01120 par série.

Précisons d’abord les libellés. Pour tous ces modèles, l’API documente le même effort par défaut, high, et Anthropic indique qu’un high explicite revient exactement à omettre le paramètre. Nos variantes « par défaut implicite » et high explicite présentent tout de même un écart de 16 %. Il s’agit de la variance entre exécutions sur la tâche de rédaction, qui est la cellule la plus bruitée de tous nos lots, et non d’une différence réelle. Ces deux lignes doivent être lues comme deux mesures d’une même variante. Ce qui distingue les trois configurations par défaut n’est pas le niveau d’effort, mais le comportement du thinking à ce niveau : aucun sur 4.8, économe et adaptatif sur Fable 5, agressif et adaptatif sur Opus 5.

Deux constats ressortent. Premièrement, le réglage de l’effort sert à ajuster la qualité, pas le coût. L’échelle elle-même, de low à max, n’est pas nouvelle : 4.8 accepte la même plage. Mais sur des tâches aussi simples, chaque niveau au-dessus de low ne fait qu’acheter davantage de délibération, sans améliorer la précision. Avec xhigh, la facture atteint 3,8 fois celle de 4.8. Les niveaux supérieurs servent à augmenter le calcul à l’inférence sur des problèmes réellement difficiles, ce qu’une matrice de contrôle limitée à cinq tâches ne peut pas tester. Elle montre en revanche l’effet sur les coûts : aucun niveau de l’échelle ne permet de retrouver la parité avec 4.8. Seule la désactivation y parvient, avec une baisse de 67 % par rapport au défaut. Deuxièmement, cette désactivation existe bel et bien : Fable 5 refuse thinking: {"type": "disabled"} avec une erreur 400. Il s’agit donc d’une vraie différence propre à Opus 5, et non d’une constante de la famille. Le même objet thinking fonctionne sur les deux interfaces du gateway, /v1/messages et l’API compatible OpenAI /v1/chat/completions. Sur cette dernière, les exécutions avec thinking désactivé indiquent zéro reasoning_tokens dans completion_tokens_details :

{"model": "claude-opus-5", "thinking": {"type": "disabled"}}

La limite de cette mesure doit être claire : nos tâches vérifiables relèvent surtout de la restitution d’informations et du raisonnement en une étape. La précision est restée à 9/9 sans thinking, y compris sur le problème en plusieurs étapes. L’adaptive thinking vise précisément des tâches agentiques plus difficiles. La désactivation doit donc se décider route par route, selon la même règle que pour Kimi K3 et Gemini 3.6 Flash : désactivez-la pour l’extraction, le formatage et les appels en une étape ; gardez la configuration par défaut lorsque vos evals montrent que le thinking justifie son coût.

Le surcoût de 3x se retrouve-t-il sur les workloads agentiques ?

Non, et cette différence est essentielle. Sur l’ensemble de notre suite de scénarios agentiques, qui couvre les boucles d’outils, le RAG, l’outillage, le batch et les longues conversations, à raison de 50 épisodes par variante, Opus 5 par défaut n’a coûté que 33 % de plus qu’Opus 4.8, et non 210 %. Les scénarios centrés sur les tools étaient proches de la parité, entre 1.01 et 1.22x. Dans ce contexte, l’adaptive thinking est réellement adaptatif : environ 88 tokens de thinking par appel dans les boucles agentiques, contre 806 sur un simple prompt de rédaction. La longue conversation fait exception avec un ratio de 1.58x ; la désactivation reste rentable dans ce cas, en ramenant le ratio à 1.22x. Le function calling n’a généré aucun surcoût de thinking : avec la configuration par défaut, une requête d’appel d’outil a produit 52 tokens de sortie sans aucun thinking, soit le même budget qu’un modèle sans raisonnement.

La séparation opérationnelle se fait donc selon la forme du trafic, pas selon le modèle. Les complétions brutes et les appels de type chat supportent le surcoût par défaut de 3x et gagnent à désactiver le thinking. Le trafic agentique riche en tools n’en a généralement pas besoin.

Opus 5 coûte-t-il vraiment deux fois moins cher que Fable 5 ?

Seulement après avoir désactivé le thinking. Par token, oui : $5/$25 contre $10/$50 pour Fable 5. En pratique, sur notre matrice de tâches simples, Opus 5 par défaut a coûté $0.03427 par série, contre $0.02233 pour Fable 5, soit 53 % de plus en valeur absolue. Fable 5 a répondu aux mêmes tâches avec 383 tokens de sortie, contre 1,305 pour Opus 5. Une fois le thinking désactivé, les $0.01130 d’Opus 5 correspondent presque exactement à la moitié de la facture de Fable 5. La promesse du lancement se vérifie donc, mais grâce à un paramètre que Fable 5 lui-même n’accepte pas.

Contexte, cache et tokenizer : qu’avons-nous vérifié d’autre ?

La fenêtre de 1M est réelle et les dépassements provoquent une erreur explicite. Une aiguille placée au début d’un prompt de 969,950 tokens a été correctement retrouvée en 39 secondes. Un prompt de 1,010,221 tokens a renvoyé un message clair, prompt is too long: … > 1000000 maximum, au lieu d’être tronqué silencieusement.

Le seuil minimal du cache a été divisé par deux. Anthropic documente un préfixe minimal de 512 tokens pour qu’Opus 5 et Fable 5 puissent le mettre en cache, contre 1,024 pour Opus 4.8 et Sonnet 5. Nos tests ont confirmé ce seuil : les préfixes proches de 511 tokens n’étaient jamais mis en cache, tandis que ceux de 547 tokens l’étaient de manière fiable. Les lectures depuis le cache sont facturées $0.50/M (0.1x), les écritures 1.25x, avec un TTL de 5 minutes. Les system prompts plus courts peuvent désormais être mis en cache, ce qui compte discrètement sur les routes à fort QPS.

Le tokenizer est identique sur Opus 5, Opus 4.8, Fable 5 et Sonnet 5. Nos échantillons multilingues et de code ont donné exactement les mêmes nombres de tokens. Les budgets par langue et les estimations de taille des prompts restent donc valables sans nouvelle calibration.

FAQ

Peut-on désactiver le thinking sur Claude Opus 5 ?

Oui, avec un effort high ou inférieur. La documentation précise que le combiner à xhigh ou max renvoie une erreur 400. Lors de nos tests, cette configuration a ramené les tokens de thinking à zéro et le coût au niveau d’Opus 4.8, avec 384 tokens de sortie contre 384 sur notre matrice. Ce comportement est propre à Opus 5 : Fable 5 refuse le même paramètre, quel que soit le niveau d’effort, avec une erreur 400. Le réglage de l’effort, de low à max, fonctionne également, mais n’atteint jamais la parité : dans notre matrice, il allait de -21 % avec low à +24 % avec xhigh par rapport à la configuration par défaut.

Pourquoi ma facture Opus 5 est-elle plus élevée que celle d’Opus 4.8 alors que leurs tarifs publics sont identiques ?

Parce qu’Opus 5 raisonne par défaut et facture ce raisonnement comme de la sortie à $25/M. Sur des prompts bruts, le raisonnement masqué représentait 42 à 95 % de la sortie facturée dans nos mesures. Même une multiplication à deux chiffres comportait 11 tokens de thinking derrière une réponse d’un seul token. Consultez reasoning_tokens dans le détail d’usage pour mesurer cette part sur votre propre trafic, puis désactivez le thinking sur les routes qui n’en ont pas besoin.

Faut-il désactiver le thinking pour les workloads agentiques sur Opus 5 ?

Généralement non. Dans notre suite agentique, la configuration par défaut n’a coûté que +33 % par rapport à Opus 4.8. Les scénarios avec tools et en batch étaient proches de la parité, car l’adaptive thinking se déclenche très peu dans les boucles d’outils. Les longues sessions de type chat font exception, avec un ratio de 1.58x, et la désactivation y reste rentable. Mesurez votre propre répartition : le surcoût se concentre dans les complétions brutes, pas dans les appels d’outils.

Mesures réalisées du 2026-07-25 au 2026-07-27 sur claude-opus-5, claude-opus-4-8 et claude-fable-5 via le gateway Synthorai : matrice de cinq tâches et ablation des niveaux d’effort et du paramètre de thinking à partir d’un même lot canonique (n=3 par cellule, prompts salés, API Messages native), mesures agentiques issues d’une suite de 150 épisodes, tests du contexte et du cache par recherche d’aiguille et balayage des tailles de préfixe, lignes liées à la forme de l’API (prefill, acceptation du paramètre) obtenues par des requêtes directes. Les scores de précision ne portent que sur les tâches ayant une réponse unique et vérifiable. Les tarifs et les comportements peuvent évoluer ; vérifiez-les dans vos propres relevés d’usage.

← Retour au blog