Opus 5.5 : mesure le coût par tâche, pas le prix du token
#Combien coûte vraiment ce que tu demandes à Claude ?
À chaque sortie de modèle, on compare les grilles tarifaires : tant de dollars par million de tokens en entrée, tant en sortie. C'est utile, mais ça ne répond pas à la question qui t'intéresse vraiment : combien me coûte une tâche terminée ?
Le token, c'est l'unité de base que lit et produit un modèle : un morceau de mot, en gros. Le prix affiché porte sur ces morceaux. Mais une tâche réelle, c'est bien plus qu'un aller-retour. Le modèle relit des fichiers, tente une modification, rate, recommence. Toi, tu réexpliques ce que tu voulais. Tout ça consomme des tokens.
C'est l'angle que prend Nate B Jones dans une vidéo consacrée à Opus 5.5 (publiée le 30 septembre 2026). Son idée : la vraie mesure d'un modèle, c'est son efficacité par tâche. Dans cet article, on décortique son exemple, on sépare ce qui relève des faits et ce qui relève de son opinion, puis on voit comment appliquer la méthode à ton propre travail.
#L'exemple : un logo transformé en LEGO
Pour illustrer son propos, l'auteur de la vidéo a demandé à Opus 5.5 de transformer son logo (une tête avec un bonnet et des lunettes) en modèle LEGO constructible. Le résultat n'est pas qu'une jolie image. Il a obtenu :
- un modèle de 514 pièces ;
- un livret d'instructions de 63 pages en 58 étapes ;
- un fichier de modèle, une liste de pièces et une liste de commande pour BrickLink (un site de vente de pièces LEGO détachées) ;
- un fichier de vérification des connexions géométriques entre les briques ;
- un fichier LDraw, le format ouvert standard pour décrire des modèles LEGO, qui permet de contrôler que les pièces s'assemblent vraiment ;
- une animation vidéo de l'assemblage.
Et voici l'addition qu'il présente :
Le raisonnement : son abonnement revient à environ 50 dollars par semaine. Si la tâche consomme 1 % du quota hebdomadaire, elle lui coûte environ 50 centimes. Au tarif de l'API, ces 89 millions de tokens auraient coûté au moins 44 dollars, soit grosso modo un quart d'un abonnement à 200 dollars par mois.
Le chiffre de 44 dollars est une estimation de l'auteur, sans détail du calcul. Hors source : au tarif d'entrée affiché (4 dollars par million de tokens), 89 millions de tokens coûteraient bien plus. Un total aussi bas suppose qu'une très grande partie de ces tokens soient des lectures de cache, facturées beaucoup moins cher. Prends ce chiffre comme un ordre de grandeur, pas comme une facture.
#Prix du token contre coût de la tâche
#Les tarifs affichés
Selon la vidéo, Opus 5.5 coûte 4 dollars par million de tokens en entrée et 20 dollars par million en sortie. C'est 20 % de moins qu'Opus 5, et 60 % de moins que Fable 5.1, facturé 10 et 50 dollars.
| Modèle | Entrée (par million) | Sortie (par million) |
|---|---|---|
| Opus 5.5 | 4 $ | 20 $ |
| Opus 5 | 5 $ | 25 $ |
| Fable 5.1 | 10 $ | 50 $ |
Contexte (hors source) : les tarifs d'Opus 5 (5 et 25 dollars) se déduisent de la baisse de 20 % annoncée. D'après plusieurs sites de suivi des prix, la lecture d'un préfixe en cache coûte 0,20 dollar par million de tokens sur Opus 5.5, et l'API Batch divise les tarifs de base par deux. Vérifie toujours sur la page de tarifs officielle d'Anthropic.
#Pourquoi le prix ne suffit pas
Anthropic annonce que les charges de travail typiques coûtent environ 40 % de moins avec Opus 5.5 qu'avec Opus 5. Ce chiffre combine deux effets : la baisse des tarifs et le fait que le modèle utilise moins de tokens pour finir le travail.
Nate B Jones insiste sur un piège : 40 % de coût en moins ne veut pas dire 40 % de tokens en moins. Une facture mélange plusieurs catégories de tokens, chacune avec son tarif : entrée, sortie, écriture et lecture de cache. Pour comprendre d'où vient le gain, il faut regarder chaque catégorie, la facture API, et, si tu es abonné, l'effet sur ton quota.
Contexte (hors source) : certains commentateurs notent que la baisse de tarif explique à elle seule une bonne partie de ces 40 %, et que la comparaison d'Anthropic opposerait Opus 5.5 en effort moyen à Opus 5 en effort élevé. Raison de plus pour mesurer toi-même.
L'auteur juge ce chiffre de 40 % plausible. Il cite les témoignages mis en avant dans l'annonce : GitHub et Lovable décrivent un modèle qui passe par moins d'étapes, et Spotify des tâches faites plus vite et moins cher. Il ajoute avoir vu beaucoup d'utilisateurs rapporter la même chose sur X. Ce sont des retours d'expérience, pas une mesure indépendante.
#Ce qui rend un modèle efficace sur une tâche
#La « pilotabilité »
Pour Nate B Jones, le gain d'efficacité vient surtout de la pilotabilité (steerability) : la capacité du modèle à faire exactement ce que tu demandes, du premier coup, et à intégrer une correction sans tout casser.
Il raconte qu'après Opus 4.6, qu'il appréciait beaucoup, obtenir le résultat voulu était devenu plus compliqué au fil des versions 4.7, 4.8 et Fable, notamment pour l'écriture. Il cite des plaintes publiques allant dans ce sens, dont un ticket dans le dépôt GitHub d'Anthropic où un utilisateur décrit des consignes d'écriture reconnues puis ignorées. Toujours selon lui, l'annonce d'Opus 5.5 cite ces retours sur la communication d'Opus 5 et présente une écriture plus claire et un meilleur respect des consignes comme l'une des principales corrections.
Son critère pour une bonne réécriture est simple : elle préserve ton intention. Si tu demandes un paragraphe plus simple, le modèle ne doit pas supprimer la nuance qui faisait la valeur de ton argument. Si tu demandes un ton plus chaleureux, il ne doit pas adoucir une décision que tu voulais ferme.
« Une bonne révision doit préserver ton intention. » — Nate B Jones
#Le code comme outil visuel
Autre point mis en avant : Claude produit du travail visuel en écrivant du code. Three.js, par exemple, est une bibliothèque JavaScript qui affiche des scènes 3D dans le navigateur : objets, matériaux, lumières, caméra.
L'intérêt pour l'efficacité : une scène décrite en code se modifie de façon chirurgicale. Si tu veux un chapeau plus haut mais garder les lunettes intactes, Claude peut changer uniquement les objets concernés, puis mettre à jour la liste de pièces et les instructions pour qu'elles restent cohérentes. Pas besoin de tout régénérer.
#Un cadre clair pour les tâches longues
L'auteur dit avoir lancé deux ou trois tâches de nuit avec Opus 5.5. Sa conclusion : le modèle s'en sort mieux quand on lui donne des conditions d'arrêt claires et une définition de « terminé » précise. Selon lui, ce modèle « aime continuer encore et encore » : sans limite, cette persévérance consomme des tokens inutilement.
Pour le LEGO, il a donc fixé dès le départ le nombre de pièces et le niveau de complexité. Le modèle n'a pas eu à décider seul de l'ampleur du projet, puis à juger son travail insuffisant et à en refaire davantage. D'après lui, cela lui a fait économiser beaucoup de tokens.
Ce conseil n'est pas propre à Opus 5.5, l'auteur le reconnaît lui-même. Mais plus un modèle est persévérant, plus il compte. Avant une tâche longue, écris noir sur blanc : le livrable attendu, les critères de réussite et le moment où le modèle doit s'arrêter.
#Comment l'appliquer : mesurer ton propre coût par tâche
Les tâches de l'auteur ne sont pas les tiennes. Comme il le dit, les modèles ont des performances en dents de scie : excellents sur certains travaux, moyens sur d'autres. La seule façon de savoir ce que vaut une nouvelle version pour toi, c'est de la tester sur ton travail réel. Voici la méthode qu'il propose, en étapes.
- Choisis une tâche déjà faite. Prends un travail que tu as déjà confié à un modèle précédent, avec tes vrais fichiers : un dépôt de code, des tableurs, des documents. Choisis une tâche dont le résultat t'importe vraiment.
- Reproduis les mêmes conditions. Même point de départ, même prompt, même configuration. Sinon, tu compares deux choses différentes.
- Laisse tourner, puis mesure tout. Note le total de tokens, estime le coût au tarif de l'API, et relève la part de ton quota consommée si tu es abonné.
- Compte aussi ton implication. Combien de tentatives ratées ? Combien de corrections ? Combien de fois as-tu dû réexpliquer ? Un modèle qui te fait passer l'après-midi à le corriger coûte cher, même si ses tokens sont bon marché.
- Vérifie la qualité. Le résultat doit être au moins aussi bon qu'avec le modèle précédent. Une tâche moins chère mais ratée ne compte pas.
- Garde les échecs. Note aussi les cas où la nouvelle version ne t'a pas aidé. C'est ce qui te montre où se situe vraiment le progrès : peut-être sur le visuel et l'écriture, moins sur la recherche.
- Recommence à chaque sortie. Conserve ce petit kit de tâches et repasse-le à chaque nouveau modèle. C'est comme ça que tu sauras quand une vraie avancée arrive.
Un simple tableau suffit pour commencer : une ligne par essai, avec le modèle, la tâche, les tokens, le coût estimé, le nombre de corrections et une note de qualité. Après deux ou trois sorties de modèles, tu auras ta propre référence, bien plus parlante qu'un benchmark public.
L'auteur donne un exemple de décision prise ainsi : après ses essais, il a confié à Opus 5.5 un travail de design d'environ 90 éléments, en un seul prompt, plutôt qu'à l'outil qu'il utilisait jusque-là pour le visuel. Le travail a été fait sans entamer sérieusement son quota hebdomadaire.
#Ce qu'il faut garder en tête
Une partie de la vidéo relève de l'opinion. Nate B Jones estime qu'Opus 5.5 a fait mieux que Fable sur son usage, parce qu'il était bien moins cher et plus rapide. Il voit aussi dans cette version la preuve que les retours des utilisateurs sont écoutés, en partie grâce à l'IA utilisée en interne : Anthropic affirme qu'en mai, Claude écrivait plus de 80 % du code fusionné dans sa base de code. Il note enfin que l'écart entre deux sorties majeures de modèles se compte désormais en semaines, autour de 18 jours selon un chiffre qu'il dit avoir vu passer. Ce sont des lectures personnelles et des chiffres rapportés, à prendre comme tels.
#Récapitulatif
- Le prix par token ne dit pas ce que coûte une tâche : relectures, tentatives ratées et corrections comptent aussi.
- Opus 5.5 est affiché à 4 dollars (entrée) et 20 dollars (sortie) par million de tokens, 20 % de moins qu'Opus 5.
- Anthropic annonce environ 40 % de coût en moins sur les charges typiques, ce qui mélange baisse des prix et économie de tokens.
- Selon Nate B Jones, l'efficacité vient surtout de la pilotabilité : un modèle qui respecte ton intention te fait moins recommencer.
- Pour les tâches longues, fixe une définition de « terminé » et des conditions d'arrêt.
- Pour juger un modèle, rejoue tes propres tâches, mesure tokens, coût, quota et corrections, et garde la trace des échecs.