Optimiser le coût et l'intelligence

Lorsqu'une charge de travail passe du prototype à la production, le coût devient une contrainte de conception de premier ordre. Le modèle le plus performant peut être trop cher à grande échelle, et le modèle le moins cher peut ne pas atteindre la qualité requise. Bien gérer le coût signifie comprendre comment chaque levier de coût affecte la qualité des résultats, car certains leviers se paient en qualité et d'autres non. La Claude Platform vous donne un contrôle direct sur ce compromis. Vous choisissez le modèle, le niveau d'effort et l'architecture pour chaque requête, ce qui vous permet de placer une charge de travail presque n'importe où sur la « cost-to-intelligence frontier » (frontière coût-intelligence).

Les leviers sont de deux sortes :

• Les gains gratuits réduisent les dépenses sans toucher à la qualité : le « prompt caching » (mise en cache des prompts), l'hygiène des tokens, un audit des prompts par rapport au modèle que vous exécutez, le traitement par lots à 50 % de réduction pour le travail qui peut attendre jusqu'à 24 heures, et les limites de dépenses de l'espace de travail comme filet de sécurité.
• Les compromis échangent du coût contre de l'intelligence : le choix du modèle, l'effort, les plafonds de sortie et les budgets de tâche, et les architectures multi-modèles.

Chaque levier est accompagné de résultats mesurés et de la règle indiquant quand il est rentable. Dans les mesures d'Anthropic, la mise en cache des prompts était de loin le levier le plus important : elle a divisé le coût des boucles d'agent par un facteur de 2,5 à 3,7 sur les benchmarks de ce guide et a réduit la facture d'un petit agent de triage de 83 %, ou de 88 % avec l'ajout de la réduction des entrées. Les leviers multi-modèles sont plus étroits ; un second modèle s'est avéré rentable sous deux formes, un conseiller et un orchestrateur.



Commencez ici

Faites correspondre votre situation à une ligne.

Ces résultats sont internes à Anthropic (Benchmarks référencés) et indicatifs, non des garanties ; mesurez donc sur votre propre charge de travail avec la méthode en quatre étapes.



Réduire les dépenses sans perdre en qualité

La mise en cache des prompts, l'hygiène des tokens, le traitement par lots et un audit des prompts par rapport à votre modèle actuel réduisent tous ce que vous payez sans réduire la qualité des résultats. Deux réserves s'appliquent : le traitement par lots échange de la latence contre sa réduction, et l'édition de contexte, un levier d'hygiène des tokens, a coûté plus qu'elle n'a économisé dans l'exécution mesurée dans cette section.



Mettre en cache le contexte répété

Activez la mise en cache des prompts avant tout autre levier, car chaque tour d'une tâche agentique renvoie l'intégralité de la conversation qui s'allonge : l'invite système, les définitions d'outils et chaque tour précédent. Une tâche de 40 tours envoie son premier tour 40 fois, de sorte que le coût de la tâche croît à peu près avec le carré du nombre de tours. La mise en cache n'empêche pas le renvoi, mais chaque renvoi coûte environ un dixième du prix et est traité plus rapidement : le préfixe est facturé au tarif de lecture du cache, un dixième du prix d'entrée, et chaque tour ne paie le tarif d'écriture en cache de 1,25x que pour ce qui est nouveau.

Dans l'ensemble des exécutions mesurées par Anthropic, les lectures de cache sont régulièrement la composante la plus importante du coût d'une tâche, ce qui rend la mise en cache plus précieuse que la plupart des décisions de choix de modèle. Anthropic a chiffré des exécutions de WideSearch¹ et de DeepResearch Bench II⁷ avec et sans mise en cache :

La durée de vie par défaut du cache est de 5 minutes et les tours d'une boucle d'agent sont espacés de quelques secondes, de sorte que la réduction s'applique à la plupart des tokens à chaque tour ; les exécutions représentées ont atteint des taux de succès de 81 % à 90 %. L'économie varie avec la profondeur de l'épisode, car les boucles plus courtes relisent moins, mais la mise en cache est restée le levier le plus important sur chaque modèle et chaque benchmark mesuré.

Si votre boucle attend des humains entre les tours, utilisez la durée de cache d'une heure. Elle coûte plus cher à écrire (2x le prix d'entrée au lieu de 1,25x) mais se rentabilise dès le premier échec de cache évité, car un échec renvoie tout le préfixe au plein tarif et l'écrit à nouveau.

La mise en place demande peu de travail. La mise en cache automatique place les points de rupture pour vous ; sinon, la skill Claude API livrée avec Claude Code peut ajouter la mise en cache à une intégration existante à partir d'un seul prompt. L'extrait suivant montre la skill l'ajoutant au harnais qui a produit ces mesures :

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

Ces placements de points de rupture suivent le modèle standard décrit dans Points de rupture de cache explicites.

Trois paramètres peuvent casser votre cache pendant une tâche. Modifier effort entre les requêtes invalide le préfixe mis en cache ; ne le modifiez donc que là où vous remettriez en cache de toute façon, par exemple à une frontière de compaction. Modifier un budget de tâche en cours de route fait de même ; définissez-le donc une seule fois, sur la première requête. Chaque passe d'édition de contexte invalide le préfixe à partir du point qu'elle efface et la requête suivante paie pour remettre en cache tout ce qui suit ; effacez donc en quelques grands lots plutôt qu'en de nombreux petits. Effectuez ces trois modifications à des pauses naturelles, puis confirmez que les lectures de cache n'ont pas chuté ; si c'est le cas, les diagnostics de cache montrent où le préfixe a divergé.



Réduire les tokens d'entrée et de contexte

La plupart des requêtes d'agent transportent des tokens qui n'influencent jamais la réponse. Les supprimer ne coûte rien en qualité de sortie, même si tous les leviers présentés ici n'ont pas permis d'économiser de l'argent lors des mesures. Deux endroits où chercher :

• Réduction des entrées. Le filtrage dynamique de l'outil web fetch écarte le contenu passe-partout des pages récupérées, le redimensionnement d'images ajuste la taille des entrées de vision, et la recherche d'outils avec chargement différé ne charge les définitions d'outils que lorsque c'est nécessaire. L'appel d'outils programmatique permet à Claude d'exécuter plusieurs appels d'outils depuis du code afin que seul le résultat filtré entre dans le contexte ; sa documentation rapporte 24 % de tokens d'entrée en moins sur les benchmarks de recherche agentique, avec un score plus élevé. Gérer le contexte des outils compare la recherche d'outils, l'appel d'outils programmatique, la mise en cache des prompts et l'édition de contexte.
• Cycle de vie du contexte. L'édition de contexte efface les résultats d'outils obsolètes, et la compaction automatique avec son seuil empêche les longues boucles de transporter tout leur historique.

