Claude Opus 5.5 : moins cher au token, pas prouvé à la tâche

Un Opus moins cher qui refuse une partie de vos requêtes existantes

Claude Opus 5.5 est le remplaçant d'Opus 5 chez Anthropic dans le même palier, annoncé aujourd'hui, disponible uniquement par API, sans poids publiés. Pour quiconque fait tourner Opus 5 en production, deux choses changent en même temps, et elles tirent en sens opposés.

La première, c'est la facture. Selon le tableau du fournisseur, l'entrée passe de $5 à $4 par million de tokens, la sortie de $25 à $20, et les lectures de cache de $0.50 à $0.20. L'annonce d'Anthropic formule le message principal ainsi :

It costs less per token than Opus 5 and uses fewer tokens per task, which nets out to a 40% drop in costs.

Deux affirmations sont compressées dans cette phrase. Le prix au token est un fait que l'on peut lire directement sur le tableau. Les tokens par tâche relèvent d'une mesure, et savoir sur quelle charge de travail elle a été prise compte plus que le pourcentage.

Le second changement, c'est que l'API n'accepte plus certaines requêtes qu'Opus 5 acceptait. La page What's new d'Anthropic liste quatre changements cassants : le thinking ne peut plus être désactivé, l'usage forcé d'un outil renvoie une erreur, les blocs de thinking sont liés au modèle et à la conversation, et l'ancien outil d'usage d'ordinateur computer_20251124 n'est plus accepté sur la Claude API ni sur Google Cloud.

Les deux premiers sont ceux que la plupart des intégrations Opus 5 vont rencontrer. Toute requête qui envoie thinking: {"type": "disabled"} ou un budget de thinking manuel reçoit une erreur 400. Toute requête qui envoie un tool_choice de valeur any ou un outil nommé reçoit une erreur 400. Les remplacements recommandés par le fournisseur sont le paramètre effort pour le premier cas, et tool_choice: auto combiné à l'usage strict d'outils ou aux sorties structurées pour le second. Si vous forciez un appel d'outil pour obtenir du JSON conforme à un schéma, c'est un changement de code, pas un changement de configuration.

Un cinquième changement ne fait échouer aucune requête et passe plus facilement inaperçu :

text between tool calls comes back in thinking blocks

Au réglage display par défaut, ces blocs ont un texte vide, donc une application qui diffuse aux utilisateurs les notes de progression du modèle devient silencieuse entre les appels d'outils, sans aucune erreur à intercepter.

L'argument de coût et le nouvel effort par défaut ne font qu'un

La cause, c'est la sortie elle-même, et ce qui rend le sujet urgent, c'est que pour une bonne part des intégrations Opus 5, la migration n'est pas facultative comme elle le serait avec un nouveau modèle ordinaire. La propre page du fournisseur indique que le code qui tourne déjà sur Opus 5 avec le thinking activé n'a besoin d'aucun changement. Le code qui tourne avec le thinking désactivé, force un appel d'outil, utilise l'ancien outil d'usage d'ordinateur, ou modifie le contexte antérieur d'une conversation sur un compte créé depuis le 31 août ne peut pas être basculé sur Opus 5.5 sans y toucher. Quiconque est sur Opus 5 doit trancher, et l'argument du fournisseur pour trancher en faveur du oui, c'est le coût.

Le qualificatif accompagnant cet argument figure sur la même page que le message principal :

at default settings it will cost 40% less than Opus 5 on typical workloads

« Default settings » pèse plus lourd qu'il n'y paraît. La documentation d'Anthropic sur l'effort indique qu'Opus 5.5 tourne par défaut à l'effort medium là où Opus 5 tournait par défaut à high :

a request that omits effort runs one level lower than it did on Claude Opus 5

Le chiffre de 40% du fournisseur compare donc Opus 5.5 à medium avec Opus 5 à high. C'est une comparaison de réglages par défaut légitime en soi. Ce n'est pas une comparaison au même niveau d'effort, et le propre guide de prompting du fournisseur dit ce qui se passe si l'on maintient l'effort constant :

