Le coût par tâche de Claude Opus 5.5 est inférieur, mais les prix des jetons n’en expliquent que la moitié

Anthropic a réduit de 20 % les tarifs des jetons de Claude Opus 5.5, mais le coût estimé par tâche de Claude Opus 5.5 peut diminuer davantage. Les lectures de cache coûtent 60 % moins cher que sur Opus 5, ce qui modifie l’économie des longues sessions Claude Code.

Claude Devs a mis en évidence cette différence au moyen d’une analyse du coût par tâche et d’un calculateur interactif publiés le 22 septembre 2026. L’analyse invite les développeurs à mesurer le travail achevé, plutôt qu’à comparer des tarifs de jetons isolés.

Cette distinction est au cœur de la véritable comparaison entre Opus 5.5 et Opus 5. Un jeton moins cher ne garantit pas qu’une fonctionnalité, une migration ou une session de débogage coûtera moins cher. Le nombre de tours, le comportement du cache, la sortie de raisonnement, les reprises et les paramètres du modèle déterminent le résultat final.

Ce qui a changé dans le coût par tâche de Claude Opus 5.5

Anthropic a abaissé chaque grande catégorie de jetons, mais les lectures de cache ont bénéficié de la réduction la plus importante.

Les tarifs des jetons d’entrée et de sortie sont chacun inférieurs de 20 % à leurs équivalents d’Opus 5. Les lectures de cache sont 60 % moins chères, selon l’annonce du modèle d’Anthropic.

Cette différence compte parce que Claude Code renvoie à plusieurs reprises au modèle les éléments des échanges précédents. Le matériel réutilisé comprend souvent des instructions, des fichiers source, des résultats d’outils et le travail accompli jusque-là.

La mise en cache des prompts permet au service de reconnaître du contenu déjà traité. Une lecture de cache récupère ce contexte réutilisable à un tarif inférieur à celui de son traitement comme nouvelle entrée.

Anthropic indique que les lectures de cache représentent l’essentiel du volume de jetons dans de nombreuses charges de travail de programmation et d’agents. Cette affirmation décrit la composition des jetons, pas nécessairement le poste le plus élevé de chaque facture.

La sortie peut toujours dominer le coût final, car le raisonnement et le texte généré sont facturés comme jetons de sortie. Une session avec peu d’entrée mais un raisonnement étendu peut moins bénéficier de lectures de cache moins chères.

L’analyse officielle du coût par tâche sépare ces effets. Elle commence par comparer les deux modèles avec des volumes de jetons identiques, afin d’isoler l’évolution tarifaire.

Sa session illustrative contient un volume important de contexte mis en cache, quelques nouvelles entrées et une quantité plus faible de sortie. Sous ces hypothèses fixes, Opus 5.5 coûte environ 31 % moins cher qu’Opus 5.

Ce résultat se situe entre les réductions annoncées. Il dépasse 20 % parce que la session profite de lectures de cache moins chères, mais reste inférieur à 60 % parce que les autres catégories de jetons comptent aussi.

Anthropic estime séparément que les charges de travail typiques coûtent environ 40 % moins cher avec les paramètres par défaut. Cette estimation plus large inclut à la fois les tarifs inférieurs et l’anticipation de l’entreprise selon laquelle Opus 5.5 réalise le travail plus efficacement.

Il s’agit d’affirmations différentes. Les chiffres de 20 % et 60 % découlent directement des changements de tarifs publiés. L’exemple à 31 % dépend d’une composition illustrative de jetons.

La réduction estimée à 40 % ajoute des hypothèses sur le comportement du modèle. Les développeurs ne devraient pas l’appliquer automatiquement à chaque dépôt, prompt ou workflow de programmation.

Opus 5.5 est devenu disponible le 22 septembre via l’API Claude et plusieurs grandes plateformes cloud. Le modèle a également intégré Claude Code et les produits par abonnement d’Anthropic.

Sa présentation du modèle mentionne une fenêtre de contexte d’un million de jetons et un réglage d’effort moyen par défaut. La réflexion adaptative est toujours active.

Ces détails influencent les coûts au-delà de la nouvelle grille tarifaire. Un contexte disponible plus large peut soutenir des sessions plus longues, tandis que la réflexion adaptative ajoute de la sortie facturable selon la difficulté de la tâche.

