Claude 5.5 : Arrêtez de payer pour les tâches échouées

La configuration Sonnet et Opus qui compte vraiment : effort, cache, vérification et coût par tâche terminée

Le modèle le moins cher n'est pas celui dont le prix au token est le plus bas

C'est celui qui termine le travail, passe la vérification et ne vous oblige pas à payer cinq fois pour le même contexte

Sonnet 5.5 et Opus 5.5 rendent cette distinction particulièrement cruciale. L'un est tarifé pour le volume. L'autre pour les tâches complexes. Les deux adoptent un nouveau comportement d'effort et peuvent s'avérer étonnamment économiques au sein d'une boucle d'agent bien optimisée par le cache

Copiez votre ancienne configuration dans l'un ou l'autre modèle et vous risquez d'obtenir un résultat plus lent, plus coûteux, voire une erreur 400

Voici plutôt la configuration que je mettrais en place

1TÂCHE → SONNET 5.5 → VÉRIFICATION → OPUS 5.5 SI NÉCESSAIRE → RÉSULTAT VALIDÉ
2             ↘ effort ↗         ↘ registre de cache + utilisation ↗

Je publie des analyses pratiques sur les agents IA, les workflows et les systèmes de production sur Substack

Abonnez-vous à la newsletter ici

La métrique qui devrait dicter votre stack

La plupart des comparaisons de modèles commencent par le prix en dollars par million de tokens

Votre agent ne livre pas des tokens. Il livre des tâches accomplies

https://x.com/claudeai/status/2102435511222890900

Encore une fois : ce sont leurs tests. Votre architecture a besoin de vos propres chiffres

Cela signifie que la vérification ne peut pas se résumer à un vague pouce levé après avoir lu une réponse impressionnante. Pour le code, utilisez le test qui bloquerait le merge. Pour l'extraction, comparez les champs requis avec un jeu de données annoté. Pour la recherche, vérifiez si la source citée étaye réellement chaque affirmation. Intégrez le coût des tâches qui échouent systématiquement, et pas seulement les beaux exemples de votre démo

Analysez également la traîne difficile séparément. Si le paramètre le moins économique traite 90 % de vos requêtes mais engloutit la moitié du budget sur les 10 % restants, sa moyenne peut masquer la partie du workflow qui nécessite un autre modèle

Ce que dit vraiment la grille tarifaire de la 5.5

Au 3 octobre 2026, aux tarifs standard de l'API Claude, par million de tokens :

1SONNET 5.5
2Entrée fraîche  $2       Sortie  $10
3Lecture cache   $0.20    Écriture cache  $2.50 / 5m, $4 / 1h
4
5OPUS 5.5
6Entrée fraîche  $4       Sortie  $20
7Lecture cache   $0.20    Écriture cache  $5 / 5m, $8 / 1h

Les deux modèles disposent d'une fenêtre de contexte de 1M de tokens et d'une sortie maximale de 128K tokens. Ce sont des plafonds, pas une invitation à les saturer.

Spécifications et tarification des modèles

La ligne inhabituelle concerne la lecture du cache

Opus coûte deux fois plus cher en entrée et sortie fraîches, mais un préfixe mis en cache revient exactement au même prix de 0,20 $ par million sur les deux modèles. Cela ne rend pas une exécution Opus aussi bon marché : elle paie toujours plus pour les nouvelles entrées, les sorties et les écritures dans le cache. En revanche, cela signifie que l'écart de prix entre les modèles peut se réduire lors d'une session gourmande en lectures

Il y a une deuxième nuance qui échappe souvent. Le « 40 % de moins qu'Opus 5 » annoncé par Anthropic est une estimation du \coût d'exécution\ typique. Les prix des tokens frais d'Opus 5.5 ont baissé de 20 % ; son prix de lecture du cache a chuté de 60 %. Ces chiffres sont liés, mais ils ne sont pas interchangeables

L'effort est une décision de routage, pas un curseur de qualité

Sonnet 5.5 prend en charge low, medium, high, xhigh et max. Sur l'API, la valeur par défaut est high ; dans les applications Claude, Anthropic indique que medium est le réglage par défaut. Opus 5.5 utilise medium par défaut sur l'API. Ces niveaux ne correspondent pas exactement à ce que ces mêmes termes signifiaient sur les modèles précédents.

Ma cartographie de départ :

