Claude Opus 5.5 consomme-t-il vraiment moins de jetons ?

Claude Opus 5.5 serait plus efficace en jetons parce qu’il aurait besoin de moins d’étapes et de reprises pour terminer une tâche. Mais le prix par jeton ne suffit pas à mesurer le coût réel : il faut comparer la consommation complète et le résultat obtenu.

Qu’est-ce qui réduit la consommation de jetons ?

Oui, mais l’efficacité annoncée vient surtout d’un nombre réduit d’étapes, de tentatives et de demandes de clarification. Si Opus 5.5 atteint le résultat avec moins d’allers-retours, il peut consommer moins de jetons au total. C’est différent d’une baisse du prix de chaque jeton.

Prix annoncé pour Opus 5.5	4 dollars par million de jetons d’entrée et 20 dollars par million de jetons de sortie.
Évolution face à Opus 5	Une baisse de 20 % des tarifs unitaires.
Coût des tâches courantes	Anthropic estime qu’il diminue d’environ 40 %.

Les deux baisses ne décrivent pas la même chose. Les 20 % concernent le prix unitaire. Les 40 % sont une estimation d’Anthropic sur le coût de tâches courantes, qui peut aussi dépendre du volume consommé. Un tarif plus bas ne signifie donc pas, à lui seul, que le modèle utilise moins de jetons.

Pour comparer deux exécutions, il faut regarder la consommation totale liée à la tâche : jetons d’entrée, de sortie, mis en cache et de contexte. Le contexte correspond aux informations conservées ou transmises au modèle pour répondre. Selon la tâche et la façon dont elle est mesurée, ces catégories peuvent se recouper ; il faut éviter de les additionner deux fois.

La création d’un modèle Lego peut servir d’illustration : si Opus 5.5 réalise la tâche avec moins d’étapes, de tentatives ou de clarifications, le volume consommé peut baisser. Sans mesure comparable, cet exemple ne permet pas de conclure que la baisse est systématique. La bonne comparaison porte sur le coût complet d’une tâche identique, pas seulement sur le prix affiché par million de jetons.

Combien coûte réellement une tâche complète ?

Le coût réel dépend du mode de facturation et de la consommation totale, pas seulement du tarif affiché par jeton. Une même tâche peut donc représenter plusieurs dizaines de dollars au tarif API et une fraction d’un forfait, sans que ces montants soient directement comparables.

L’exemple rapporté porte sur la transformation d’un logo en modèle Lego de 514 pièces. Le travail comprenait aussi une séquence animée, un livret d’instructions de 63 pages, une liste de pièces et des fichiers de vérification. La tâche aurait consommé 89 millions de jetons. Au tarif API, cela représente au moins 44 dollars.

Le même article estime pourtant que cette tâche équivaut à environ 1 % d’un forfait hebdomadaire de 50 dollars. Cette estimation décrit la consommation dans le cadre de l’abonnement, pas une facture API calculée au même tarif. Un forfait peut donner accès à une capacité d’usage selon des règles différentes ; son coût apparent par tâche ne se déduit donc pas en appliquant simplement le prix API aux jetons consommés.

Il faut aussi garder une limite importante en tête : la répartition entre jetons d’entrée et jetons de sortie n’est pas fournie. Je ne peux donc pas recalculer le montant API plus précisément à partir des seuls 89 millions de jetons, ni déterminer quelle part vient des prompts, des réponses ou des échanges intermédiaires.

La comparaison utile n’est pas « 44 dollars contre 50 centimes », mais « facturation à l’usage contre forfait ». Pour estimer le coût d’une tâche en production, je regarde le mode de facturation réellement utilisé, le volume total consommé et les limites du forfait. Le tarif par jeton, pris isolément, ne suffit pas.

Pourquoi mesurer le coût par tâche ?

Oui, le coût par tâche intègre les reprises et toutes les étapes nécessaires pour obtenir un résultat exploitable. Un tarif unitaire plus faible ne garantit donc pas une facture totale plus basse : si le modèle multiplie les appels, relit plusieurs fois les fichiers ou corrige son propre résultat, la consommation cumulée peut dépasser celle d’un modèle plus cher qui réussit en moins d’étapes.

Le prix affiché au million de jetons ne raconte qu’une partie de l’histoire. Pour comparer deux modèles, il faut compter les jetons d’entrée et de sortie sur l’ensemble de l’exécution, ainsi que les tentatives abandonnées ou les corrections nécessaires. Le critère utile, c’est le coût pour livrer un résultat acceptable, pas le coût d’un appel isolé.

Les éléments de lancement d’Anthropic rapportent des retours attribués à GitHub, Lovable et Spotify qui évoquent moins d’étapes, une réduction des coûts ou une exécution plus rapide. Ce sont des observations faites dans des contextes précis, pas des garanties générales. Une tâche de génération de code, une analyse documentaire et un agent qui enchaîne des actions n’ont ni le même profil de consommation ni les mêmes critères de réussite.

Pour évaluer Opus 5.5, je comparerais les modèles sur une même tâche réelle, avec le même contexte et le même niveau d’exigence. Je mesurerais le coût complet, le nombre d’étapes et la qualité du livrable. Il faut aussi répéter le test : une seule exécution ne permet pas de distinguer une tendance d’un résultat chanceux.

La lecture du coût devient alors plus claire :

Mesure	Ce qu’elle indique
Tarif unitaire	Le prix des jetons pour un appel, selon leur type.
Consommation totale	Les jetons utilisés sur toutes les étapes et reprises.
Coût final	La dépense complète pour obtenir un livrable exploitable.

L’écriture est-elle plus facile à ajuster ?