Il en résulte un coût unitaire inférieur associé à un total dépendant de la charge de travail. Le changement de tarif crée l’opportunité, mais le chemin suivi par l’agent dans une tâche détermine la part qui se matérialise.

Pourquoi une tâche Claude Code coûte plus que son contexte final

Claude Code paie les traitements répétés au fil des tours, et non seulement la conversation visible à la fin.

Une tâche Claude Code fonctionne en boucle. Le modèle lit le contexte, sélectionne un outil, examine le résultat, met à jour son raisonnement et répète ces étapes.

Chaque boucle crée une nouvelle requête. Cette requête inclut une grande partie de la conversation accumulée lors des tours précédents.

Prenons une session qui commence avec un contexte modéré et s’étend à mesure que Claude lit des fichiers, lance des tests et reçoit la sortie du terminal. La taille de son contexte final n’est pas égale à son volume total d’entrée traité.

Si la tâche exige de nombreux tours, le modèle retrouve à plusieurs reprises le matériel antérieur. La mise en cache des prompts rend ces lectures répétées moins coûteuses, mais ne les rend pas gratuites.

Ce mécanisme explique pourquoi deux sessions aboutissant à des modifications de code similaires peuvent avoir des coûts différents. Un modèle peut repérer immédiatement les fichiers pertinents et terminer après une courte boucle de validation.

Un autre peut examiner le mauvais sous-système, tenter une correction, rencontrer un échec et revenir sur ses pas. La seconde session paie davantage d’appels d’outils, de raisonnement et de contexte répété.

Le nombre de tours agit donc comme un multiplicateur de coût. Chaque tour inutile transporte à la fois son nouveau contenu et la conversation déjà accumulée.

L’exemple d’Anthropic démarre avec un contexte qui est multiplié par six et se poursuit pendant 40 tours. Le volume total d’entrée traité devient bien plus important que la fenêtre de contexte finale.

Réduire cet exemple à 25 tours abaisse fortement le total des entrées. L’économie provient de l’évitement de passages répétés sur une même conversation en croissance.

C’est pourquoi une commande de test fiable peut réduire le coût d’une tâche Claude Code. Le modèle reçoit un signal direct indiquant si sa modification fonctionne.

Sans ce signal, il peut examiner davantage de fichiers ou développer plusieurs explications spéculatives. Une compilation, un test unitaire ou un script de reproduction peuvent raccourcir cette recherche.

Le regroupement d’outils peut produire un effet similaire. Lire plusieurs fichiers liés en une seule passe peut éviter des cycles de requêtes supplémentaires, bien qu’une récupération indiscriminée puisse gonfler le contexte.

L’objectif utile n’est pas le plus petit nombre possible de jetons. C’est le chemin fiable le plus court vers un résultat correct et vérifié.

Cette distinction compte lors de la comparaison entre Opus 5.5 et Opus 5. Un modèle plus récent peut générer davantage de raisonnement durant un tour tout en nécessitant moins de tours au total.

L’inverse peut également se produire. Opus 5.5 utilise toujours la réflexion adaptative, et Anthropic indique qu’il peut réfléchir davantage au même niveau d’effort nommé.

Un développeur qui ne compare que la sortie d’une requête peut manquer la structure complète de la tâche. L’unité significative inclut l’exploration, les modifications, les tests, les corrections et le rapport final.

Les reprises méritent une attention particulière. Une exécution à faible effort qui échoue et doit être répétée peut coûter plus cher qu’une exécution réussie à un paramètre plus élevé.

Il en va de même pour les rétrogradations de modèle. Un modèle plus petit peut économiser des jetons lors d’une recherche, mais un résultat erroné peut envoyer l’agent principal dans un détour coûteux.

L’analyse d’Anthropic présente cela comme un coût par tâche achevée. Cette mesure récompense une exécution précise et pénalise les faux départs, même lorsque le tarif de jeton sous-jacent semble attractif.

Pour les équipes d’ingénierie, la leçon est pratique. Comptez la boucle entière, d’une demande cadrée jusqu’à un résultat vérifié, et non une réponse ou un instantané de contexte.