At a given level, Claude Opus 5.5 tends to think more per turn than Claude Opus 5, especially at xhigh and max.

Mettez ces deux lignes bout à bout et la migration prend une forme précise. Migrez en adoptant le nouveau défaut, et vous tournez un niveau d'effort en dessous de l'ancien, sur un modèle que le fournisseur dit plus performant à ce niveau. Migrez en conservant votre valeur d'effort d'Opus 5, et le fournisseur lui-même vous dit de vous attendre à des tours plus longs et davantage de tokens de sortie, pour un prix au token seulement 20% inférieur. Les 40% correspondent à la première voie. Rien sur la page d'annonce ne les revendique pour la seconde.

Trois rapports indépendants, et personne n'a testé le réglage par défaut

La preuve la plus solide du fournisseur sur le coût par tâche est un graphique, et le fournisseur l'a publié avec l'axe correctement légendé.

Selon Anthropic, Opus 5.5 à l'effort par défaut bat Opus 5 à l'effort max sur Terminal-Bench 4.0 pour environ un cinquième du coût par tentative. C'est le benchmark du fournisseur, les runs du fournisseur et le graphique du fournisseur, et c'est la version la plus solide de son argument parce qu'elle raisonne par tentative, pas par token. L'annonce cite aussi une vingtaine de partenaires de lancement qui rapportent de bons résultats. Ce sont là des documents du fournisseur. Aucun d'eux n'a publié de compte de tokens.

Trois parties extérieures à Anthropic ont publié quelque chose le jour du lancement. Aucune ne constitue un test comparable point par point de l'affirmation du fournisseur sur les réglages par défaut, et chacune montre quelque chose de plus étroit que le titre qu'on lui prête généralement : une hausse de tokens à l'échelle d'un pipeline face à un mélange de production, une seule requête ayant atteint le plafond de sortie à l'effort max, et un run d'indice max contre max.

CodeRabbit a fait tourner Opus 5.5 dans son pipeline de revue de code et a rapporté une utilisation de tokens plus élevée dans chaque configuration : +49.2% et +57.6% sur 80 correctifs de bugs open source, +40.6% et +60.1% sur 13 cas plus difficiles. Deux conditions accompagnent ces chiffres. La référence de comparaison est le propre mélange de modèles en production de CodeRabbit, pas Opus 5, et « Standard » et « Max » sont ses configurations de pipeline, pas des valeurs d'effort de l'API. CodeRabbit le dit lui-même pour la première partie :

The token increase is also a different comparison from the price reduction relative to Opus 5.

Les chiffres proviennent d'un résumé de run qui ne distingue pas les tokens d'entrée des tokens de sortie, et ils n'établissent ni coût en dollars ni latence. Le billet ne dit pas si CodeRabbit disposait d'un accès anticipé. Ce qu'il dit, en revanche, c'est où repose la charge de la preuve :

Its efficiency remains an open question, so teams should verify whether its lower token prices actually translate into lower production-review costs.

Ce n'est pas un avis hostile. La raison que le même billet avance pour essayer le modèle est la capacité, pas le prix :

The strongest reason to try Opus 5.5 is that it finds a different mix of bugs.

Simon Willison a touché l'autre bord du thinking permanent. En demandant un SVG à l'effort max :

it hit the limit of 128,000 cap for output tokens while it was still reasoning about the question!

So that failed attempt on max cost me $2.56.

C'est un comportement documenté, pas un bug. La page d'Anthropic sur l'effort vous dit de

set a large max_tokens at the higher levels: it's a hard limit on total output (thinking plus response text)

et le guide de migration confirme que le plafond est resté à 128k. Sur Opus 5, vous pouviez désactiver le thinking et rendre ce plafond sans objet. Sur Opus 5.5, vous ne le pouvez plus, si bien qu'aux niveaux d'effort les plus élevés une requête peut épuiser tout son budget en raisonnement et ne rien renvoyer, tout en vous facturant ce raisonnement.

Artificial Analysis a fait tourner son Intelligence Index sur les deux modèles à l'effort max, avec le repli activé pour Opus 5.5. Relevées le jour du lancement, les deux pages indiquent :