Les leviers interagissent avec le cache et entre eux ; jugez-les donc par leur effet net, et utilisez les diagnostics de cache pour confirmer que votre préfixe mis en cache survit à chaque modification. Anthropic a activé les leviers un par un pour un agent de triage de tickets traitant 20 rapports de bogues réels avec captures d'écran provenant d'un dépôt public (et, pour le second panneau, une variante plus longue du même travail) :

La mise en cache a fait presque tout le travail, et la réduction a porté le total à 88 %. Chaque barre correspond à une exécution, de sorte que des différences de 0,10 $ relèvent du bruit ; celles montrées ici n'en relèvent pas. La compaction nécessite une session suffisamment longue pour la déclencher : l'exécution de 20 tickets n'a jamais atteint le plancher de 50 000 tokens une fois ses entrées réduites, mais sur la variante plus longue du second panneau, elle s'est déclenchée une fois et a réduit la facture de 38 % supplémentaires.

L'édition de contexte est le seul levier ici qui n'est pas gratuit. Chaque passe d'effacement réécrit la conversation mise en cache, ce qui va à l'encontre de la mise en cache des prompts ; dans cette exécution, l'édition de contexte a coûté plus qu'elle n'a économisé. Utilisez-la pour faire de la place dans la fenêtre de contexte, et effacez en quelques grands lots.



Traiter par lots le travail qui peut attendre

L'API Batch retire 50 % sur chaque token d'une requête, y compris ceux mis en cache, en échange de résultats arrivant à tout moment dans les 24 heures. Faites passer par un lot chaque requête que personne n'attend, et gardez le chemin interactif pour le reste. Le traitement par lots est le deuxième levier gratuit le plus important après la mise en cache pour le travail d'agent sans surveillance : exécutions d'évaluation, rattrapages de données et tâches planifiées telles qu'une exécution récurrente de l'agent de triage de tickets de la mesure de réduction des tokens. Il se combine avec tout ce qui figure sur cette page sauf l'interactivité, mais n'est pas disponible pour les sessions Claude Managed Agents, qui sont interactives par conception (voir Tarification de Claude Managed Agents).



Auditer les prompts par rapport au modèle actuel

Chaque génération de modèle répond différemment aux prompts, de sorte qu'un prompt accumule du texte écrit pour un modèle que vous n'utilisez plus. Le cas habituel est une instruction trop spécifique ajoutée pour compenser un modèle plus ancien : « vérifie deux fois », « sois aussi exhaustif que possible », une procédure étape par étape obligatoire, ou un bloc-notes de raisonnement fait maison. Un modèle plus récent les suit à la lettre, produisant des tours d'outils supplémentaires et de l'écriture supplémentaire, de sorte que la facture augmente sans gain de précision. Auditer les prompts par rapport au modèle que vous exécutez maintenant, et à nouveau chaque fois que vous changez de modèle, est un gain gratuit.

L'audit tient en une commande. La skill Claude API livrée avec Claude Code dispose d'une commande prompt-audit qui lit les prompts et le code de requête d'un projet et signale ce qui a été écrit pour un modèle différent. Cet extrait raccourci la montre exécutée sur un prompt de service d'assistance et un code de requête contenant ces motifs :

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

La commande propose ensuite ses modifications sous forme de diff (un seul bloc affiché) et liste ce qu'elle a délibérément laissé intact : la fenêtre de remboursement, l'exigence de ton et le niveau de qualité. Vous examinez un correctif, pas une réécriture.

L'effet est mesurable. Sur une évaluation de service d'assistance¹⁴, les prompts écrits pour Claude Opus 4.8 coûtaient 36 % de plus par ticket sur Claude Opus 5 sans changement de précision. Exécuter l'audit sur les mêmes prompts a rendu Opus 5 à la fois moins cher que la version non auditée (de 14 %) et plus précis (97 % des tickets, contre 92 %, un gain hors du bruit). Sur la migration de Claude Sonnet 4.6 vers Claude Sonnet 5, l'audit a retiré 14 % à précision égale :

Les deux types de texte obsolète ont des coûts différents. Les instructions que le nouveau modèle suit trop littéralement coûtent de l'argent : supprimer « vérifie deux fois » a réduit d'un tiers le coût par ticket d'Opus 5, et supprimer « sois aussi exhaustif que possible » presque autant. Le texte qui ne convient plus au modèle coûte en revanche de la précision : un paramètre de réflexion retiré, des règles contradictoires et un bloc-notes fait maison en conflit avec la propre réflexion du modèle ont chacun restauré 7 à 11 points sur Opus 5 une fois supprimés :

Les mêmes motifs apparaissent dans les descriptions d'outils et les skills, et méritent d'y être supprimés également.



Échanger du coût contre de l'intelligence