Les lectures de cache créent le plus grand renversement tarifaire

La réduction la plus importante d’Opus 5.5 s’applique à la catégorie de jetons que les longues sessions d’agents utilisent le plus.

Opus 5 facturait les lectures de cache à un dixième de son tarif standard d’entrée. Opus 5.5 ramène ce rapport à un vingtième.

Combiné au tarif d’entrée inférieur, cela produit la réduction de 60 % des lectures de cache. Les nouvelles entrées et la sortie bénéficient de la réduction plus modeste de 20 %.

Une part élevée de cache rapproche donc une tâche de l’économie la plus importante. Une requête courte avec peu de contexte réutilisé reste plus proche de la réduction de base du tarif des jetons.

Le calculateur d’Anthropic permet aux lecteurs de modifier l’entrée totale, la part mise en cache, la sortie, le volume quotidien de tâches et une hypothèse d’efficacité. Le dernier contrôle représente le nombre inférieur de jetons utilisés par Opus 5.5.

Laisser cette hypothèse d’efficacité à zéro isole la tarification. Toute réduction ajoutée représente une hypothèse sur la manière dont le comportement du modèle modifie la tâche.

Cette séparation est importante. Une grille tarifaire est vérifiable de l’extérieur, tandis que l’efficacité d’un modèle dépend du dépôt et du travail demandé.

Les performances du cache dépendent également du comportement de la session. Des préfixes de prompt stables et un travail continu aident le service à réutiliser du contenu déjà traité.

Plusieurs actions peuvent perturber ce schéma. Changer de modèle oblige la première requête sur le nouveau modèle à traiter la conversation dans un cache différent.

Modifier certains paramètres via un fournisseur cloud ou une passerelle peut également réduire la réutilisation. Connecter un nouveau serveur d’outils au cours d’une session peut modifier la structure du prompt.

De longues pauses peuvent permettre au matériel mis en cache d’expirer. L’effet exact dépend de la durée du cache et de la manière dont les requêtes sont acheminées.

Les écritures de cache ajoutent une autre réserve. L’écriture de nouveau matériel dans le cache coûte plus cher que sa lecture ultérieure.

Le calculateur exclut volontairement les écritures de cache de sa comparaison simplifiée. Cela rend l’outil utile pour comprendre les principales variables, mais pas pour simuler une facture complète.

Le premier passage sur un grand dépôt peut donc rester coûteux. Les économies s’accumulent lorsque les tours suivants réutilisent ce que le modèle a déjà traité.

La compaction introduit un autre compromis. Elle remplace le matériel de conversation plus ancien par un résumé plus court, réduisant le contexte renvoyé lors des requêtes ultérieures.

Toutefois, la compaction crée aussi un nouvel état de prompt. La requête immédiate doit traiter ce résumé, et certains éléments détaillés de contexte peuvent devoir être récupérés à nouveau.

Effacer une session entre des tâches sans rapport peut empêcher un ancien contexte de suivre un travail qui n’en a plus besoin. L’effacer au cours d’une tâche cohérente peut supprimer un contexte mis en cache utile.

Un changement de modèle crée une frontière similaire. Anthropic conseille de changer à une pause naturelle, lorsque le coût de reconstruction du contexte risque moins d’effacer l’avantage du modèle.

Les sous-agents compliquent encore la facture. Chaque sous-agent possède une fenêtre de contexte distincte et renvoie un résumé à la conversation principale.

Cette séparation peut maintenir les recherches volumineuses dans les fichiers hors du contexte principal. Pourtant, chaque sous-agent consomme toujours des jetons et hérite d’un modèle, sauf configuration contraire.

La réduction du cache récompense les sessions longues et cohérentes, mais ne rend pas les conversations interminables optimales. Les anciennes instructions et les résultats d’outils non pertinents peuvent alourdir chaque requête ultérieure.

Les équipes devraient examiner à la fois la part de cache et le total des entrées. Un taux de cache élevé est utile, mais une conversation surdimensionnée peut encore traiter trop de matériel.

Une session bien gérée maintient le contexte réutilisable actif tout en supprimant le travail sans rapport. Cet équilibre compte davantage dans les workflows agentiques que dans un chat à réponse unique.