• Sonnet low Pour les requêtes ciblées et sensibles à la latence, assorties d'une vérification peu coûteuse
• Sonnet medium Pour le développement bien spécifié et les tâches multi-étapes courantes
• Sonnet high Quand l'exécution medium échoue à une véritable vérification, ou que la tâche présente un schéma de complexité avéré
• Opus medium Pour les travaux ambigus, multi-fichiers et à long terme où Sonnet tourne en rond
• Xhigh/max Uniquement si vos évaluations montrent un gain justifiant le temps et les tokens supplémentaires

Il s'agit d'une hypothèse de départ, pas d'une hiérarchie universelle. Dans les résultats FrontierCode publiés par Anthropic pour Sonnet 5.5, xhigh a obtenu un meilleur score que max. Plus d'effort ne garantit pas un meilleur résultat

La note de bas de page d'Anthropic explique ce résultat contre-intuitif : au niveau max, le modèle lançait plus souvent des tâches de revue de code supplémentaires. Dans deux cas examinés, cela a entraîné un timeout ou des modifications hors du périmètre de la tâche.

Le mode d'échec n'était pas « le modèle n'a pas assez réfléchi », mais un effort dépensé au mauvais endroit. Si votre agent passe déjà ses vérifications, des tours de revue supplémentaires peuvent devenir un coût et une source de nouvelles erreurs

https://x.com/edwinarbus/status/2104675431853248816

Par ailleurs, ne baissez pas max_tokens en pensant faire une optimisation. Cette limite englobe la réflexion et la sortie visible. Si vous la coupez en pleine tâche, vous paierez une réponse tronquée suivie d'une seconde exécution, au lieu de faire des économies

https://x.com/claudeai/status/2104633115620823187

C'est une promesse de lancement séduisante. Mais une configuration de production doit tout de même battre votre propre base de référence

Faites un petit balayage avant d'inventer un routeur de modèles

Prenez 10 à 30 tâches qui comptent vraiment pour vous. Incluez du travail facile, des cas ambigus et les échecs agaçants tirés de vos logs. Attribuez à chaque tâche un vérificateur : des tests, une comparaison structurée, une réponse connue ou une grille d'évaluation humaine définie avant l'exécution