Ces leviers déterminent où un modèle unique se situe entre coût et intelligence : le choix du modèle, l'effort, la relance des échecs à un réglage plus élevé, et les budgets et plafonds dans lesquels il travaille. Commencez par un balayage de l'effort sur votre modèle actuel (Ajuster l'effort). Du coût et de la capacité les plus faibles aux plus élevés, les modèles actuels sont Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5 et Claude Fable 5 (le « frontier model », ou modèle de pointe) ; la Vue d'ensemble des modèles présente la gamme complète et les prix.



Comparer les modèles sur le coût par tâche

Les grilles tarifaires sont rédigées par token, et par token le modèle de pointe semble cher : le prix par token de Claude Fable 5 est plusieurs fois celui de Claude Sonnet 5. Vous payez cependant pour des tâches accomplies ; comparez donc les modèles sur le coût par tâche accomplie. Un modèle plus performant termine une tâche avec moins de travail : moins de tours, moins de recherches, moins de relecture de son propre contexte et moins de retours en arrière. Le supplément par token est régulièrement écrasé par le fait de faire moins de tout.

Anthropic a mesuré cela directement sur DeepResearch Bench II⁷, un benchmark de rapports de recherche suffisamment difficile pour départager les modèles :

Le modèle de pointe à l'effort low était plus précis et environ 10 % moins cher par tâche que le modèle intermédiaire, malgré l'écart par token. Il ne gagne cependant pas toujours. Sur le sous-ensemble SWE-bench Pro³ de cette page, que les deux modèles saturent largement et dont les scores ne sont pas comparables au classement public, Claude Opus 5 seul a égalé Claude Fable 5 seul (91,7 % contre 91,3 %, dans le bruit d'une exécution à l'autre) pour environ 60 % de son coût. Sur un travail plus difficile, comme les tâches de DeepResearch Bench II, l'avantage de Fable réapparaît.

Pour la plupart des charges de travail d'agent, commencez par Claude Opus 5 : par token, il coûte la moitié de Fable 5 et 2,5 fois Sonnet 5, et sur ce sous-ensemble de codage il a égalé la précision de Fable. À l'autre extrémité, Claude Haiku 4.5 a répondu aux questions de GPQA Diamond⁹ pour environ un dixième du coût par question d'Opus 5, avec une précision de 63 % contre 92 % pour Opus, et a pris beaucoup plus de retard sur les longues tâches de codage. Il convient au travail à fort volume avec des sorties vérifiables, pas aux longues boucles agentiques.

Le classement s'inverse selon la charge de travail, et aucune grille tarifaire ne vous dit dans quel sens. Chiffrez chaque candidat en coût par tâche accomplie sur votre propre trafic, y compris Claude Opus 5 et le modèle de pointe à effort réduit.

Chiffrez la queue de votre charge de travail, pas la médiane : comparez les modèles sur le dixième le plus difficile de vos tâches, pas sur la tâche typique. Sur la tâche typique, tous les modèles se ressemblent et le moins cher semble le meilleur, mais la facture est décidée par les tâches que le modèle moins cher échoue, car une tâche échouée facture quand même ses tokens, puis la nouvelle tentative, puis tout ce que l'échec coûte en aval. La queue est aussi là où va l'argent même quand rien n'échoue. Sur une exécution WideSearch¹ de 20 problèmes, deux problèmes représentaient 43 % des dépenses :

Les stratégies multi-modèles existent pour dépenser l'intelligence de pointe sur cette queue sans payer les tarifs de pointe pour le reste.



Ajuster l'effort

L'effort est le moyen le plus direct d'ajuster un modèle à votre tâche. Le paramètre effort régit la quantité de réflexion, d'appels d'outils et d'auto-vérification que le modèle effectue, et la valeur par défaut (high) convient aux tâches exigeantes. Le coût évolue avec toute cette activité ; la précision n'évolue qu'avec la partie dont votre tâche a besoin. En dessous du plafond du modèle, les niveaux d'effort les plus élevés paient pour une profondeur que la tâche n'utilise jamais.

Sur les benchmarks de recherche et de travail intellectuel (WideSearch¹, DeepWideSearch⁶, BrowseComp⁴ et GDPval², tous avec Claude Fable 5), la courbe de la précision en fonction du coût est presque plate : low a cédé 1 à 3 points pour un tiers à la moitié de réduction du coût par tâche, medium a égalé la précision de la valeur par défaut pour 70 % à 85 % de son coût, et la valeur par défaut n'a rien apporté de mesurable par rapport à medium sur aucun des quatre. Sur DeepWideSearch, low a également égalé un orchestrateur avec un exécutant Claude Sonnet 5 pour un coût inférieur de 20 % : baisser l'effort a battu un changement d'architecture.

Les réglages inférieurs sont aussi plus rapides, ce qui compte lorsque la latence est la contrainte. Dans ces exécutions, low a pris 4,5 minutes par problème sur DeepWideSearch, contre 7,9 minutes à la valeur par défaut. Sur le benchmark de corpus, dont l'entrée ne tient dans aucune fenêtre de contexte unique, Fable 5 a pris 7,9, 9,1 et 11,4 heures par épisode à low, medium et à la valeur par défaut.

Le codage à long horizon est l'autre forme. Sur SWE-bench Pro³, Claude Opus 5 a cédé environ 2 points à medium pour la moitié du coût et environ 8 points à low pour un quart de celui-ci : un véritable compromis, que la relance des échecs à un effort plus élevé retransforme en économie. Ce graphique représente la précision en fonction du coût pour les benchmarks de recherche et de travail intellectuel et pour SWE-bench Pro :

Deux conséquences en découlent. Premièrement, tracez cette courbe pour votre propre charge de travail avant d'ajouter un second modèle : dans ces mesures internes, une configuration multi-modèles qui semblait moins chère que le modèle unique par défaut coûtait plus que ce même modèle à un effort inférieur. Deuxièmement, cette courbe est la référence à modèle unique que toute stratégie multi-modèles doit battre ; c'est pourquoi l'étape 2 de la mesure sur votre propre charge de travail établit la référence sur plusieurs niveaux d'effort.

Un effort inférieur coûte bien de la précision sur les charges de travail qui atteignent le plafond du modèle, là où la précision évolue réellement avec la profondeur du raisonnement. Sur DeepResearch Bench II⁷, où chaque rapport récompense un raisonnement approfondi par sous-thème, chaque palier d'effort a apporté environ 2,4 points de score de grille d'évaluation ; il n'y a pas de réduction de coût gratuite sur cette courbe :

La description de la tâche seule ne révèle pas quel type de charge de travail vous avez ; balayez donc deux ou trois niveaux d'effort sur un échantillon de votre propre trafic et lisez la réponse sur la courbe. Testez chaque niveau dans une session séparée : changer l'effort en cours de session invalide le cache (voir Mettre en cache le contexte répété) et fausse la comparaison. Pour les détails du paramètre, consultez Effort.



Relancer les échecs à un effort plus élevé

Lorsque le résultat d'une tâche est vérifiable, la politique la moins chère sur la courbe d'effort n'est pas un réglage fixe : exécutez chaque tâche à un réglage bas et ne relancez que les échecs à un réglage plus élevé.

Anthropic a calculé cette politique tâche par tâche à partir des exécutions d'effort sur le sous-ensemble SWE-bench Pro³ de Ajuster l'effort. Avec Claude Opus 5 à low, 16 % des tâches ont échoué ; avec celles-ci relancées à la valeur par défaut, environ 93 % ont réussi pour environ 0,70 $ chacune, contre 91,7 % pour 1,39 $ en exécutant tout à la valeur par défaut : le même taux de réussite pour la moitié du coût, en comptant les tentatives bon marché échouées. Commencer à medium à la place a résolu environ 94 % pour environ 0,95 $. L'essentiel du léger gain provient de la seconde tentative (relancer les propres échecs de la valeur par défaut à la valeur par défaut obtient à peu près le même score, pour plus d'argent) ; utilisez donc cette politique pour l'économie, pas pour le gain :