Opus 5.5 vs Opus 5 est un test de charge de travail

Les économies estimées par Anthropic restent une projection du fournisseur tant que les équipes ne les reproduisent pas sur leurs propres tâches.

L’entreprise indique qu’Opus 5.5 nécessite moins de calcul pour être servi et génère des sorties plus de 30 % plus rapidement qu’Opus 5. Elle rapporte aussi de meilleurs résultats sur plusieurs benchmarks internes.

Ces résultats soutiennent l’argument en faveur d’une meilleure efficacité économique. Ils n’établissent pas une réduction universelle pour les bases de code en production.

Les benchmarks fournissent des comparaisons contrôlées, tandis que les dépôts réels comportent des tests incomplets, des dépendances inhabituelles, des conventions internes et des exigences changeantes. Ces facteurs modifient le chemin suivi par un agent.

La variable la plus incertaine est le nombre de jetons nécessaires pour achever un travail équivalent. Opus 5.5 peut éviter les faux départs, mais la réflexion adaptative peut augmenter la sortie pour certains prompts.

Son effort par défaut est moyen, tandis qu’Opus 5 utilisait par défaut un effort élevé. Une comparaison qui accepte les deux réglages par défaut modifie davantage que la seule version du modèle.

Les conseils de migration recommandent explicitement de recalibrer l’effort. Conserver un ancien paramètre peut produire des résultats trompeurs.

Le modèle introduit également des changements de comportement et d’intégration. La réflexion ne peut pas être désactivée, et plusieurs schémas d’utilisation des outils nécessitent des mises à jour.

Les applications utilisant une ancienne interface d’utilisation de l’ordinateur sur l’API Claude ou Google Cloud doivent migrer vers le nouvel ensemble d’outils. Certaines configurations imposant le choix d’un outil renvoient désormais des erreurs.

Le texte de progression entre les appels d’outils peut également arriver via des blocs de réflexion. Une interface qui ne traite pas ces blocs peut sembler silencieuse pendant l’exécution.

Ces changements ne sont pas de simples détails de migration. Des requêtes échouées, des outils défaillants ou l’absence d’affichage de la progression peuvent entraîner des tentatives supplémentaires et augmenter le coût opérationnel de l’adoption.

Un test équitable entre Opus 5.5 et Opus 5 doit donc maintenir la tâche constante tout en consignant les paramètres. Les deux exécutions nécessitent le même état du dépôt, les mêmes critères d’acceptation et la même commande de validation.

Les développeurs devraient tester de véritables éléments du backlog plutôt que des prompts artificiels. Une petite modification syntaxique révèle peu de choses sur les boucles d’agent, la réutilisation du cache ou la récupération après une mauvaise approche.

Parmi les bons candidats figurent un bug dont la reproduction est fiable, une fonctionnalité couvrant plusieurs fichiers ou une migration disposant d’une suite de tests définie.

Une seule exécution ne suffit pas. L’état du dépôt, la latence des outils et le comportement non déterministe du modèle peuvent modifier le chemin suivi pour accomplir une tâche.

Trois ou quatre tâches appariées fournissent un échantillon initial plus crédible. Les équipes plus importantes devraient regrouper les résultats par type de tâche, plutôt que de présenter une moyenne globale unique.

Les équipes doivent également définir le succès de manière cohérente. Une exécution qui produit un code plausible mais échoue aux tests ne devrait pas être considérée comme une réalisation moins coûteuse.

Le temps de revue humaine fait partie de l’analyse opérationnelle, même s’il n’apparaît pas sur le reçu des tokens. Un patch difficile à comprendre peut mobiliser du temps d’ingénierie après la fin de la génération.

Le rapport final de Claude Code peut aider les réviseurs à comprendre les exécutions plus longues. Anthropic présente des rapports de clôture plus clairs comme une autre source potentielle d’efficacité.

Cet avantage est plausible, mais dépend de la charge de travail. Les équipes devraient mesurer si les réviseurs ont besoin de moins de prompts de suivi ou passent moins de temps à reconstituer les actions de l’agent.

Les preuves publiques indépendantes restent limitées, car Opus 5.5 n’a été lancé que quatre jours avant cette analyse. Les premiers retours d’utilisateurs ne permettent pas encore d’établir une moyenne sectorielle stable.