Opus 5.5 aurait été amélioré pour mieux suivre les consignes et produire une écriture plus claire. Les informations disponibles ne permettent toutefois pas de mesurer précisément l’ampleur de ce progrès. Je le traiterais comme un objectif attribué à Anthropic, pas comme une garantie valable pour chaque tâche.

Les critiques formulées sur des versions antérieures de Claude portaient notamment sur la difficulté à orienter certaines réponses et sur un ton parfois argumentatif. C’est un point concret pour les usages éditoriaux : un texte peut être bien rédigé tout en s’écartant du ton demandé, en ajoutant des précautions inutiles ou en défendant une position que vous ne lui avez pas demandée.

Pour vérifier si l’ajustement est réellement plus simple, je comparerais Opus 5.5 à une autre version avec les mêmes consignes, les mêmes contenus et le même niveau de contexte. Il faut éviter de changer le prompt entre les essais : sinon, on ne sait plus si l’écart vient du modèle ou de la consigne.

Je suivrais quatre critères observables :

• Le format : le modèle respecte-t-il la structure, la longueur et les éléments explicitement demandés ?
• Le ton : le texte correspond-il au registre attendu, sans dérive argumentative ou emphatique ?
• Les contraintes : les interdictions, le vocabulaire et les consignes prioritaires sont-ils respectés ?
• Les corrections : combien de retouches faut-il pour obtenir un texte publiable, et de quel type ?

Le dernier critère compte souvent davantage qu’une impression générale de fluidité. Si vous devez réécrire chaque passage pour neutraliser le ton ou rétablir les contraintes, l’écriture n’est pas vraiment plus facile à piloter. Je ne dispose pas ici de résultats comparatifs qui permettraient d’affirmer qu’Opus 5.5 réduit effectivement le nombre de corrections. La conclusion prudente : l’amélioration est plausible et annoncée, mais elle doit être vérifiée sur vos propres tâches rédactionnelles.

Comment éviter qu’un agent consomme trop de jetons ?

Un agent persistant doit recevoir une consigne d’arrêt explicite. Sans limite claire, il peut continuer à travailler et à consommer des jetons sans que le résultat s’améliore. Le risque ne se mesure donc pas uniquement au tarif unitaire du modèle : il faut regarder le coût complet pour obtenir une tâche terminée.

Un modèle moins coûteux par jeton n’est pas nécessairement moins coûteux à l’usage. Si l’agent multiplie les échanges ou les étapes, la consommation totale peut augmenter. À l’inverse, réduire les étapes peut faire baisser le coût par tâche, à condition de conserver le résultat attendu. C’est cette mesure qui permet de comparer utilement deux configurations, y compris Claude Opus 5.5.

Pour maîtriser la consommation, je définis d’abord le résultat attendu, puis le critère qui marque la fin du travail. La consigne doit indiquer clairement quand l’agent a suffisamment d’éléments pour s’arrêter, plutôt que de lui demander de poursuivre jusqu’à obtenir un résultat vague comme « la meilleure réponse possible ». Je suis ensuite les jetons consommés sur l’ensemble de la tâche, pas seulement sur un échange ou une étape.

Cette lecture évite un faux gain : un tarif unitaire plus bas peut masquer davantage d’étapes ou une consommation totale plus élevée. L’indicateur utile reste le coût nécessaire pour produire le résultat attendu. Si la tâche peut être accomplie avec moins d’étapes sans dégrader ce résultat, la réduction de consommation est réelle.

Leviers de maîtrise :

• Définir une consigne d’arrêt explicite.
• Suivre la consommation totale de jetons.
• Mesurer le coût complet par tâche.

Comment évaluer le coût réel d’Opus 5.5 ?

Claude Opus 5.5 est présenté comme un modèle qui réduit le coût des tâches en combinant un tarif par jeton plus bas et une exécution qui demanderait moins d’étapes. L’exemple du modèle Lego montre pourquoi il faut distinguer le coût API théorique d’un usage sur abonnement. Pour comparer les modèles, mesurez la consommation complète, les reprises nécessaires et la qualité du livrable sur vos propres tâches. Les gains rapportés par Anthropic et ses partenaires restent à confronter à votre contexte. Pour les agents persistants, fixez un critère d’arrêt explicite et surveillez les jetons consommés. Vous obtenez ainsi une mesure plus utile du coût réel et pouvez choisir le modèle qui améliore effectivement votre performance.

FAQ

• Pourquoi Opus 5.5 serait-il plus efficace en jetons ?
  L’efficacité annoncée viendrait du fait qu’il aurait besoin de moins d’étapes, de tentatives et de clarifications pour terminer certaines tâches.
• Quels sont les tarifs indiqués pour Claude Opus 5.5 ?
  Les tarifs rapportés sont de 4 dollars par million de jetons d’entrée et de 20 dollars par million de jetons de sortie, soit une baisse annoncée de 20 % par rapport à Opus 5.
• Pourquoi le prix par jeton ne suffit-il pas ?
  Le coût total dépend aussi du volume consommé, des reprises et des catégories de jetons utilisées, notamment les jetons d’entrée, de sortie, mis en cache et de contexte.
• Que montre l’exemple du modèle Lego ?
  La tâche aurait consommé 89 millions de jetons et coûté au moins 44 dollars au tarif API. L’article la rapporte aussi à environ 1 % d’un forfait hebdomadaire de 50 dollars, deux modes de facturation qui ne sont pas directement comparables.
• Comment limiter la consommation d’un agent persistant ?
  Définissez clairement le résultat attendu et un critère d’arrêt, puis surveillez la consommation complète de jetons plutôt que le seul tarif unitaire.

 

 

A propos de l’auteur

Franck Scandolera accompagne les équipes dans la mesure de la performance digitale et l’automatisation IA. Il s’intéresse notamment au coût réel des workflows agentiques et à leur efficacité sur des tâches métier concrètes.