Deux conditions s'appliquent. Premièrement, vous avez besoin d'un signal d'échec (ici, les propres tests du benchmark) ; un vérificateur qui laisse passer du mauvais travail laisse passer ces échecs. Deuxièmement, chaque échec de première passe prend le temps réel de deux exécutions, de sorte que l'économie se paie en latence sur les échecs.



Définir des budgets et des plafonds de sortie

La plupart des exécutions de tâches agentiques sont bon marché, mais une minorité dépense plusieurs fois le coût médian en recherches, revérifications et tests excessifs. Un « task budget » (budget de tâche) cible cette queue. Le modèle voit un décompte de tokens en direct pour l'ensemble de la tâche et s'autorégule, en supprimant les recherches à faible valeur, en sautant les vérifications redondantes et en concluant au lieu de s'emballer.

Anthropic a mesuré le taux de réussite et le coût par tâche sur SWE-bench Pro³ avec Claude Fable 5 à mesure que le budget se resserrait :

Un budget généreux a cédé environ 2,7 points de taux de réussite pour une économie de coût de 18 %, et le budget le plus serré autorisé a cédé 4,4 points pour une économie de 47 %. Les budgets ont acheté ici de l'efficacité, pas de la précision.

Trois contrôles remplissent trois fonctions différentes. Un budget de tâche économise de l'argent, parce que le modèle le voit. max_tokens est un plafond de sécurité qui n'économise rien. Sur Claude Managed Agents, un budget de session est l'arrêt ferme en dollars derrière les deux. Définissez les trois : un budget de tâche, un max_tokens élevé et un plafond de session pour l'exécution que vous ne voulez jamais voir sur une facture, avec une limite de dépenses de l'espace de travail comme filet de sécurité final.

• Les budgets de tâche sont en bêta (en-tête bêta task-budgets-2026-03-13) sur Claude Opus 5, Claude Fable 5, Claude Opus 4.8 et Claude Opus 4.7, mais pas sur Claude Sonnet 5 ; vérifiez d'abord le tableau de prise en charge. Commencez près de l'utilisation de tokens au 90e percentile de votre boucle, puis resserrez (Choisir un budget montre comment collecter cette distribution). Les budgets inférieurs au plancher actuel de 20 000 tokens sont rejetés, et des budgets très serrés peuvent produire un comportement proche du refus. Définissez le budget une seule fois, sur la première requête, car une modification en cours de tâche invalide le cache. Le budget est indicatif, orientant le modèle plutôt que l'arrêtant ; vérifiez donc son respect sur votre charge de travail.
• max_tokens plafonne une seule réponse, de manière invisible pour le modèle, de sorte que le baisser ne pousse pas le modèle à économiser. Les tours qui avaient besoin de cette marge sont écartés et quand même facturés. Sur un benchmark interne de tâches de dépôt¹², un plafond de 16 384 tokens a mis fin à 15 % des tentatives de Claude Opus 5 et à un tiers de celles de Claude Fable 5, aucune d'entre elles résolue. Les exécutions plafonnées ont dépensé moins par tentative mais ont acheté proportionnellement moins de résolutions, de sorte que le coût par tâche résolue était le même qu'à 64 000. À ce réglage, rien n'a été coupé, et Fable a résolu 54,6 % des tâches au lieu de 36,6 % sur les problèmes notés par les deux exécutions (sur une coupe distincte du sous-ensemble SWE-bench Pro³, décrite dans la référence 12, 92 % au lieu de 90 %). Relancer les tentatives plafonnées ne fait qu'ajouter du coût : au même plafond elles n'ont jamais réussi, et à un plafond plus élevé vous payez aussi la tentative gaspillée. Définissez max_tokens à 64 000 pour le travail agentique (128 000, le maximum, à l'effort xhigh ou max), diffusez en streaming les réponses de cette taille, traitez stop_reason: max_tokens comme un échec, et économisez de l'argent avec l'effort et les budgets de tâche, que le modèle peut voir.
• Les budgets de session sur Claude Managed Agents sont l'arrêt ferme. Un budget de session est un plafond en dollars sur une session aux tarifs publics pour les tokens, les recherches et le temps de session. Au plafond, la session se met en pause avec stop_reason: budget_reached ; augmenter le budget la reprend. Il est appliqué par la plateforme, fonctionne sur tout modèle ayant un prix public (y compris Claude Sonnet 5) et se combine avec le budget de tâche indicatif. Les déploiements appliquent le même champ à chaque exécution.

Le premier des deux graphiques max_tokens représente le coût par tentative et par tâche résolue à chaque plafond :

Le second représente la longueur de sortie par tour par rapport aux plafonds :



Combiner les modèles

Les architectures multi-modèles conviennent aux charges de travail dont la complexité des tâches varie suffisamment pour que différentes étapes soient mieux servies par différents modèles. Lorsque votre trafic mélange du travail de routine qu'un modèle plus petit gère de manière fiable avec des étapes plus difficiles qui nécessitent une capacité de pointe, répartir le travail maintient l'intelligence de pointe là où elle compte tandis que la plupart des tokens sont facturés aux tarifs du modèle plus petit. Lorsqu'une charge de travail ne présente pas ce mélange, parce que sa difficulté est uniforme ou qu'il s'agit d'une seule chaîne dépendante, un modèle unique bien réglé est généralement le meilleur choix. Chaque section de stratégie donne la règle pour distinguer les deux cas.

Deux stratégies couvrent la plupart des charges de travail, et elles diffèrent par le modèle qui tient la boucle principale :



Stratégie du conseiller : faire remonter les décisions difficiles

Dans la stratégie du conseiller (advisor strategy), un modèle exécuteur moins coûteux fait tourner la boucle de l'agent et effectue la plupart des tours. Lorsqu'il rencontre une décision qui nécessite un jugement plus approfondi, comme le choix d'une approche ou la reprise après un échec, il appelle un modèle conseiller plus intelligent pour obtenir des orientations stratégiques, puis continue. La plupart des tokens sont facturés aux tarifs de l'exécuteur, et seules les consultations occasionnelles le sont aux tarifs du conseiller.

Pour l'utiliser, ajoutez l'outil conseiller à votre requête. Cette fonctionnalité bêta exécute toute la stratégie côté serveur en une seule requête /v1/messages : l'exécuteur émet un appel d'outil, Anthropic exécute l'inférence du conseiller, et l'exécuteur continue avec le conseil ; vous n'écrivez aucun code d'orchestration. Sur Claude Managed Agents, donnez un conseiller à la session en ajoutant une entrée advisor à la liste multiagent de l'agent ; le fil principal de la session le consulte de la même manière. Claude Code le prend également en charge ; consultez faire remonter les décisions difficiles avec l'outil conseiller.