La conclusion défendable est plus limitée. Opus 5.5 affiche des tarifs publiés inférieurs, et les tâches fortement axées sur le cache bénéficient d’un avantage structurel plus important.

La possibilité que la réduction du coût des tâches terminées approche l’estimation d’Anthropic dépend des tours, de la sortie, du comportement du cache, des nouvelles tentatives et de la qualité de la migration.

Comment mesurer le coût de vos propres tâches Claude Code

La commande `/usage` transforme l’affirmation tarifaire en un test reproductible à partir de vos sessions réelles.

Exécutez /usage lorsqu’une tâche cohérente est terminée. /cost fournit la même vue dans Claude Code.

Le bloc de session indique les entrées, les sorties, les entrées mises en cache et un coût estimé basé sur les tarifs catalogue. Les utilisateurs d’abonnement devraient considérer cette estimation comme un indicateur de travail.

Il ne s’agit pas d’une facture d’abonnement supplémentaire. Les limites du forfait et l’utilisation de l’API facturée au token correspondent à des modalités de facturation différentes.

Commencez par consigner le modèle et le paramètre d’effort. Sans ces détails, deux reçus de session peuvent sembler comparables tout en représentant des modes de fonctionnement différents.

Consignez ensuite la définition de la tâche et le test d’acceptation. Une condition d’achèvement claire évite qu’une exécution s’arrête plus tôt qu’une autre.

Examinez ensuite la part du cache. Une longue session devrait généralement réutiliser une grande partie de ses entrées.

Une faible part de cache peut indiquer des pauses, des changements de modèle, des changements d’effort ou des modifications du prompt. Elle peut également refléter une tâche naturellement courte ou fragmentée.

Comparez le total des entrées avec le plus grand contexte observé. Si le total des entrées est plusieurs fois supérieur, la session a probablement utilisé de nombreux tours.

Cette différence n’est pas automatiquement du gaspillage. Le travail d’ingénierie en plusieurs étapes nécessite naturellement plusieurs requêtes, surtout lorsque les tests révèlent de nouvelles informations.

Toutefois, l’inspection répétée des mêmes fichiers peut révéler une boucle évitable. Examinez la transcription autour de ces répétitions pour identifier les instructions ou outils de validation manquants.

La sortie mérite une vérification distincte, car elle inclut la réflexion interne. Une sortie élevée pour une petite modification mécanique peut indiquer un effort excessif ou des raisonnements répétés.

Pour un test apparié, réinitialisez le dépôt au même état de départ. Exécutez la tâche avec Opus 5 puis Opus 5.5, en alternant l’ordre lors des tests suivants.

Consignez les tours, les entrées nouvelles, les lectures du cache, la sortie, le temps écoulé, les résultats des tests et les corrections humaines nécessaires. Ces champs expliquent mieux le résultat qu’un seul total.

Utilisez le calculateur seulement après avoir recueilli ces mesures. La saisie de quantités réelles de tokens produit une comparaison de tarifs utile.

Maintenez son contrôle d’efficacité à zéro pour le premier calcul. Cela montre comment les changements des tarifs publiés affectent la même charge de travail en tokens.

Calculez ensuite la différence de tokens observée à partir des exécutions appariées. Cette seconde vue combine la tarification avec le comportement réel du modèle.

Ne supposez pas que toutes les tâches futures correspondront à cet échantillon. Distinguez le débogage, le développement de fonctionnalités, la revue de code, la recherche dans le dépôt et les exécutions d’agent sans supervision.

L’effort doit également être testé par catégorie de tâche. Un effort moyen peut convenir au travail quotidien bien délimité, tandis que des échecs difficiles peuvent justifier un effort élevé.

Un faible effort peut convenir aux modifications déterministes, mais seulement lorsque la vérification rend les erreurs peu coûteuses à détecter. Une tentative à faible effort qui échoue affaiblit toute économie apparente.

Les équipes utilisant des passerelles doivent effectuer une vérification supplémentaire. La passerelle doit préserver les champs de mise en cache des prompts et d’utilisation, faute de quoi les rapports internes peuvent mal représenter l’économie des sessions.