When evaluating the Intelligence Index, it generated 260M tokens, which is very verbose in comparison to the median of 88M.

When evaluating the Intelligence Index, it generated 140M tokens, which is very verbose in comparison to the median of 88M.

Opus 5.5 a obtenu 58 contre 51 pour Opus 5 sur cet indice, et les mêmes pages, telles que lues le jour du lancement, chiffrent le run complet à $8,708.20 contre $7,274.74, soit $5.98 par tâche contre $5.86. Vingt pour cent moins cher au token, 86% de tokens en plus, deux pour cent de plus par tâche. Deux réserves : il s'agit de max contre max, donc cela ne dit rien du réglage par défaut medium sur lequel repose l'affirmation du fournisseur, et le repli était activé, donc certaines tâches ont pu être traitées par un autre modèle. La même page indique la vitesse de sortie d'Opus 5.5 comme non disponible. L'annonce d'Anthropic affirme que le modèle génère la sortie plus de 30% plus vite qu'Opus 5. À ce jour, personne en dehors d'Anthropic ne l'a mesuré.

Ce qui n'a été testé par personne d'indépendant : la comparaison des réglages par défaut elle-même, Opus 5.5 à medium contre Opus 5 à high sur une charge de travail réelle. C'est la seule mesure qui trancherait le chiffre du fournisseur, et c'est celle que vous pouvez réaliser vous-même.

Il existe un désaccord supplémentaire, entre deux pages d'Anthropic elles-mêmes. L'annonce décrit les nouveaux garde-fous sur la cybersécurité, la biologie et la distillation comme

all of which fall back to another model transparently

La documentation sur les refus et le repli nomme Opus 5.5 dès sa première phrase, puis décrit quelque chose que l'appelant doit mettre en place lui-même. Un refus n'est pas une erreur :

When that happens, you receive a normal response, not an error, with stop_reason: "refusal".

Obtenir une réponse d'un autre modèle suppose d'activer l'une des trois voies suivantes : le repli côté serveur, le middleware du SDK, ou une retentative écrite par vos soins. À propos de la première, la même page précise :

Server-side fallback is in beta on the Claude API.

Elle ajoute que le paramètre fallbacks n'est pas pris en charge sur l'API Message Batches et n'est pas disponible sur Amazon Bedrock, Google Cloud ou Microsoft Foundry, où le middleware du SDK est la voie à utiliser à la place. La facturation est elle aussi précisée :

An attempt that declined before producing any output is not billed: its tokens are reported on its usage.iterations entry but not charged.

Chaque tentative ayant effectivement produit une sortie, y compris une tentative refusée en cours de route, est facturée aux tarifs du modèle qui l'a exécutée, et usage.iterations en constitue le relevé par tentative. Quand un repli s'exécute, la réponse nomme le modèle qui l'a servie. Autrement dit, « transparently » signifie visible, pas automatique. Un pipeline qui n'active rien et se contente de vérifier les erreurs lira un refus de garde-fou comme un appel réussi qui ne contient aucune réponse.

Mesurez les tokens par tâche terminée, puis décidez

La migration est un travail en deux temps, et l'ordre compte. Rendez d'abord les requêtes valides : supprimez le champ thinking, remplacez le tool_choice forcé par auto associé à l'usage strict d'outils ou aux sorties structurées, passez au nouveau jeu d'outils d'usage d'ordinateur si vous en utilisez un, et réglez display sur updates si vous diffusez du contenu entre les appels d'outils. Fixez effort explicitement plutôt que d'hériter du nouveau défaut par inadvertance, et réglez max_tokens assez haut aux niveaux supérieurs pour laisser de la place au raisonnement.