Ce qui détermine le gain. Le conseiller ne voit la tâche qu'à travers les appels de l'exécuteur, donc deux éléments décident de l'ampleur de son aide.

Le premier est l'écart entre les modèles. Le conseiller ne peut transmettre que les capacités qui manquent à l'exécuteur : sur GPQA Diamond⁹, un exécuteur Claude Haiku 4.5 a beaucoup gagné avec un conseiller Claude Opus 5, un exécuteur Claude Sonnet 5 a gagné quelques points, et un exécuteur de pointe presque rien.

Le second, et le plus fragile, est de savoir si l'exécuteur demande réellement (le taux de consultation, ou consult rate). Un exécuteur à faible effort peut cesser de remarquer qu'il est bloqué : une paire qui consulte sur la plupart des tâches à l'effort par défaut peut tomber à presque aucune consultation lorsque l'effort est réduit, et obtient alors un score inférieur à celui de l'exécuteur seul. Le taux varie également selon la tâche : sur DeepSWE¹⁰, un exécuteur Sonnet 5 à faible effort a continué à demander et a gagné 23 points ; sur SWE-bench Pro³, le même exécuteur a cessé. Lorsque l'exécuteur demande effectivement, il parcourt la majeure partie du chemin. Sur l'ensemble des paires du graphique suivant, le conseiller a comblé 60 % à 90 % de l'écart avec le modèle le plus puissant, alors que ce modèle n'était payé que pour les consultations, ce qui rend les cas d'économie possibles :

Le taux de consultation réagit au prompting. Avec seulement la description intégrée de l'outil, les exécuteurs appellent trop peu, en particulier sur le travail de codage, c'est pourquoi la documentation de l'outil conseiller fournit une invite système qui demande un appel avant tout travail substantiel et un autre avant de terminer, soit environ deux à trois appels par tâche. La paire de codage mesurée ci-après a fonctionné à cette cadence, environ deux consultations sur chaque tâche. Cette page traite également de la manière d'inciter un exécuteur qui appelle trop peu et de plafonner les appels côté client pour borner le coût. Surveillez donc le taux de consultation : demandez-le dans le prompt, mesurez-le, et rétablissez l'effort de l'exécuteur s'il s'effondre.

Quand cela paie sur le coût. Un conseiller fait économiser de l'argent lorsque quelques courtes consultations, facturées au tarif du conseiller, remplacent l'exécution du modèle du conseiller pour toute la tâche. Cela fonctionne le mieux lorsque le modèle du conseiller est tarifé bien au-dessus de celui de l'exécuteur, de sorte que la configuration la plus rentable est un conseiller de pointe au-dessus d'un exécuteur de milieu de gamme. Une paire peut tenir son rang même en haut de la gamme, car les conseils font aussi économiser des tokens d'exécuteur : un exécuteur à qui l'on indique la bonne approche explore moins d'impasses, ce qui peut couvrir les consultations.

Sur un benchmark interne de codage agentique¹¹, exécuté avec un agent API simple, un exécuteur Claude Opus 5 avec un conseiller Claude Fable 5 était la configuration la plus précise mesurée : 85,7 % des tentatives résolues pour 8,40 $ par tentative. Elle se situe au-dessus de la ligne passant par les propres réglages d'effort de chaque modèle, mais seulement un point ou deux au-dessus du meilleur d'entre eux (Opus seul au réglage par défaut, 84,4 % pour 8,50 $, et Fable seul à medium, 83,4 % pour 8,20 $), ce qu'une seule exécution ne distingue pas du bruit. Fable seul à l'effort medium atteint à peu près la même précision que la paire (83,4 % contre 85,7 %) pour à peu près le même prix (8,20 $ contre 8,40 $ par tentative) :

Une mesure antérieure via le mode conseiller de Claude Code a produit le même classement. Lisez ce résultat comme une forme à tester sur votre charge de travail, et non comme une économie : en haut de la gamme, le conseiller achète un peu de précision au prix de pointe, et le cas d'économie appartient aux paires présentant un écart de capacité plus large, comme le cas de lecture de graphiques suivant. Le coût en latence correspond aux consultations elles-mêmes : environ deux appels supplémentaires au modèle de pointe par tâche sur ce benchmark, chacun sur le chemin critique de la tâche.

Quand cela paie plutôt que d'augmenter l'effort. Lorsque l'écart de capacité est plus large et que la précision d'une charge de travail réagit à l'effort, un exécuteur à faible effort qui consulte un conseiller peut constituer une montée en gamme moins coûteuse que l'augmentation de l'effort propre de l'exécuteur, car le conseiller n'est payé que sur les tâches qui en ont besoin.

Sur Chartography¹³, un benchmark public de lecture de graphiques exécuté sur Claude Managed Agents avec son conseiller, un exécuteur Claude Opus 5 à l'effort low avec un conseiller Claude Fable 5 a obtenu 67,5 pour 0,60 $ par tâche. C'est au-dessus de la ligne passant par les propres réglages d'effort de l'un ou l'autre modèle (Opus seul est passé de 49 à 75 entre low et medium pour 0,38 $ à 0,94 $), bien que les réglages medium et par défaut de l'exécuteur détiennent toujours les meilleurs scores, à 1,6 et 3,3 fois le prix :

L'exécuteur à faible effort a consulté le conseiller sur 86 % des tâches, la condition que la paire SWE-bench Pro n'a pas remplie. Mesurez le taux de consultation dans votre boucle d'agent avant de vous appuyer sur cette configuration.

Quelle que soit la paire, chiffrez d'abord le modèle du conseiller seul à faible effort ; c'est la référence à battre. Revérifiez à chaque sortie de modèle, car les sorties déplacent à la fois l'écart de capacité et le rapport de prix.

Quand cela convient. La stratégie du conseiller convient aux charges de travail où les tours sont principalement mécaniques mais où un excellent plan compte : agents de codage, utilisation de l'ordinateur et pipelines de recherche en plusieurs étapes. Elle convient mal lorsque chaque tour nécessite réellement une capacité de pointe, lorsqu'il n'y a rien à planifier (questions-réponses en un seul tour), ou lorsque votre exécuteur est déjà proche de la capacité du conseiller.



Stratégie de l'orchestrateur : déléguer le travail de masse