Voici la sonde API utile la plus simple. Elle journalise les champs d'utilisation nécessaires. Exécutez-la sur chaque modèle et niveau d'effort avec la même tâche, puis ajoutez votre propre contrôle de réussite/échec. Ce n'est pas un benchmark complet d'agent

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # répéter avec claude-opus-5-5
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # répéter avec high
8    messages=[{"role": "user", "content": "Remplacez ceci par une vraie tâche."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("fresh", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

Ceci suppose l'utilisation du package Python officiel Anthropic et d'une variable d'environnement ANTHROPIC_API_KEY. Il s'agit d'un appel isolé sans cache activé, donc aucune lecture ni écriture de cache n'est attendue. La section suivante montre ce qui change cela

Pour un véritable agent, additionnez l'utilisation sur tous les appels API liés à un même ID de tâche, y compris les tentatives et les appels d'outils. Ne comptez une réussite que lorsque le vérificateur confirme que le travail est terminé

Comparez le coût total en dollars par réussite avant de choisir votre valeur par défaut

Gardez le test honnête :

• Figez le jeu de tâches et le vérificateur avant de comparer les configurations
• Appliquez les mêmes outils, permissions, contextes et exigences de sortie à chaque candidat
• Notez le taux de réussite, la dépense totale, le coût par réussite, la latence, ainsi que les échecs les plus longs ou les plus coûteux
• Considérez stop_reason: "max_tokens" comme une tentative incomplète, et non comme une réussite économique

L'exemple de code ci-dessus utilise une limite de sortie de 8K pour une sonde à un seul tour. Ne reprenez pas cette limite pour un agent de codage de longue haleine.

Anthropic recommande beaucoup plus de marge pour le travail agentique, car la réflexion masquée est décomptée dans cette même limite.

Fixez la limite en fonction du travail, puis contrôlez la dépense via l'effort, le cache et un budget par tâche, plutôt que de forcer l'arrêt de la réponse en plein milieu

Mettez en cache la partie stable du travail

Les agents envoient sans cesse les mêmes instructions système, définitions d'outils, cartographies de dépôt et conversations antérieures. Si ce préfixe est stable, la mise en cache du prompt modifie l'équation économique bien plus qu'une légère réécriture du prompt

Par exemple, 200K tokens mis en cache et lus 50 fois représentent 10M de tokens lus depuis le cache. À 0,20 $ le million, ces lectures coûtent 2 $ sur n'importe lequel des modèles 5.5.

Sur Opus 5.5, envoyer ces mêmes 10M de tokens en entrée fraîche coûterait 40 $. La première écriture en cache de 200K tokens (valable cinq minutes) ajoute 1 $.

Il s'agit d'une illustration portant uniquement sur les frais de préfixe : les nouvelles entrées, sorties, autres écritures, expirations TTL et véritables défauts de cache alourdissent la facture

Les règles pratiques :

• Sur l'API Claude, activez la mise en cache du prompt avec cache_control={"type": "ephemeral"} au niveau supérieur ou via des points d'arrêt de cache explicites. La sonde ci-dessus ne fait ni l'un ni l'autre, ses compteurs de cache resteront donc normalement à zéro
• Placez les instructions et outils stables avant la requête utilisateur variable
• Conservez un préfixe partagé identique d'un tour à l'autre ; vérifiez les cache_read_input_tokens réels
• Traitez un changement de modèle comme un nouveau budget de conversation, et non comme une continuation gratuite. Le cache est spécifique au modèle : une requête Opus ne peut pas lire le préfixe que Sonnet vient de mettre en cache
• Évitez de modifier l'effort de premier niveau à chaque tour ; cela altère le prompt généré et invalide les préfixes mis en cache

Sur les modèles compatibles, un changement d'effort par message peut préserver le cache précédent, mais cela nécessite l'en-tête bêta d'Anthropic et diffère de la modification de l'output_config global.

Sonnet 5.5 comporte également une restriction between_tools : l'effort ne peut pas être modifié en cours de conversation dans ce mode.

Documentation sur la mise en cache des prompts

Ne déduisez pas un succès de cache d'une réponse rapide. Lisez l'objet usage. Il sépare l'entrée fraîche, la création de cache et les lectures de cache

Les deux modèles 5.5 nécessitent au moins 512 tokens dans un préfixe pouvant être mis en cache. Un minuscule prompt système ne générera pas les économies de l'exemple précédent. La durée de vie par défaut du cache est de cinq minutes, ce qui convient parfaitement à une boucle d'outils rapide.

Une écriture d'une heure coûte plus cher et ne se justifie que si vos sessions réelles font souvent des pauses suffisamment longues pour dépasser la fenêtre de cinq minutes. Mesurez ces écarts avant de payer pour un TTL plus long

Escaladez sur la base de preuves, pas d'anxiété

La plupart des équipes construisent le routeur à l'envers : elles classent une tâche comme « difficile », l'envoient au modèle coûteux et ne découvrent jamais si l'option moins chère aurait suffi

Utilisez le vérificateur comme signal de routage

11  Sonnet 5.5 · effort choisi  → exécuter la tâche
22  Vérificateur                → accepter si réussite
33  Opus 5.5 · medium           → réessayer uniquement sur preuve d'échec
44  Vérificateur                → accepter ou transmettre avec preuves

La vérification peut être une suite de tests, une validation de schéma, une réponse connue ou un relecteur. Elle doit expliquer ce qui a échoué.

« La réponse semble faible » est un mauvais signal d'escalade ; « l'endpoint modifié échoue à deux tests d'intégration » est utile

Ne répétez pas aveuglément un prompt identique. Fournissez à la tentative suivante la vérification échouée, les artefacts pertinents et une instruction précise pour corriger l'écart. Limitez les échelons pour éviter qu'un agent ne brûle son budget à tenter de corriger une tâche nécessitant une décision humaine

Vous pouvez tester une nouvelle tentative avec Sonnet high lors de votre balayage hors ligne. Ne la conservez dans le parcours en direct que si elle réduit le coût par tâche validée. Rien n'oblige à faire payer deux exécutions Sonnet pour chaque échec avant de passer à Opus

Le changement de modèle lui-même peut casser un préfixe mis en cache. Prenez-le en compte lorsque vous comparez le parcours de secours à une approche Opus d'emblée

Le point de bascule est facile à manquer. Supposons qu'une tentative Sonnet coûte 0,06 $ et réussisse 80 % de vos tâches.

Si chaque tâche échouée coûte ensuite 0,20 $ à terminer sur Opus, votre moyenne illustrative est de 0,10 $ par tâche achevée : 0,06 $ plus un secours à 0,20 $ pour une tâche sur cinq. C'est mieux que de payer 0,20 $ pour Opus sur chaque tâche. Mais si Sonnet coûte 0,14 $ et ne réussit qu'une fois sur deux, le même parcours coûte 0,24 $, avant même de facturer le changement de modèle. Dans cette charge de travail, l'approche Opus d'emblée est moins chère et plus rapide

Ces chiffres sont des exemples, et non des résultats mesurés sur Claude. Leur but est de rendre la règle de routage réfutable. Le parcours en escalier ne se justifie que si les appels Opus économisés compensent les tentatives Sonnet échouées, les défauts de cache et la latence ajoutée

Il existe aussi une voie médiane : l'outil advisor en bêta d'Anthropic. Sonnet peut continuer à exécuter la tâche et demander de l'aide à Opus pour une décision difficile, au lieu de lui confier l'intégralité du travail.

Ce n'est pas automatiquement moins cher. Journalisez la fréquence à laquelle Sonnet consulte réellement l'advisor, le coût de ces appels et leur impact sur le taux de réussite final. Si l'exécuteur sollicite rarement l'advisor, cette fonctionnalité reste inutilisée

Avec ces modèles 5.5, le conseil lui-même est renvoyé chiffré au client. Évaluez donc le travail produit plutôt que de prétendre pouvoir auditer le texte privé du conseil

Quatre fuites qui gonflent la facture avant même que le choix du modèle n'entre en jeu

Tout problème de coût ne justifie pas un nouveau routeur

Vérifiez d'abord ces points :

• Une sortie qui ne cesse de grossir Sur les deux modèles 5.5, les tokens de sortie coûtent cinq fois plus cher que les tokens d'entrée fraîche. Dans une conversation, une longue réponse peut aussi revenir comme contexte lors des tours suivants. Demandez l'artefact et une brève note d'achèvement, pas un récit détaillé de chaque étape. La réflexion masquée est également facturée en sortie, donc une réponse finale concise ne résoudra pas à elle seule un problème d'effort. Ne supprimez pas les éléments de preuve nécessaires à la validation du résultat
• Des images plus grandes que nécessaire Sonnet 5.5 peut traiter des images en plus haute résolution que les anciennes versions de Sonnet, ce qui peut augmenter le nombre de tokens d'image. Si l'agent n'a besoin que du libellé d'un bouton ou d'un paragraphe, recadrez ou redimensionnez d'abord. S'il lui faut un graphique dense ou de minuscules détails d'interface, conservez la résolution et mesurez le coût au lieu de la réduire aveuglément
• Un contexte que personne n'utilise Les définitions d'outils, les logs obsolètes, les anciens résultats de recherche et un CLAUDE.md tentaculaire peuvent accompagner chaque requête. Placez les règles durables dans un court préfixe stable ; gardez les preuves temporaires près de la tâche qui en a besoin. Réduire le contexte ne doit pas supprimer des faits dont le modèle a encore besoin pour terminer correctement
• Une tarification interactive pour un travail que personne n'attend L'API Message Batches offre une réduction de 50 % sur les entrées et sorties pour les deux modèles. Elle est idéale pour les évaluations hors ligne, les backfills de documents et autres tâches asynchrones. Elle ne remplace pas une boucle d'outils en direct où quelqu'un a besoin de l'étape suivante immédiatement

Le principe est le même pour ces quatre points : éliminez le travail superflu avant d'acheter plus d'intelligence ou de réduire l'effort jusqu'à dégrader la qualité

Les pièges de migration qui transforment une économie en erreur 400

Les anciens corps de requête constituent un mauvais point de départ pour la famille 5.5.

En particulier :

• La réflexion d'Opus 5.5 est toujours activée Supprimez thinking: {"type": "disabled"} et les anciens paramètres fixes budget_tokens ; contrôlez la profondeur avec output_config.effort
• Le choix d'outil forcé échoue sur les deux modèles 5.5

Les valeurs any et tool de tool_choice renvoient une 400. Utilisez auto, précisez quand l'outil doit être employé et validez le résultat de l'outil dans votre propre code

• Les blocs de réflexion ne sont pas des blocs de texte Lisez le contenu par type, et non par content [0]. Dans les boucles d'outils, renvoyez les blocs de réflexion inchangés avec le tour de l'assistant
• Votre interface peut sembler muette Sur Opus 5.5, la progression entre les outils peut arriver dans des blocs de réflexion vides avec les paramètres d'affichage par défaut. Si vous affichiez auparavant ces notes aux utilisateurs, demandez un mode d'affichage de réflexion pris en charge et rendez les blocs par type. Sinon, l'agent pourrait travailler pendant que l'interface paraît figée
• Les anciennes versions de l'outil computer-use peuvent échouer Vérifiez la version actuelle de l'outil avant de migrer un agent navigateur/ordinateur
• Un plafond max_tokens plus bas peut interrompre le travail

La réflexion est incluse même lorsque le texte est masqué

Ce sont des changements de comportement de l'API, pas des astuces de rédaction de prompts.

Guide de migration Opus et Guide de migration Sonnet

Formalisez le contrat dans Claude Code, pas dans votre tête

L'API permet de mesurer chaque champ d'utilisation. Claude Code est l'endroit où beaucoup ressentiront le changement de modèle pour la première fois. Le même principe s'applique : donnez à l'agent une définition bornée de l'achèvement, puis exigez qu'il fournisse ses preuves

Dans Claude Code, **/model sélectionne le modèle et /effort choisit le niveau d'effort pris en charge. Vérifiez les paramètres actifs avant de comparer les sessions. La valeur par défaut de l'API Sonnet ne décrit pas fidèlement ce qu'utilisent actuellement votre application Claude ou votre session Claude Code

Voici un bloc de départ complet et réutilisable pour CLAUDE.md. Adaptez les commandes à votre projet

1# Contrat de travail
2
3Effectue uniquement la modification demandée. Préserve le travail non lié.
4Exécute les tests pertinents après modification. Signale toute vérification impossible à lancer.
5Arrête-toi lorsque le travail demandé est validé. N'ajoute pas de fonctionnalités supplémentaires ni de boucles de revue.
6Termine par : Modifié / Vérifié / Risque restant.
7Demande avant toute action destructive, publication ou modification hors de ce dépôt.

Ce bloc ne rendra pas magiquement chaque exécution bon marché. Il rend les réussites et les échecs visibles. À partir de là, vous pourrez comparer un workflow Sonnet d'abord avec un workflow Opus d'abord sur les mêmes tâches

Le message de tâche doit rester précis. Voici la différence entre « corrige le code de paiement » et un travail qu'un agent peut réellement mener à bien

1Modification : migrer l'endpoint de paiement vers le nouveau client
2Terminé : ancien client supprimé, tests de l'endpoint réussis, diff limité à ce chemin
3Arrêt : demander avant de supprimer des données ou de modifier quoi que ce soit hors du dépôt
4Rapport : fichiers modifiés, vérifications exactes exécutées, risque restant

Ce petit contrat donne au vérificateur un élément concret à inspecter. Il fournit aussi au modèle une raison de s'arrêter. Une consigne ouverte du type « révise jusqu'à la perfection » peut transformer une modification validée en une nouvelle boucle payante

Pour les projets longs, conservez la checklist dans un fichier qui survivra à la compression. Pour les sous-agents, demandez à l'agent principal d'inspecter leurs preuves avant d'accepter leurs rapports. Et si vous avez simplement demandé des idées, dites à Claude de ne pas commencer à coder. Ce sont des limites de workflow, pas des prompts pour « être plus intelligent »

La configuration que je déploierais en premier

• Choisissez 10 à 30 tâches réelles et définissez une vérification pour chacune
• Balayez Sonnet 5.5 aux niveaux medium et high, puis Opus 5.5 au niveau medium
• Journalisez les entrées fraîches, sorties, écritures de cache, lectures de cache, latence, tentatives et réussites/échecs par tâche
• Rendez le préfixe stable apte à la mise en cache et confirmez les succès dans l'utilisation
• Ne faites remonter que les échecs, accompagnés de leurs preuves
• Réévaluez le parcours lorsque la charge de travail évolue. Un benchmark sauvegardé n'est pas une vérité immuable

Si les 10 % difficiles passent systématiquement d'un échec Sonnet à une réussite Opus, envisagez de router directement cette catégorie de tâches identifiable vers Opus. Si Sonnet high réussit ces mêmes cas pour moins cher, gardez-les à ce niveau. Un routeur est une politique mesurée, pas une opinion définitive sur le modèle le plus intelligent

La mise à jour 5.5 ne se résume pas à « utiliser Sonnet pour le travail bon marché et Opus pour le travail complexe »

C'est l'occasion d'arrêter de tarifer le modèle pour commencer à tarifer le travail accompli

Si tu as lu jusqu'ici

-> Abonne-toi à mon Substack

-> Rejoins mon Telegram

-> Ajoute cet article à tes favoris

-> Suis @0xwhrrari