Ensuite, avant que tout cela n'atteigne la production, faites la comparaison que recommande la propre page du fournisseur sur l'effort : un balayage des niveaux d'effort sur vos évaluations plutôt que des réglages simplement reportés. Le chiffre à consigner n'est pas le prix au token. C'est le nombre total de tokens, décomposé en entrée, sortie et lectures de cache, par tâche effectivement terminée, à chaque niveau d'effort, sur vos propres prompts. Les lectures de cache comptent plus qu'il n'y paraît : Anthropic affirme qu'elles constituent la majorité des coûts du travail agentique et de code, et c'est la ligne qui a chuté de 60%, si bien qu'une charge de travail riche en cache peut ressortir gagnante même si les tokens de sortie augmentent. Une charge de travail avec peu de cache et un raisonnement long peut ressortir perdante. Vous ne saurez laquelle des deux est la vôtre qu'en comptant.

Cette comparaison est un petit workflow, et c'est exactement le genre de chose pour laquelle Latenode est conçu, que le modèle testé soit ou non le sujet. Prenez les trente prompts que votre produit envoie réellement, faites-les passer par deux configurations, Opus 5 à l'effort que vous utilisez aujourd'hui et Opus 5.5 à medium, et laissez un nœud JavaScript, qui peut installer n'importe quelle bibliothèque NPM, faire les deux appels via le SDK du fournisseur et enregistrer les tokens d'entrée, les tokens de sortie, les lectures de cache et le temps d'horloge murale pour chacun. Un plan payant inclut 5 workers d'exécution parallèles, si bien que le balayage tourne à peu près au niveau de concurrence que vous servez, plutôt qu'un prompt à la fois. Le compteur de facturation coopère avec l'expérience : Latenode facture les secondes CPU qu'une exécution consomme réellement, pas par nœud ni par appel d'API, et sans minimum par exécution, si bien que quelques centaines de courtes exécutions de comparaison coûtent les secondes qu'elles prennent. La facture qui compte, c'est celle du modèle, et le balayage existe pour produire ce chiffre avant que vous ne vous engagiez.

Migrez cette semaine si votre charge est riche en cache et que vous pouvez compter

Migrez dès maintenant si trois conditions sont réunies : vous faites tourner Opus 5 avec le thinking activé, votre trafic est du travail agentique ou de code où les lectures de cache dominent, et vous disposez d'un moyen de mesurer les tokens par tâche terminée avant et après. Dans ce cas de figure, le tableau tarifaire du fournisseur fait l'essentiel du travail à lui seul, la baisse de l'effort par défaut est un bonus que vous pouvez prendre ou refuser, et les changements cassants vous coûtent une après-midi. Prenez d'abord medium. Ne montez que si vos évaluations vous y invitent.

Ne migrez pas cette semaine si l'un de ces cas s'applique. Vous faites tourner Opus 5 avec le thinking désactivé : cette configuration n'existe plus, et le substitut le plus proche est un niveau d'effort inférieur que vous n'avez pas calibré. Vous forcez les appels d'outils pour obtenir du JSON valide : cette voie a disparu et le remplacement doit être testé. Vous tournez à xhigh ou max : les seules mesures indépendantes à ce niveau montrent plus de tokens, et le plafond de 128k inclut désormais un raisonnement que vous ne pouvez plus désactiver. Votre compte API a été créé le 31 août 2026 ou après, et votre pipeline modifie le system prompt ou les outils en cours de conversation : le thinking préservé rejettera le rejeu. Votre trafic touche à des outils de sécurité ou à la biologie : un refus de garde-fou revient comme une réponse normale avec un motif d'arrêt de refus, pas comme une erreur, et obtenir une réponse d'un autre modèle suppose d'activer une voie de repli, dont la voie côté serveur est en bêta sur la Claude API et non proposée sur les lots ni sur les plateformes cloud. Construisez la retentative avant d'en avoir besoin.

Et ne migrez pas sur la foi des 40%. C'est le chiffre du fournisseur pour ses propres charges de travail, à ses propres réglages par défaut, et à ce jour personne en dehors du fournisseur ne l'a reproduit sur quoi que ce soit. La première mesure indépendante de la comparaison défaut contre défaut sur une charge de production vaudra plus que tous les benchmarks de la page d'annonce. Tant qu'elle n'existe pas, le chiffre qui doit trancher votre migration est celui que vous produirez vous-même.