Dans la stratégie de l'orchestrateur (orchestrator strategy), le modèle de pointe tient la boucle. Il décompose la tâche, répartit les sous-tâches vers des modèles travailleurs moins coûteux et fusionne leurs résultats. La propre transcription de l'orchestrateur reste courte car les travailleurs absorbent l'exploration gourmande en tokens, de sorte que la plupart des tokens sont facturés aux tarifs des travailleurs tandis que le plan et la synthèse proviennent toujours du modèle de pointe.

Pour en construire un, utilisez l'orchestration multi-agents dans Claude Managed Agents : configurez un agent coordinateur (l'orchestrateur) et une liste d'agents travailleurs, chacun avec son propre modèle. Pour un exemple fonctionnel complet avec un coordinateur Claude Fable 5 et des travailleurs Claude Sonnet 5, consultez la recette du Claude Cookbook Coordinator pattern: big models for planning, small models for execution.

Ce modèle fait gagner du temps réel lorsque les travailleurs peuvent s'exécuter en parallèle : sur le benchmark de corpus⁸, un épisode a pris un peu plus de 2 heures avec le coordinateur exécutant la limite documentée de la plateforme de 25 travailleurs simultanés, contre 11,4 heures en solo. Il n'a fait économiser de l'argent que dans deux situations mesurées. Sur un travail qu'un seul modèle pouvait gérer seul, le même modèle à effort réduit était moins cher à chaque fois.

Cas 1 : assurance contre la queue de coût sur le travail de routine. Un modèle de pointe fonctionnant seul s'enlise occasionnellement sur un problème de routine qu'il résoudrait normalement. Comme vous ne pouvez pas savoir à l'avance lesquels ce seront, quelques exécutions de ce type dominent la facture. Un coordinateur qui confie le travail de routine à un travailleur moins coûteux plafonne cette queue, car tout enlisement se produit désormais aux tarifs du travailleur.

Anthropic a mesuré cela sur une tranche délibérément facile de BrowseComp⁴ (10 problèmes que le modèle solo résout de manière fiable ; 50 exécutions déléguées et 70 exécutions solo). Un coordinateur Claude Fable 5 avec un travailleur Claude Sonnet 5 a coûté un peu moins de la moitié de Fable seul en moyenne et environ un tiers au 90e percentile (12 $ contre 33 $), et l'exécution la plus coûteuse du modèle solo, à 84 $, était également fausse :

La délégation a payé sur la part de routine, normalement résoluble, du travail, à l'opposé de l'intuition selon laquelle les travailleurs sont destinés aux problèmes difficiles. Sur l'ensemble BrowseComp complet, plus difficile, l'économie s'est inversée. Si votre trafic présente une longue queue de coût sur les tâches de routine, c'est le cas d'orchestrateur à mesurer en premier.

Cas 2 : travail plus grand qu'une fenêtre de contexte. Un modèle solo doit traiter une entrée aussi volumineuse en série, une fenêtre de contexte à la fois, en payant pour relire son propre état à chaque passage. Les travailleurs lisent chacun leur propre partition, en parallèle et aux tarifs des travailleurs. Un travail à forte lecture qui tient encore dans une seule fenêtre de contexte est un problème de choix de modèle, pas un problème de délégation : sur le seul coût de lecture, l'orchestrateur ne l'emporte que lorsqu'aucun contexte unique ne peut contenir le travail.

Anthropic a construit un benchmark pour ce cas⁸ : un corpus de 21,6 millions de tokens composé de 14 paquets Python publics avec 130 défauts implantés, trop volumineux pour n'importe quelle fenêtre de contexte. Réduire l'effort ne peut pas aider, car la facture est la lecture du corpus elle-même : Claude Fable 5 en solo a coûté 720 $ à 764 $ par épisode à chaque réglage d'effort, et seule sa précision a varié. La configuration avec coordinateur a coûté plus de 60 % de moins que n'importe lequel de ces réglages et a obtenu 2 à 6 points de moins que Fable à medium ou par défaut, tout en battant nettement une référence Claude Sonnet 5 en solo :

La comptabilité des tokens montre pourquoi. Les deux factures sont principalement constituées de lecture du corpus servie depuis le cache : la configuration avec coordinateur a lu environ 570 millions de tokens en cache par épisode, près de trois fois les quelque 200 millions du modèle solo, et a tout de même coûté moins de la moitié, car ses lectures étaient facturées au tarif de lecture de cache de Claude Sonnet 5 plutôt qu'à celui de Claude Fable 5. Fable 5 à l'effort par défaut détient toujours la précision maximale, à 2,8 fois le coût de la configuration avec coordinateur, de sorte que la délégation achète ici la majeure partie de la précision, pas la totalité.

Quand la délégation ne paie pas. Un orchestrateur n'achète quelque chose que lorsqu'il y a de la masse à confier : de nombreux éléments indépendants, idéalement trop nombreux pour une seule fenêtre de contexte. Lorsque le travail est une chaîne dépendante unique, ou tient dans un seul contexte, l'orchestrateur paie pour un plan, un transfert et une fusion qu'un modèle unique obtient gratuitement. Dans chaque cas de ce type mesuré, le modèle du coordinateur seul à effort réduit l'a emporté.

BrowseComp⁴ montre la frontière au sein d'un même benchmark. La délégation a payé sur la tranche de routine et a perdu sur l'ensemble complet, plus difficile, où le modèle de pointe seul a atteint la précision de la configuration avec coordinateur à un coût inférieur de 22 % à 30 %. Des travaux externes indépendants rapportent le même schéma⁵. Si le travail est une chaîne unique, tient dans un seul contexte sans longue queue de coût, ou si un modèle unique à effort réduit atteint déjà votre seuil, ne construisez pas d'orchestrateur.



Choisir entre les stratégies

La plupart des cas se résument à une question : le travail se divise-t-il en éléments indépendants, ou s'agit-il d'une seule réponse atteinte par une chaîne d'étapes dépendantes ? Le tableau des stratégies associe les deux réponses aux deux stratégies.

Si vous n'êtes pas sûr, ne construisez rien pour l'instant :

1. Balayez d'abord l'effort sur votre modèle actuel. C'est l'expérience la moins coûteuse de cette page, et la plupart des charges de travail s'arrêtent là.
2. Si le balayage révèle un écart, chiffrez le modèle plus puissant seul à faible effort. C'est le chiffre qu'une paire avec conseiller doit battre, et les paires de cette page qui l'ont battu étaient celles dont l'exécuteur consultait réellement.