La documentation d’Anthropic sur les passerelles décrit le suivi centralisé de l’utilisation, les budgets et l’attribution des requêtes. Elle avertit également que des passerelles obsolètes peuvent bloquer des fonctionnalités plus récentes.

Les grandes organisations peuvent utiliser les rapports d’utilisation pour agréger les résultats par développeur et par modèle. Les totaux par utilisateur restent à eux seuls insuffisants sans les résultats des tâches.

Un indicateur interne utile associe les tâches terminées à la consommation de tokens. Un autre suit les nouvelles tentatives qui surviennent après des tests échoués ou un rejet par les réviseurs.

Les équipes peuvent conserver de brèves notes d’expérimentation à côté des décisions d’ingénierie. Une base de connaissances technique consultable peut préserver les prompts, les paramètres, les résultats et les constats de migration.

Ce registre aide à distinguer les changements de modèle des changements de processus. Il évite également à chaque équipe de répéter le même benchmark sans méthodologie commune.

L’objectif n’est pas d’optimiser chaque session pour obtenir le reçu le plus faible. Il s’agit d’identifier des paramètres qui fournissent du code accepté avec un coût et un effort de revue prévisibles.

Trois signaux montreront si les économies se confirment

Le prochain test consistera à déterminer si des tarifs plus faibles se traduisent par une sortie stable et vérifiée dans le cadre du travail d’ingénierie courant.

Le premier signal sera constitué des données /usage appariées provenant de projets réels. Des réductions répétées dans le débogage, le développement de fonctionnalités et la revue renforceraient l’argument du coût par tâche.

Ces comparaisons devraient publier les catégories de tokens et les critères de réussite. Un pourcentage mis en avant sans part de cache, effort ni nouvelles tentatives ne peut expliquer ce qui a changé.

Le deuxième signal est la stabilité du cache durant les longues sessions. Les équipes devraient surveiller si Opus 5.5 maintient une forte réutilisation du cache entre les appels d’outils, la compaction et les transitions de modèle.

Des parts de cache systématiquement faibles affaibliraient l’avantage attendu. Elles suggéreraient que la conception du flux de travail ou l’infrastructure empêche les utilisateurs d’atteindre le tarif de cache avantageux.

Le troisième signal est la fréquence des nouvelles tentatives après migration. Opus 5.5 modifie les paramètres d’effort par défaut, le comportement de réflexion et plusieurs interfaces d’outils.

Moins de boucles échouées appuierait l’affirmation d’Anthropic selon laquelle le modèle accomplit le travail plus efficacement. Davantage d’erreurs d’intégration pourraient temporairement effacer les économies publiées.

Les développeurs devraient aussi éviter de réduire la comparaison au seul Opus 5. Des modèles Claude plus petits peuvent rester mieux adaptés à la recherche, à la lecture de journaux et aux résumés peu coûteux.

La décision pertinente est l’affectation des charges de travail. Opus 5.5 peut servir de modèle principal pour le codage supervisé, tandis que des modèles plus petits prennent en charge la récupération délimitée.

Les tâches difficiles et sans supervision peuvent justifier un modèle plus capable s’il évite plusieurs échecs. Le chemin le moins coûteux vers la réussite peut commencer avec un modèle plus cher.

Le calculateur d’Anthropic améliore cette discussion en exposant les variables à l’origine de l’estimation. Il ne tranche pas le résultat pour une équipe donnée.

Le coût par tâche de Claude Opus 5.5 est inférieur à consommation de tokens égale, en particulier lorsque les lectures de cache dominent les entrées. La réduction exacte reste une question empirique.

Choisissez un véritable élément du backlog, définissez son test de réussite et exécutez-le une fois sur chaque modèle. Comparez /usage, les tours, la sortie, la part de cache et les corrections de revue.

Répétez ce processus pour plusieurs types de tâches avant de modifier un paramètre par défaut à l’échelle de l’équipe. Si Opus 5.5 termine avec moins de nouvelles tentatives, la réduction tarifaire se cumule.

S’il consomme davantage de raisonnement ou perturbe une intégration, l’économie annoncée se réduira. Le mois à venir de mesures de production appariées comptera davantage que n’importe quel préréglage unique du calculateur.