Les résultats multi-modèles de cette page ont été jugés par rapport au même modèle à effort réduit et par rapport au modèle immédiatement inférieur fonctionnant seul. C'est la comparaison à effectuer sur votre propre charge de travail, et c'est pourquoi la première étape est un balayage de l'effort.

Lorsque vous ajoutez effectivement un conseiller, il s'agit d'une définition d'outil plutôt que d'une refonte d'architecture.



Mesurer sur votre propre charge de travail

Les chiffres de cette page datent de juillet et août 2026, aux prix catalogue de l'époque, et dériveront à mesure que les modèles et les prix changeront. Votre taux d'escalade, la netteté avec laquelle les tâches se divisent et la longueur des transcriptions les font également varier. La méthode reste la même :

1. Extrayez quelques tâches des journaux de production, pondérées comme le trafic réel, et écrivez des vérifications de résultat pour chacune : les tests passent, le ticket est fermé, le nombre de lignes est correct. Enregistrez le coût par tâche à côté du score : chiffrez les quatre compteurs de tokens du champ usage de chaque réponse à leurs propres tarifs, additionnés sur l'ensemble des requêtes de la tâche (l'API Usage and Cost rapporte l'agrégat).
2. Établissez une référence pour les niveaux de modèles sur l'ensemble des niveaux d'effort, pas seulement le niveau par défaut, et tracez le score en fonction de la dépense. Une configuration multi-modèles doit battre toute la courbe du modèle unique.
3. Si la courbe montre un écart que l'effort ne peut pas combler, ajoutez la stratégie multi-modèles qui convient et relancez la suite.
4. Exécutez le gagnant en mode fantôme sur une tranche de trafic avant la bascule, puis maintenez la suite en fonctionnement.

L'exemple suivant calcule le coût de l'étape 1 pour une requête aux prix catalogue de Claude Opus 5 :

# Prix par million de tokens issus de la page de tarification ; modifiez ces deux valeurs pour un autre modèle.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # Les écritures en cache sont facturées à 1,25x le prix d'entrée (cache de 5 minutes) ; les lectures en cache à 0,1x.
    + (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

Dans les boucles d'agent, le terme de lecture de cache est généralement le plus grand des quatre ; si ce n'est pas le cas, vérifiez que la mise en cache est activée. Lorsque l'outil conseiller ou la compaction est activé, certains tokens ne sont rapportés que dans usage.iterations et non dans les totaux de premier niveau ; additionnez donc plutôt sur usage.iterations, en chiffrant les entrées advisor_message aux tarifs du modèle conseiller.

Le tableau suivant répertorie les leviers dans l'ordre où les essayer :



Benchmarks référencés

Toutes les mesures sont des exécutions internes à Anthropic de ces benchmarks. Sauf mention contraire, les coûts sont en USD aux prix catalogue d'août 2026 ; les chiffres de Claude Sonnet 5 utilisent 2 $ et 10 $ par million de tokens d'entrée et de sortie. Les graphiques étiquetés « notional USD » (USD notionnels) chiffrent les compteurs de tokens de chaque requête à ces tarifs plutôt que de rapporter des factures.

1. WideSearch : Wong et al., « WideSearch: Benchmarking Agentic Broad Info-Seeking », arXiv:2508.07999, 2025. Tâches de recherche web étendue notées sur l'exhaustivité et l'exactitude d'un tableau à nombreuses lignes ; 200 problèmes, 3 exécutions par configuration. Les graphiques de mise en cache et d'effort proviennent d'exécutions distinctes, de sorte que les coûts par problème diffèrent légèrement. Le graphique de concentration des coûts est une exécution distincte de 20 problèmes, 3 exécutions par problème, chiffrée à partir des enregistrements de facturation par requête.
2. GDPval : OpenAI, « GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks », 2025. Livrables de travail intellectuel notés selon des grilles de tâches ; une exécution de 210 tâches de l'ensemble de référence publié, une tentative par tâche. Un modèle Claude note, de sorte que les scores absolus peuvent différer des résultats publiés.
3. SWE-bench Pro : Scale AI, « SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? », 2025. Un sous-ensemble de 482 problèmes sélectionné pour sa compatibilité avec le harnais d'évaluation d'Anthropic ; les scores ne sont pas comparables au classement public. Claude Opus 5 à l'effort par défaut est la moyenne de deux exécutions ; les réglages à effort réduit sont des exécutions uniques. Les chiffres d'escalade proviennent tâche par tâche de ces exécutions : low d'abord, puis le réglage par défaut sur ses échecs, a résolu 92,5 % à 93,6 % selon les paires d'exécutions pour environ 0,70 $ ; medium d'abord, 93,8 % à 94,2 % pour environ 0,95 $ ; le réglage par défaut relancé sur ses propres échecs, 94,0 % pour 1,58 $ ; tout au réglage par défaut, 90,9 % à 92,5 % pour 1,39 $. Les paires avec exécuteur Claude Sonnet 5 du graphique du conseiller proviennent de la même série d'août 2026 sur ce sous-ensemble : la paire Sonnet-plus-Opus a été exécutée deux fois (une exécution et une réplication exacte) et la paire à faible effort une fois ; les chiffres de budget de tâche correspondent à une exécution par budget sur le même sous-ensemble. Le chiffre de Claude Fable 5 dans Comparer les modèles est une exécution unique de juillet 2026, également la référence sans budget du graphique de budget de tâche ; chaque exécution avec budget a terminé les 482 problèmes sans erreur de harnais.
4. BrowseComp : Wei et al., « BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents », OpenAI, 2025. Les chiffres d'effort utilisent une coupe de 500 problèmes, une à trois exécutions par réglage. Le graphique d'assurance-coût utilise 10 problèmes résolus de manière fiable issus d'une tranche de 26 problèmes, 50 exécutions déléguées et 70 exécutions solo (6,45 $ contre 11,99 $ par exécution en espérance) ; les chiffres délégués comportent une bande de mesure d'environ 20 %.
5. Mise à l'échelle des architectures d'agents : Kim et al., « Towards a Science of Scaling Agent Systems », arXiv:2512.08296, 2025. Étude externe indépendante, citée uniquement pour le sens de la conclusion sur les cas où la délégation ne paie pas, et non pour un chiffre quelconque.
6. DeepWideSearch : « DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking », arXiv:2510.20168, 2025. Les 220 questions couvrent 15 domaines, chacune combinant une collecte à nombreuses lignes avec une récupération multi-sauts ; mesuré sur l'ensemble de lignes permanent du benchmark, 3 exécutions par configuration.
7. DeepResearch Bench II : Li et al., « DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report », arXiv:2601.08536, 2026. Ses 132 tâches de recherche réparties sur 22 domaines sont notées selon des grilles binaires dérivées d'experts ; mesuré sur un sous-ensemble de 50 tâches stratifié sur tous les thèmes, une tentative par tâche, 3 exécutions, noté sur les tâches qu'aucune configuration n'a refusées. Claude Opus 4.6 juge selon le protocole de grille du benchmark ; l'original utilise un juge différent, et un juge Anthropic peut favoriser le style maison. Les exécutions sont antérieures à Claude Opus 5, d'où son absence du graphique Comparer les modèles. Le coût de Sonnet 5 diffère légèrement entre le graphique de mise en cache (coût d'inférence, avec et sans mise en cache) et ce graphique (coût tout compris, mise en cache activée) ; les deux proviennent des mêmes exécutions.
8. Balayage de défauts de corpus : Interne à Anthropic, pour un travail plus grand qu'une fenêtre de contexte : un corpus de 21,6 millions de tokens issu de 14 sources de paquets Python publics avec 130 défauts implantés et une notation déterministe ; protocole fixé avant les exécutions et revu en interne ; trois exécutions par configuration. Chaque configuration a été exécutée sur Claude Managed Agents. La configuration d'équipe représentée est une exécution d'août 2026 dans laquelle le coordinateur Claude Fable 5 a exécuté tout le balayage au sein de la plateforme à sa limite documentée de 25 travailleurs Claude Sonnet 5 simultanés ; ses trois épisodes ont obtenu des F1 de 0,842, 0,805 et 0,810 pour 263 $, 299 $ et 261 $. Les configurations solo sont des exécutions de juillet 2026 sur la même version du corpus. Le F1 absolu est spécifique à cette version du corpus, non comparable entre benchmarks ; les comparaisons de configurations sont à périmètre identique.
9. GPQA Diamond : Rein et al., « GPQA: A Graduate-Level Google-Proof Q&A Benchmark », 2023. Le sous-ensemble Diamond de 198 questions, mesuré en août 2026, deux exécutions par configuration, noté par modèle par rapport aux réponses de référence, tokens du conseiller comptabilisés par requête. Un contrôle de sécurité de la plateforme a refusé deux questions de biologie sur les exécuteurs Sonnet et Opus ; les exclure ne modifie aucune comparaison de plus d'un point.
10. DeepSWE : Datacurve, « DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks », arXiv:2607.07946, 2026. Mesuré en août 2026 : 113 tâches originales dans cinq langages avec des vérificateurs basés sur des programmes. Les paires correspondent à deux exécutions chacune avec les tokens du conseiller comptabilisés par requête, et ont utilisé une boucle de conseiller côté client plutôt que l'outil conseiller, avec une comptabilité identique. Les balayages d'effort à modèle unique sont des exécutions uniques chiffrées à partir des compteurs de tokens, une approximation tenant compte du cache. Les coûts par tâche sont les totaux d'exécution divisés par 113.
11. Benchmark interne de codage agentique : Interne à Anthropic : 370 tâches de dépôt notées par les propres tests des dépôts. Les chiffres API (Opus 5 seul, Fable 5 seul et la paire) ont été mesurés en août 2026 à l'effort par défaut avec un plafond de sortie de 128 000 tokens, une exécution par configuration : cinq tentatives par tâche aux réglages par défaut et pour la paire, une à low et medium ; la paire a effectué en moyenne environ deux consultations du conseiller par tentative ; les coûts sont par tentative. Les chiffres de Claude Code sont des exécutions de juillet 2026 des mêmes tâches, une exécution par configuration, coûts approximatifs.
12. Benchmark interne de tâches de dépôt (mesure du plafond) : Un ensemble distinct interne à Anthropic d'environ 130 tâches de dépôt, exécuté en août 2026 avec une boucle d'agent API simple, une tentative par tâche. Les chiffres à 16 384 tokens sont la moyenne de deux exécutions par modèle ; les chiffres à 64 000 tokens sont des exécutions uniques (124 tâches notées pour Opus 5 ; 108 pour Claude Fable 5, l'environnement ayant ignoré le reste avant que le modèle ne s'exécute). Environ la moitié des tentatives de Fable que le plafond de 16 384 avait interrompues se sont terminées résolues à 64 000 ; une exécution supplémentaire de Fable à 128 000 a obtenu 56,1 %, dans le bruit de l'exécution à 64 000. Les chiffres de plafond SWE-bench Pro correspondent à une exécution de Claude Fable 5 par plafond à l'effort par défaut sur un sous-ensemble de 100 problèmes stratifié à partir de l'ensemble de 482 problèmes de la référence 3, non comparable à ses scores. Les distributions par tour du graphique proviennent de l'exécution d'Opus à 64 000 et de l'exécution de Fable à 128 000, de sorte qu'aucune n'est tronquée par son propre plafond.
13. Chartography : Surge AI, « Chartography », 2026. L'ensemble complet publié de 100 questions, mesuré en août 2026 avec l'implémentation d'Anthropic sur Claude Managed Agents (sandbox cloud standard ; les configurations avec conseiller utilisent le conseiller de Managed Agents). Claude Sonnet 4.6 note à la place du juge de référence et le benchmark s'exécute avec des outils, de sorte que les scores se comparent entre configurations ici mais pas au classement publié. Deux exécutions par configuration, regroupées ; les écarts d'une exécution à l'autre étaient de 4 à 10 points. Les coûts excluent le temps de sandbox, qui ajoutait moins de 1 %. La comparaison des taux de consultation provient de la réexécution des mêmes configurations sur l'API Messages avec un jeu d'outils de conteneur.
14. Évaluation d'audit de prompts de service d'assistance : Un ensemble construit par Anthropic de 44 tickets d'assistance avec notation déterministe, exécuté en août 2026 sous six invites système, chacune ajoutant au même prompt propre un schéma courant dans les prompts écrits pour Claude Opus 4.8 et Claude Sonnet 4.6. Chaque point du graphique est l'un de trois cas (ancien modèle, nouveau modèle sur le même prompt, nouveau modèle après l'audit) moyenné sur les six prompts et les 44 tickets. Le gain de précision d'Opus 5 a un intervalle de confiance à 95 % de 3 à 8 points ; les différences de précision de Sonnet sont dans le bruit.



Prochaines étapes