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 s'échangent contre la 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).

Le coût et l'intelligence sont généralement représentés comme une frontière où l'un achète l'autre. Le premier groupe de leviers de cette page déplace une charge de travail vers cette frontière en réduisant le coût sans toucher à la qualité ; seul le second groupe se déplace le long de celle-ci :

Les leviers sont de deux sortes :

• Les gains gratuits réduisent les dépenses sans toucher à la qualité : la « 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 « batch processing » (traitement par lots) à 50 % de réduction pour le travail qui peut attendre jusqu'à 24 heures, et les limites de dépenses d'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,7 à 5,3 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, pas 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é

Pourquoi la mise en cache vient en premier

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'« system prompt » (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'arrête 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.

À quoi ressemble un bon résultat. Sur une journée complète de trafic réel, les boucles d'agent ont lu une médiane de 84 % de leurs entrées depuis le cache, et les 10 % de harnais les plus performants, de codage ou non, ont lu 94 % ou plus¹⁷. En profondeur dans une tâche, une boucle bien construite paie le plein tarif sur moins de 1 % de ses entrées. En dessous d'environ 80 %, cherchez ce qui casse le cache (voir Ce qui casse le cache).

Dans l'ensemble des exécutions mesurées par Anthropic, les lectures du cache sont régulièrement la plus grande composante unique 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 évalué le prix des exécutions 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 du graphique de mise en cache ont lu 79 % à 90 % de leurs tokens d'entrée depuis le cache. 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 unique le plus important sur chaque modèle et chaque benchmark mesuré.

Choisir la durée du cache

Si votre boucle attend une personne 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). Un échec de cache sur l'une ou l'autre durée facture l'ensemble du préfixe au prix d'écriture au lieu du prix de lecture, de sorte que la durée plus longue est rentable dès que quelques tours par session suivent une pause comprise entre 5 minutes et une heure.

Pour décider, comptez les intervalles entre requêtes consécutives dans une conversation :

• Plus d'environ 1 intervalle sur 20 se situe entre 5 minutes et une heure, et les intervalles de plus d'une heure sont rares : utilisez la durée d'une heure.
• Les tours arrivent à quelques secondes d'intervalle : restez sur la valeur par défaut de 5 minutes. Lorsque rien n'était en pause, elle a coûté 15 % de moins que le réglage d'une heure sur Claude Sonnet 5 et 11 % de moins sur Claude Opus 5.
• Les intervalles de plus d'une heure sont fréquents : restez sur la valeur par défaut. Un intervalle de plus d'une heure fait expirer les deux durées, et le réglage d'une heure réécrit alors le préfixe à son prix d'écriture plus élevé, de sorte qu'il perd sur chacun de ces intervalles. Parmi vos pauses de plus de 5 minutes, si environ 60 % ou plus dépassent également une heure, restez sur la valeur par défaut ; la durée d'une heure n'est rentable que lorsqu'au moins environ 40 % des longues pauses se terminent dans l'heure.

Anthropic a mesuré la tâche de triage de Réduire les tokens d'entrée et de contexte avec des pauses insérées avant certains tours pour simuler le délai d'une personne¹⁶. Sur les deux modèles mesurés, le cache d'une heure est devenu le réglage le moins cher dès qu'environ 1 tour sur 30 suivait une pause, de sorte que la règle de 1 sur 20 laisse une marge, et l'écart se creuse rapidement au-delà du point de croisement car chaque tour en pause sur le réglage de 5 minutes réécrit l'ensemble du préfixe. Tous les modèles actuels utilisent les mêmes multiplicateurs d'écriture en cache, et tous les modèles sauf Claude Fable 5.1 et Claude Mythos 5.1 le même prix de lecture, de sorte que le point de croisement se situe dans la même plage sur les autres modèles ; Fable 5.1 est le cas traité ensuite. La précision est restée dans le bruit d'une exécution à l'autre dans chaque cellule. Le tour suivant une pause a conservé sa latence de cache chaud sur le réglage d'une heure. Le graphique suivant représente le coût par session en fonction de la part de tours en pause sur Claude Sonnet 5 :

Anthropic a également mesuré des requêtes supplémentaires qui gardent le cache de 5 minutes chaud. Sur Claude Sonnet 5 et Claude Opus 5, elles n'ont rien économisé de mesurable par rapport à la durée d'une heure, quelle que soit la part de tours en pause, et ont coûté plus cher avec une pause avant chaque tour ; utilisez donc plutôt la durée.

Sur Claude Fable 5.1, le réglage le moins cher est différent. Sa lecture du cache coûte 0,025x le prix d'entrée (0,25 $ par million de tokens) tandis que ses écritures en cache conservent les multiplicateurs standard, de sorte qu'une requête de maintien en vie qui relit le préfixe est bon marché et que la prime d'écriture de la durée d'une heure est la facture la plus élevée. Anthropic a mesuré la tâche de triage sur Claude Fable 5.1 avec les mêmes trois réglages¹⁹. Garder le cache de 5 minutes chaud a coûté 13 % à 20 % de moins par session que le cache d'une heure chaque fois que les pauses duraient quelques minutes ; ce n'est qu'avec des pauses proches de 45 minutes que le cache d'une heure a gagné, d'environ 12 cents par session. Sur Claude Fable 5.1, gardez le cache de 5 minutes chaud pendant qu'une personne s'absente quelques minutes, et achetez la durée d'une heure lorsque les pauses approchent une heure :

Pour garder le cache chaud, renvoyez la requête précédente avec max_tokens défini à 0 dans les 4 minutes suivant le début de la requête précédente, puis toutes les 4 minutes ensuite, en supprimant stream s'il était défini. Comptez à partir du début de la requête, pas de la fin de sa réponse : la durée de vie de 5 minutes du cache court à partir du début de la requête qui a écrit ou rafraîchi l'entrée, de sorte que le temps passé par la réponse à générer est décompté. C'est la requête de préchauffage : elle rafraîchit la durée de vie du cache, ne génère rien et ne facture que la lecture du cache. Ne changez pas un octet du préfixe, et n'utilisez pas max_tokens: 1, qui échantillonne un token sans raison. Renvoyez les en-têtes de la requête ainsi que son corps : si vos requêtes portent un en-tête anthropic-beta (pour un budget de tâche, par exemple), la requête de maintien en vie a besoin du même en-tête, sinon les champs soumis à la bêta dans le corps rejoué sont rejetés. Une requête max_tokens: 0 est rejetée lorsque la requête définit thinking.type: "enabled" (la réflexion adaptative par défaut sur Claude Fable 5.1 convient), des sorties structurées ou un choix d'outil forcé (ses limitations) ; sur ces charges de travail, achetez plutôt la durée d'une heure.

# Dans les 4 minutes suivant le début de la dernière requête (le temps de génération
# compte dans la durée de vie du cache), renvoyez cette requête avec max_tokens à
# 0, sans stream (une requête max_tokens: 0 ne peut pas utiliser le streaming). Envoyez
# les mêmes en-têtes que la requête d'origine, y compris tout en-tête anthropic-beta.
jq '.max_tokens = 0 | del(.stream)' last_request.json | \
  curl https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    --data-binary @-

Activer la mise en cache

La configuration demande peu de travail. La mise en cache automatique place les points d'arrêt 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 d'arrêt suivent le modèle standard décrit dans Points d'arrêt de cache explicites.

Ce qui casse le cache

Plusieurs choses peuvent casser votre cache pendant une tâche. Tout ce qui change par requête, comme un horodatage ou une position dans une file d'attente, placé avant le préfixe stable transforme chaque requête en une écriture complète du cache : sur l'exécution de triage de Réduire les tokens d'entrée et de contexte, une ligne d'état de 25 tokens au début de l'invite système a coûté 4,24 $ par exécution au lieu de 0,59 $, plus que d'exécuter avec la mise en cache désactivée. Gardez le texte par requête dans le tour utilisateur le plus récent.

Le cache est une correspondance de préfixe exacte à l'octet sur la requête dans l'ordre (outils, puis invite système, puis messages), de sorte qu'un changement n'importe où invalide tout ce qui suit. Changer effort ou la configuration de réflexion entre les requêtes invalide le cache à partir de ce point, et sur certains modèles également les outils et l'invite système qui le précèdent ; toute modification de l'invite système invalide le cache à partir de ce point ; définir ou changer un format de sortie invalide le cache pour toute la conversation ; ajouter, supprimer ou réordonner une définition d'outil l'invalide entièrement. La page sur la mise en cache des prompts liste ces cas, à l'exception du format de sortie, que couvre la page sur les sorties structurées. Sur les modèles les plus récents, changez les instructions avec un message système en cours de conversation, un message {"role": "system"} ajouté à messages, au lieu de modifier le champ system de premier niveau : le préfixe mis en cache reste intact. Consultez cette page pour savoir quels modèles le prennent en charge. Sur les modèles qui le prennent en charge, un changement d'effort par message laisse également le préfixe mis en cache intact. Les enjeux sont les plus élevés sur Claude Fable 5.1 et Claude Mythos 5.1 : une rupture réécrit le préfixe à 1,25x le prix d'entrée au lieu de le lire à 0,025x, de sorte que sur un préfixe de 100 000 tokens, un tour cassé coûte 1,25 $ au lieu de 0,03 $, 50 fois la lecture, contre 12,5 fois (0,63 $ au lieu de 0,05 $) sur Claude Opus 5.

Anthropic a mesuré cela sur les longues sessions de l'agent de triage¹⁸. Un changement d'effort et un outil ajouté effectués en milieu de session ont réécrit 39 000 et 60 000 tokens mis en cache, et ces sessions ont coûté 0,95 $ par session. Les mêmes deux changements sur la première requête après compaction ont coûté 0,75 $, et sur la requête qui a déclenché la compaction 0,92 $, car la passe de résumé de la compaction a alors retraité le contexte de 81 000 tokens au prix d'écriture en cache : cette passe de résumé a coûté 0,21 $, contre 0,04 $ lorsque les mêmes changements sont intervenus une requête plus tard, avec une précision dans le bruit d'une exécution à l'autre dans chaque bras :

Changer un budget de tâche en cours de route invalide tout préfixe mis en cache qui contient la valeur du budget ; définissez-le donc une 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 gros lots plutôt qu'en de nombreux petits. Sur Claude Fable 5.1 et Claude Mythos 5.1, chacun de ces cas coûte 50 fois le prix de lecture par token, c'est donc là qu'ils comptent le plus. Effectuez chaque changement invalidant le cache aux pauses naturelles, puis confirmez que les lectures du 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 coûte rarement en qualité de sortie, bien que tous les leviers présentés ici n'aient pas économisé d'argent lorsqu'ils ont été mesurés. Deux endroits où chercher :

• Réduction des entrées. Le filtrage dynamique dans l'outil de récupération web é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 (mesuré plus loin dans cette section). 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 changement. Anthropic les a mesurés sur 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 sur une variante plus longue de la même tâche avec 2,6 fois plus de tokens. Avec la mise en cache activée, la réduction des entrées (redimensionnement d'images et recherche d'outils) a retiré 26 % supplémentaires sur l'exécution courte et 21 % sur la longue.

Différer les définitions d'outils inutilisées

Chaque définition d'outil attachée à une requête est une entrée à chaque tour, et quelques serveurs MCP en totalisent des centaines. Anthropic a exécuté l'agent de triage avec ses deux propres outils plus un catalogue de définitions d'outils réelles provenant de serveurs MCP publics, pour un total allant jusqu'à 502 outils, en les chargeant tous ou en marquant les extras defer_loading derrière la recherche d'outils :

Avec chaque définition chargée, le coût d'exécution a presque doublé à mesure que le catalogue grandissait, suivant les tokens de schéma sur chaque requête. Avec la recherche d'outils, il est resté stable à chaque taille de catalogue, 45 % de moins à 502 outils. La précision était de 15 à 18 sur 20 dans chaque cellule dans les deux cas, et le modèle n'a jamais appelé un mauvais outil, de sorte qu'à cette échelle le catalogue coûte de l'argent, pas de l'exactitude. Il en va de même pour les outils qui passent par le connecteur MCP : avec un serveur MCP GitHub public attaché, différer son jeu d'outils (default_config: {defer_loading: true}) a réduit l'exécution de 20 % à précision égale.

Garder les fichiers de données hors du prompt

Lorsque le modèle doit effectuer des calculs sur un tableau, téléversez-le avec l'API Files et laissez le modèle l'interroger avec l'exécution de code au lieu de le coller. Anthropic a posé 25 questions d'agrégation¹⁵ (sommes, comptages filtrés, regroupements et un filtre de date) sur un CSV public de 1 862 lignes, avec les réponses calculées par pandas :

Collé dans le prompt, le tableau représente environ 91 000 tokens d'entrée à chaque requête, et Claude Sonnet 5 a répondu correctement à 6 questions sur 25. Téléversé, avec l'exécution de code, il a répondu aux 25, et l'exécution a coûté environ un douzième du prix. Claude Opus 5 a montré le même schéma.

Gérer le cycle de vie du contexte

Les leviers de contexte ne sont rentables que sur une session assez longue pour en avoir besoin :

Sur l'exécution de 20 tickets, ils n'ont rien économisé, et l'édition de contexte a coûté 74 % de plus. Sur l'exécution longue, l'élagage a économisé 39 % et la compaction 32 %, tandis que l'édition de contexte n'a rien changé. L'élagage consiste en quelques lignes que vous écrivez vous-même : à chaque frontière de tâche, remplacez les gros résultats d'outils obsolètes par un extrait d'une ligne. Il se met bien en cache car les modifications se trouvent à la fin de la conversation, là où la tâche suivante ajoute de toute façon du nouveau contenu : 89 % de lectures du cache sur la première requête après une frontière et 81 % sur les requêtes entre les frontières. Sur l'ensemble de l'exécution, l'élagage et l'édition de contexte se mettent en cache à peu près aussi bien. L'élagage est moins cher parce que l'édition de contexte réécrit en milieu de tâche du contenu que l'élagage supprime (environ deux tiers de l'écart) et parce qu'il maintient le contexte à environ la moitié de la taille (l'autre tiers). Si vous utilisez l'édition de contexte, effacez en quelques gros lots. L'élagage, adapté du harnais :

import re

PRUNED = "[pruned at issue boundary]"


def prune_task_boundary(messages, tool_name_by_id, threshold=2000):
    """Call once per task boundary. Replaces large, stale search results with a one-line extract."""
    for message in messages:
        if message["role"] != "user" or not isinstance(message["content"], list):
            continue
        for block in message["content"]:
            if not (isinstance(block, dict) and block.get("type") == "tool_result"):
                continue
            if tool_name_by_id.get(block.get("tool_use_id")) != "search_issues":
                continue
            result_text = block.get("content")
            if not isinstance(result_text, str) or len(result_text) <= threshold:
                continue
            if result_text.startswith(PRUNED):
                continue  # already pruned on an earlier boundary
            # limiter les résultats sur une ligne pour garder l'extrait court
            first_line = result_text.split("\n", 1)[0].strip()[:200]
            refs = re.findall(r"#(\d+)", result_text)[:5]
            extract = f"{PRUNED} {first_line}"
            if refs:
                extract += " kept refs: " + " ".join("#" + r for r in refs)
            block["content"] = extract

Mettre en 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. La mise en 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 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. Elle 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 minutieux 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 est une seule 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 schémas :

$ 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 ont coûté 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 minutieux que possible » presque autant. Le texte qui ne convient plus au modèle coûte plutôt en précision : un réglage de réflexion retiré, des règles contradictoires et un bloc-notes fait maison qui entre 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 schémas ont tendance à apparaître dans les descriptions d'outils et les skills, qui méritent également d'être auditées.

É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.1 (le 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.1 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 recherche, moins de relecture de son propre contexte et moins de retours en arrière. La prime par token est souvent largement compensée par le fait de faire moins de tout.

Anthropic a mesuré cela sur le sous-ensemble SWE-bench Pro³, au prix facturé à un client :

Claude Fable 5.1 à l'effort low a résolu 88,6 % des tâches pour 0,54 $ par tâche résolue, contre 77,4 % pour 0,84 $ avec Claude Sonnet 5 à sa valeur par défaut : 11 points de plus pour 35 % de moins par tâche résolue, malgré un prix par token cinq fois plus élevé. Il ne gagne cependant pas toujours. Sur le même sous-ensemble, 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.1 seul à la valeur par défaut (91,7 % contre 92,1 %, dans le bruit d'une exécution à l'autre) pour environ 15 % de moins par tâche résolue (1,01 $ contre 1,19 $), et Opus 5 à low a résolu 84,0 % pour 0,25 $. Et sur les longues boucles de recherche, le modèle de pointe fait plus de travail, pas moins : sur DeepResearch Bench II⁷, Fable 5.1 à low a obtenu 10 points de plus que Sonnet 5 (66 % contre 56 %) pour environ quatre fois le coût par tâche (4,66 $ contre 1,20 $), car il exécute une boucle de recherche plus longue sur un contexte plus large. Claude Opus 5 à sa valeur par défaut a obtenu 71 % sur la même base pour 6,71 $ par tâche, au-dessus de Fable 5.1 à sa valeur par défaut (65 % pour 7,12 $), de sorte que sur la recherche aussi Fable 5.1 ne justifie son prix qu'à low.

Pour la plupart des charges de travail d'agent, commencez avec Claude Fable 5.1 à l'effort low et augmentez l'effort là où il échoue. Par token, il coûte deux fois ce que coûte Claude Opus 5 sur les entrées non mises en cache, mais moitié moins sur les entrées mises en cache (0,25 $ contre 0,50 $ par million), et dans une boucle d'agent les entrées mises en cache sont le terme le plus important. Sur le benchmark de codage de la Stratégie du conseiller, Fable 5.1 à medium a égalé Opus 5 à sa valeur par défaut pour environ un tiers du coût par tentative (2,91 $ contre 8,50 $). Sur Chartography¹³, un benchmark de lecture de graphiques, Fable 5.1 à low a obtenu 62,5 pour 0,15 $ par graphique, contre 49 pour 0,38 $ avec Opus 5 à low. Sur le sous-ensemble SWE-bench Pro, Claude Opus 5 à sa valeur par défaut reste le moyen le moins cher d'atteindre le meilleur score, comme indiqué précédemment. À 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. Évaluez le prix de 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.

Évaluez le prix de la queue de votre charge de travail, pas de 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 lorsque 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.

Mettre à niveau le modèle

Si vous avez un ou deux modèles de retard, le levier le moins cher est la chaîne du modèle. Anthropic a fait passer les modèles récents Claude Opus, Claude Sonnet et Claude Fable par le même harnais sur le sous-ensemble SWE-bench Pro³, chacun à ses valeurs par défaut livrées et au prix catalogue, et a exécuté à nouveau la gamme Opus sur Terminal-Bench 3²⁰ :

Anthropic tarifie la gamme Opus de manière identique par token d'une version à l'autre, de sorte que toute différence provient de la quantité de travail que chaque modèle effectue par tâche : au prix facturé à un client, Claude Opus 4.8 résout la même part de tâches que Claude Opus 4.7 pour 14 % de moins par tâche résolue, et Claude Opus 5 résout ensuite 12 points de tâches de plus pour 21 % de plus par tâche résolue. Claude Opus 5 à l'effort low bat la valeur par défaut d'Opus 4.8 sur ce benchmark pour environ 30 % de son coût par tâche résolue, de sorte que la mise à niveau la moins chère est le nouveau modèle à un réglage inférieur. L'économie de Sonnet 5 provient de son prix par token plus bas, qui compense largement les tokens supplémentaires qu'il utilise par tâche par rapport à Sonnet 4.6 : 15 % de moins par tâche résolue pour 5 points de plus. Le niveau de pointe a progressé de la même manière : Claude Fable 5.1 égale le score de Claude Fable 5 pour 43 % de moins par tâche résolue, l'essentiel provenant du prix de lecture du cache plus bas. Cette direction n'est pas garantie : sur DeepResearch Bench II⁷, la même mise à niveau coûte 41 % de plus par tâche à high (79 % de plus à low) pour ses 2 à 3 points supplémentaires sur les tâches propres dans chaque bras (référence 7), car le nouveau modèle y effectue plus de travail par tâche. Les prix d'entrée et de sortie sont les mêmes et la lecture du cache est 4x moins chère ; mesurez donc la mise à niveau sur votre propre charge de travail avant de supposer qu'elle économise.

Sur un travail plus difficile, l'écart se creuse. Sur Terminal-Bench 3²⁰, où les tâches sont assez difficiles pour que le taux de réussite plutôt que les tokens détermine la facture, Claude Opus 4.7, Opus 4.8 et Opus 5 dépensent chacun 8 $ à 15 $ par tâche mais résolvent 7 %, 15 % et 41 % des tâches, de sorte que le coût par tâche résolue passe de 183 $ à 63 $ puis à 28 $ en montant l'échelle. La prime de 21 % que Claude Opus 5 porte par rapport à Opus 4.8 sur le sous-ensemble de codage saturé devient une économie de 56 % sur Terminal-Bench 3, où l'ancien modèle échoue le plus souvent : plus votre charge de travail met en échec l'ancien modèle, plus la mise à niveau économise par résultat.

Comparez sur le coût par tâche résolue, pas par token : le même texte coûte environ 30 % de tokens en plus sur Claude Opus 4.7 et les versions ultérieures, de sorte qu'une comparaison par token fait paraître les modèles plus récents plus chers par construction.

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'autovérification que le modèle effectue, et la valeur par défaut (high) convient aux tâches exigeantes. Le coût augmente avec toute cette activité ; la précision n'augmente qu'avec la part 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 une réduction d'un tiers à la moitié du coût par tâche, medium a égalé la précision de la valeur par défaut pour environ 70 % à 87 % 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 doté d'un « worker » (modèle travailleur) Claude Sonnet 5 pour un coût inférieur de 29 % : réduire l'effort a fait mieux qu'un changement d'architecture.

Les réglages d'effort plus bas sont souvent plus rapides, ce qui compte lorsque la « latency » (latence) est la contrainte. Dans ces exécutions, low a pris 4,5 minutes par problème sur DeepWideSearch, contre 7,9 minutes avec la valeur par défaut. Sur le benchmark de corpus, dont l'entrée ne tient dans aucune « context window » (fenêtre de contexte) unique, Fable 5.1 a pris 15,2, 17,5 et 19,9 heures par épisode à low, medium et high.

Le codage à long horizon est le domaine où l'effort achète réellement de la précision. 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 a coûté plus cher que ce même modèle à un effort plus bas. Deuxièmement, cette courbe est la référence mono-modèle 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 des références sur tous les niveaux d'effort.

Un travail difficile ne nécessite pas automatiquement un effort élevé. Sur DeepResearch Bench II⁷, Claude Fable 5.1 a obtenu presque le même score à low, medium et high tandis que le coût par tâche passait de 4,66 $ à 7,12 $, de sorte qu'augmenter l'effort dans ce cas n'améliore pas sensiblement la qualité de la sortie ; sur les 21 tâches valides dans chaque bras d'expérience (référence 7), Claude Fable 5 était également plat sur tous les niveaux d'effort, bien que la base de 33 tâches du graphique, qui écarte les tentatives interrompues propres à chaque modèle, le montre en progression. Mesurez la courbe sur le modèle que vous déployez, pas sur celui que vous avez mesuré en dernier :

La description de la tâche seule ne révèle pas quel type de charge de travail vous avez, alors balayez 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 : modifier l'effort de niveau supérieur 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 par niveau d'effort sur le sous-ensemble SWE-bench Pro³ de la section 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,45 $ chacune, contre 91,7 % pour 0,93 $ 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,61 $. 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 donne à 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 un mauvais travail laisse passer ces échecs. Deuxièmement, chaque échec de première passe prend l'équivalent de deux exécutions en temps réel écoulé, 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 de distribution. Le modèle voit un décompte de tokens en direct pour l'ensemble de la tâche et s'autorégule, en réduisant 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.1 à mesure que le budget se resserrait :

Un budget généreux a réduit le coût par tâche de 44 % pour environ 3 points de taux de réussite, à la limite du bruit d'une exécution à l'autre, et le budget le plus serré autorisé l'a réduit de 58 % pour 6 points. Les budgets ont acheté de l'efficacité ici, à un prix en taux de réussite qui augmente à mesure que le budget se resserre.

Trois contrôles remplissent trois fonctions différentes. Un budget de tâche fait économiser de l'argent, parce que le modèle le voit. max_tokens est un plafond de sécurité : l'abaisser a réduit le coût par tentative sans réduire le coût par tâche résolue. 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 d'espace de travail comme dernier filet de sécurité.

• Les budgets de tâche sont en bêta (en-tête bêta task-budgets-2026-03-13) sur les modèles les plus récents ; consultez le tableau de prise en charge pour savoir lesquels. 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 un changement en cours de tâche invalide le cache. Le budget est indicatif, il oriente le modèle plutôt que de l'arrêter, 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 l'abaisser ne pousse pas le modèle à économiser. Les tours qui avaient besoin de cette marge sont écartés et tout de même facturés. Sur un benchmark interne de tâches sur dépôt¹², un plafond de 16 384 tokens a interrompu 15 % des tentatives de Claude Opus 5 et 43 % de celles de Claude Fable 5.1 à l'effort par défaut, et seules 9 des 117 tentatives Fable plafonnées ont tout de même réussi. 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 à peu près le même qu'à 64 000 (21 $ contre 22 $). À 64 000, 2 tours sur environ 14 000 à l'effort par défaut étaient encore coupés, et Fable 5.1 a résolu 58,5 % des tâches au lieu de 36,3 % (sur une coupe distincte du sous-ensemble SWE-bench Pro³, décrite dans la référence 12, aucune différence : 94 sur 100 avec l'un ou l'autre plafond). Réessayer les tentatives plafonnées aide rarement : au même plafond, la plupart échouent à nouveau, et à un plafond plus élevé vous payez aussi la tentative gaspillée. Définissez max_tokens à 64 000 pour le travail agentique, ou à 128 000, le maximum, lorsqu'une seule tentative coupée est coûteuse ; à 128 000, Fable 5.1 a résolu 60,0 % pour le même coût par tâche résolue. 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 catalogue 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 catalogue, y compris les modèles où les budgets de tâche ne sont pas encore disponibles, et se combine avec le budget de tâche indicatif. Les déploiements appliquent le même champ à chaque exécution.

Demandez des réponses plus courtes. Les tokens de sortie coûtent cinq fois les tokens d'entrée sur Claude Sonnet 5, et dans une boucle d'agent chaque token que le modèle écrit revient en entrée à chaque tour ultérieur, de sorte que vous payez une longue réponse encore et encore. Anthropic a exécuté la tâche de triage sous trois instructions de réponse finale, trois exécutions chacune, avec le même modèle et les mêmes outils. L'originale demandait deux lignes :

4. Finish with exactly two lines:
LABEL: <one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish>
SUMMARY: <one or two sentences for the engineering team>

La variante plus courte en demandait une :

4. Finish with exactly one line in this form:
DECISION | LABEL | REASON
where DECISION is one of: triage-now, needs-info, close-duplicate; LABEL is one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish; REASON is one clause under 15 words. Output nothing after that line.

La variante plus longue demandait un mémo avec cinq sections titrées : résumé du problème, preuves, vérification des doublons, étiquette recommandée et prochaines étapes. Pour un ticket, un prompt en file d'attente qui n'est jamais envoyé après une question ignorée, les deux premières réponses étaient :

LABEL: bug-confirmed
SUMMARY: When a user submits a new prompt instead of answering an agent's pending question, the question is cancelled/skipped but the new prompt remains stuck in "QUEUED" state indefinitely since it's waiting on a response to the now-cancelled question; the queued prompt should be processed immediately after cancellation.

triage-now | bug-confirmed | Clear repro steps show prompt queues indefinitely after cancelled question.

La réponse sur une ligne a utilisé 39 % de tokens de sortie en moins que l'originale sur deux lignes et a coûté 14 % de moins par exécution. Le mémo a utilisé six fois plus de tokens de sortie et a coûté 2,8 fois la réponse sur une ligne. Les trois ont obtenu des scores à l'intérieur du bruit d'une exécution à l'autre les uns par rapport aux autres face aux étiquettes de référence, de sorte que les formats diffèrent bien plus par ce que vous payez que par ce qu'ils réussissent. Demandez la réponse que vous lirez, pas celle qui paraît exhaustive.

Au plafond max_tokens inférieur, les deux modèles dépensent moins par tentative mais résolvent proportionnellement moins de tâches, de sorte que le coût par tâche résolue bouge à peine :

Presque chaque tour se termine bien en dessous de l'un ou l'autre plafond. Le rare tour long est ce que le plafond plus élevé achète :

Combiner des 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 routinier 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 ajusté 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 « advisor » (conseiller), un modèle exécuteur moins coûteux exécute la boucle d'agent et effectue la plupart des tours. Lorsqu'il rencontre une décision qui nécessite un jugement plus approfondi, comme choisir une approche ou se remettre d'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 aux tarifs du conseiller.

Pour l'utiliser, ajoutez l'outil advisor à 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 advisor.

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

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

La seconde, et la plus fragile, est de savoir si l'exécuteur demande réellement (le « consult rate », ou taux de consultation). Un exécuteur à faible effort peut cesser de détecter qu'il est bloqué : une paire qui consulte sur la plupart des tâches à l'effort par défaut peut tomber à ne consulter sur presque aucune lorsque l'effort est abaissé, et obtient alors un score inférieur à l'exécuteur seul. Le taux varie aussi 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 récupère une grande partie de l'écart. Parmi les paires du graphique suivant dont l'exécuteur a continué à demander, le conseiller a comblé au moins la moitié de l'écart avec le modèle plus fort (la paire de codage a carrément battu le modèle plus fort), et vous ne payez le modèle plus fort que sur les consultations, ce qui rend possibles les cas d'économie :

Le taux de consultation répond au prompting. Avec seulement la description intégrée de l'outil, les exécuteurs appellent trop peu, surtout sur le travail de codage, c'est pourquoi la documentation de l'outil advisor fournit une invite système qui demande un appel avant tout travail substantiel et un avant de terminer, soit environ deux à trois appels par tâche. La paire de codage mesurée ensuite a fonctionné à cette cadence, environ deux consultations sur chaque tâche. Cette page couvre également comment inciter un exécuteur qui appelle trop peu et comment 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, parce que le conseil fait 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 simple agent API, un exécuteur Claude Opus 5 avec un conseiller Claude Fable 5.1 était la configuration la plus précise mesurée, à 7,69 $ par tentative. Elle se situe au-dessus de la ligne passant par les propres réglages d'effort de chaque modèle : 3,5 points au-dessus d'Opus 5 seul au réglage par défaut pour un peu moins d'argent, un écart que cinq tentatives par tâche distinguent bien du bruit, et environ 2,5 points au-dessus du modèle du conseiller seul pour environ une fois et demie le prix :

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 : le conseiller achète quelques points à peu près au prix de l'exécuteur lui-même. Un écart de capacité plus large ne garantit pas une meilleure affaire. Le coût en latence est constitué des 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 le modèle plus fort seul est la meilleure étape. Lorsque la précision d'une charge de travail répond à l'effort, comparez la paire avec le modèle du conseiller seul à un réglage réduit avant de la construire : le conseiller n'est payé que sur les tâches qui en ont besoin, mais une consultation qui se déclenche sur la plupart des tâches coûte plus cher que d'exécuter le modèle plus fort lui-même. Sur Chartography¹³, la même paire a égalé Claude Fable 5.1 seul à medium à l'intérieur du bruit d'une exécution à l'autre (65,0 contre 67,5) pour environ 2,6 fois le coût par tâche, parce que le conseiller était consulté sur presque chaque tâche. Mesurez d'abord votre propre taux de consultation : si l'exécuteur demande sur la plupart de ses tâches, vous payez les tarifs du conseiller sur toute la charge de travail, et exécuter le modèle du conseiller lui-même est le moyen le moins cher d'atteindre le même score.

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, le modèle de pointe tient la boucle. Il décompose la tâche, répartit les sous-tâches vers des modèles workers moins coûteux et fusionne leurs résultats. La propre transcription de l'orchestrateur reste courte parce que les workers absorbent l'exploration gourmande en tokens, de sorte que la plupart des tokens sont facturés aux tarifs des workers 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 workers, chacun avec son propre modèle. Pour un exemple fonctionnel complet avec un coordinateur de pointe et des workers 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 écoulé lorsque les workers peuvent s'exécuter en parallèle : sur le benchmark de corpus⁸, un épisode a pris environ 2,3 heures avec le coordinateur exécutant la limite documentée de la plateforme de 25 workers simultanés, contre 15 à 20 heures en solo. Il n'a fait économiser de l'argent que dans deux situations mesurées. Sur un travail qu'un modèle unique pouvait gérer seul, le même modèle à un effort plus bas était moins cher à chaque fois.

Cas 1 : assurance contre la queue de coût sur le travail routinier. Un modèle de pointe fonctionnant seul s'emballe occasionnellement sur un problème routinier 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 routinier à un worker moins coûteux plafonne cette queue, parce que tout emballement se produit désormais aux tarifs du worker.

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 en solo). Un coordinateur Claude Fable 5 avec un worker Claude Sonnet 5 a coûté environ la moitié de Claude Fable 5 seul en moyenne et environ un tiers au 90e percentile (12 $ contre 33 $), et l'exécution la plus chère du modèle solo, à 84 $, était également fausse :

La délégation a payé sur la part routinière, normalement résoluble, du travail, à l'opposé de l'intuition selon laquelle les workers sont faits pour les 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 routinières, 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 parcourir une entrée de cette taille en série, une fenêtre de contexte à la fois, en payant pour relire son propre état à chaque passe. Les workers lisent chacun leur propre partition, en parallèle et aux tarifs des workers. Un travail à forte lecture qui tient encore dans une 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 de 14 paquets Python publics avec 130 défauts implantés, trop grand pour toute fenêtre de contexte. Abaisser l'effort ne peut pas aider, parce que la facture est la lecture du corpus elle-même : Claude Fable 5.1 en solo a coûté 468 $ à 552 $ par épisode sur les trois réglages d'effort, et seule sa précision a bougé. La configuration avec coordinateur, un chef Claude Fable 5.1 au-dessus de 25 workers Claude Sonnet 5, a coûté environ la moitié de ces réglages (47 % à 55 % de moins) et a obtenu 10 à 12 points de moins qu'eux, en environ 2,3 heures par épisode contre 15 à 20, tout en battant carrément une référence Claude Sonnet 5 en solo :

La comptabilité des tokens montre l'ampleur de la lecture : la configuration avec coordinateur a lu environ 560 millions de tokens mis en cache par épisode, environ une fois et demie les quelque 365 millions du modèle solo, presque tous au tarif de lecture de cache de Claude Sonnet 5, et a tout de même coûté environ la moitié au total. Fable 5.1 à l'effort high détient toujours la précision maximale, à environ 2,2 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 morceaux indépendants, idéalement trop nombreux pour une fenêtre de contexte. Lorsque le travail est une seule chaîne dépendante, 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 à un effort plus bas l'a emporté.

La frontière est la difficulté de la tâche, pas le benchmark : sur l'ensemble BrowseComp⁴ complet, plus difficile, Claude Fable 5 seul a atteint la précision de la configuration avec coordinateur pour un coût inférieur de 22 % à 30 %. Des travaux externes indépendants rapportent le même schéma⁵. Si le travail est une seule chaîne, tient dans un seul contexte sans longue queue de coût, ou si un modèle unique à un effort plus bas 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 morceaux 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 chère de cette page, et la plupart des charges de travail s'arrêtent là.
2. Si le balayage montre un écart, chiffrez le modèle plus fort 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 a réellement consulté.

Les résultats multi-modèles de cette page ont été jugés par rapport au même modèle à un effort plus bas et par rapport au modèle immédiatement inférieur fonctionnant seul. C'est la comparaison à effectuer sur votre propre charge de travail, et la raison pour laquelle la première étape est un balayage d'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 reflètent les prix catalogue au moment de la mesure et dériveront à mesure que les modèles et les prix changent. Votre taux de remontée, la netteté avec laquelle les tâches se divisent et la longueur des transcriptions les font également bouger. 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 cinq décomptes de tokens tarifés dans le usage de chaque réponse à leurs propres tarifs (entrée non mise en cache, écritures de cache de 5 minutes et d'une heure à 1,25x et 2x le prix d'entrée, lectures de cache et sortie), additionnés sur les requêtes de la tâche (l'API Usage and Cost rapporte l'agrégat).
2. Établissez la référence des niveaux de modèles sur tous les niveaux d'effort, pas seulement la valeur 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 d'une requête aux prix catalogue de Claude Opus 5 :

# Prix par million de tokens issus de la page de tarification ; modifiez ces trois valeurs pour un autre modèle.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
# 0,1x le prix d'entrée ; 0,025x sur Claude Fable 5.1 et Claude Mythos 5.1
CACHE_READ_PER_MTOK = 0.50
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
cache_writes = usage.cache_creation
writes_1h = cache_writes.ephemeral_1h_input_tokens if cache_writes else 0
writes_5m = cache_writes.ephemeral_5m_input_tokens if cache_writes else 0
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # Écritures en cache 1 h facturées à 2x le prix d'entrée, 5 min à 1,25x ; lectures au prix de lecture du cache.
    + writes_1h * INPUT_PER_MTOK * 2.0
    + writes_5m * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * CACHE_READ_PER_MTOK
    + 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 cinq ; sinon, vérifiez que la mise en cache est activée. Lorsque l'outil advisor ou la compaction est activé, certains tokens ne sont rapportés que dans usage.iterations et non dans les totaux de niveau supérieur, additionnez donc plutôt sur usage.iterations, en chiffrant les entrées advisor_message aux tarifs du modèle conseiller.

Le tableau suivant liste les leviers dans l'ordre où les essayer :

Benchmarks référencés

Sauf indication contraire dans une référence, les mesures sont des exécutions internes à Anthropic de ces benchmarks. Sauf mention contraire, les coûts sont en USD aux prix catalogue en vigueur au moment de l'exécution de chaque benchmark ; les chiffres de Claude Sonnet 5 utilisent 2 $ et 10 $ par million de jetons d'entrée et de sortie. Les graphiques étiquetés « notional USD » (USD notionnels) valorisent le nombre de jetons 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, exécutées du 1er au 2 août 2026. Le graphique de concentration des coûts est une exécution distincte de 20 problèmes, 3 exécutions par problème, exécutée du 3 au 4 août 2026, dont le coût est établi à 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 d'évaluation par tâche ; une exécution de 210 tâches de l'ensemble de référence publié, une tentative par tâche, exécutée le 2 août 2026. Un modèle Claude effectue la notation, 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és pour leur 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 ; toutes ont été exécutées le 4 août 2026. 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 appariements d'exécutions pour environ 0,45 $ ; medium d'abord, 93,8 % à 94,2 % pour environ 0,61 $ ; le réglage par défaut réexécuté sur ses propres échecs, 94,0 % pour 1,06 $ ; tout au réglage par défaut, 90,9 % à 92,5 % pour 0,93 $. Les coûts sur ce sous-ensemble sont valorisés comme l'organisation d'un client est mesurée : le prompt antérieur de chaque requête comme une lecture de cache et ses nouveaux jetons comme une écriture de cache de 5 minutes, à partir des propres enregistrements d'utilisation des exécutions, vérifiés par rapport au registre d'un client ; la propre mesure de l'organisation d'évaluation, qui facture le cache par pages de 8 192 jetons, a donné des chiffres 1,4 à 1,8 fois plus élevés. Les appariements avec exécuteur Claude Sonnet 5 sur le graphique du conseiller proviennent de la même série de mesures sur ce sous-ensemble : l'appariement Sonnet-plus-Opus a été exécuté deux fois (les 7 et 8 août 2026, une exécution et une réplication exacte), l'appariement à faible effort une fois (le 8 août 2026), et Claude Sonnet 5 seul deux fois (77,4 %, la référence pour les deux lignes Pro). Le point Claude Fable 5 dans Mettre à niveau le modèle est la moyenne de trois exécutions à l'effort par défaut, exécutées le 26 août 2026, valorisées de la même manière. Les chiffres de budget de tâche de Claude Fable 5.1 correspondent à une exécution par budget (deux à 35 000 jetons) sur le même sous-ensemble à l'effort par défaut, exécutées le 26 août 2026, avec une exécution sans budget le même jour (92,1 %, 1,10 $ par tâche) comme référence ; un ensemble antérieur à l'effort low, exécuté le 21 août 2026, a obtenu 88,6 % sans budget à 0,48 $ par tâche. La comparaison Comparer les modèles apparie cette exécution unique avec les deux exécutions Claude Sonnet 5 regroupées du même sous-ensemble ; à l'effort par défaut de Fable 5.1, la paire se lit dans l'autre sens, 41 % de plus par tâche résolue que Sonnet 5. L'échelle de mise à niveau correspond à une exécution par modèle à ses réglages par défaut livrés (deux chacun pour Opus 5 et Sonnet 5, et le point Fable 5 tel que décrit ci-dessus), les exécutions Opus et Sonnet la même semaine dans un même harnais et une même organisation.
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, exécutées le 3 août 2026, le point par défaut regroupant deux exécutions des 26 et 27 juillet 2026. 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 (du 1er au 2 août 2026) et 70 exécutions en solo (50 du 2 au 3 août 2026 ; 20 archivées des 12 et 13 juillet et du 1er août 2026), 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 n'est pas rentable, et non pour un quelconque chiffre.
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, exécutées le 2 août 2026 (le point d'équipe à un seul travailleur a été exécuté les 26 et 27 juillet 2026).
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 par réglage, sur Claude Managed Agents avec les propres outils de recherche web et de récupération de la plateforme (du 26 au 27 août 2026) ; noté sur les 33 tâches qu'aucune configuration n'a refusées, les tentatives interrompues par les classificateurs de sécurité de production étant retirées ; les coûts correspondent à ce qui est facturé à un client, les requêtes de la plateforme plus les frais de recherche web. Les scores sont la moyenne de chaque modèle sur la base des 33 tâches, ses propres tâches préemptées étant retirées ; sur les 21 tâches propres dans chaque bras, Claude Fable 5.1 conserve une avance de 2 à 3 points sur Claude Fable 5 à chaque niveau d'effort et les deux modèles sont stables quel que soit l'effort. Le graphique de mise en cache revalorise les mêmes requêtes avec chaque jeton d'entrée au tarif sans cache. 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. Claude Opus 5 à son effort par défaut a été exécuté sur la même surface et le même sous-ensemble, trois exécutions, le 28 août 2026 : 68,8 % sur les 50 tâches brutes, 70,8 % sur la base des 33 tâches et 71,1 % sur l'ensemble de 21 tâches, à 6,71 $ par tâche (23,72 $ sans mise en cache) ; aucune de ses tentatives n'a été interrompue par les classificateurs de sécurité, sous un déploiement de garde-fous plus récent que celui sous lequel les autres modèles ont été exécutés.
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 jetons issu de 14 sources publiques de paquets Python 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 sur le graphique est une exécution dans laquelle le coordinateur Claude Fable 5.1 a mené l'ensemble du balayage au sein de la plateforme à sa limite documentée de 25 travailleurs Claude Sonnet 5 simultanés, exécutée le 30 août 2026 ; ses trois épisodes ont obtenu des F1 de 0,764, 0,825 et 0,791 après l'audit des extras (bruts 0,751, 0,821 et 0,781) pour 225 $, 234 $ et 283 $. La configuration Claude Sonnet 5 en solo a été exécutée du 3 au 4 août 2026 ; les configurations Claude Fable 5.1 en solo ont été exécutées du 24 au 25 août 2026, sous les réglages de service de lancement de la plateforme, trois graines par réglage d'effort, sur la même version du corpus. L'image du bac à sable contenait des copies installées d'une partie du corpus, et l'étape d'assemblage final de Claude Fable 5.1 s'y est comparée dans 7 épisodes sur 9 ; une nouvelle notation sans ces ajouts a déplacé les graines concernées de 3 points au maximum. 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, deux exécutions par configuration, exécutées le 7 août 2026, noté par modèle par rapport aux réponses de référence, jetons du conseiller mesuré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. L'ensemble comporte 113 tâches originales dans cinq langages avec des vérificateurs basés sur des programmes. Les appariements correspondent à deux exécutions chacun, exécutées le 7 août 2026, avec les jetons du conseiller mesuré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 valorisées à partir du nombre de jetons, 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 de l'API ont été mesurés avec un plafond de sortie de 128 000 jetons, une exécution par configuration : Opus 5 seul à l'effort par défaut du 9 au 10 août 2026, Claude Fable 5.1 seul à cinq valeurs d'effort explicitement définies le 20 août 2026, et l'appariement du 24 au 25 août 2026. Tentatives par tâche : cinq pour l'appariement et le témoin Opus seul, une pour les points à modèle unique ; l'appariement a compté en moyenne environ deux consultations du conseiller par tentative ; les coûts sont par tentative. Les chiffres de Claude Code sont des exécutions des mêmes tâches du 8 au 23 juillet 2026, 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é du 8 au 10 août 2026 (Claude Opus 5) et le 20 août 2026 (Claude Fable 5.1), avec une simple boucle d'agent API, une tentative par tâche. Les exécutions Claude Fable 5.1 comptent 135 tâches par plafond à l'effort par défaut défini explicitement : le chiffre à 16 384 jetons est la moyenne de deux exécutions (36,3 % pour les deux) ; les chiffres à 64 000 et 128 000 sont des exécutions uniques (58,5 % et 60,0 %). Six problèmes ont suscité un refus de sécurité à chaque exécution et comptent comme des échecs. Le chiffre Opus 5 à 16 384 jetons est la moyenne de deux exécutions et son chiffre à 64 000 est une exécution unique (124 tâches notées). Les chiffres de plafond SWE-bench Pro correspondent à une exécution Claude Fable 5.1 par plafond à l'effort par défaut, exécutée le 26 août 2026, 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 deux plafonds ont obtenu le même score au réglage par défaut. Les distributions par tour du graphique proviennent de l'exécution Opus à 64 000 et de l'exécution Claude Fable 5.1 à 128 000 ; aucun tour Opus n'a atteint son plafond, et un tour Fable 5.1 a atteint 128 000 (0,46 % de ses tours ont dépassé 16 384).
13. Chartography : Surge AI, « Chartography », 2026. L'ensemble complet publié de 100 questions, mesuré du 8 au 10 août 2026, avec l'implémentation d'Anthropic sur Claude Managed Agents (bac à sable 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 bac à sable, qui ajoutait moins de 1 %. Les exécutions Claude Fable 5.1 en solo datent du 24 août 2026, sous les réglages de service de lancement de la plateforme, deux exécutions par réglage ; six tentatives ont atteint le plafond de session de 15 minutes et obtiennent 0, et deux graphiques par exécution ont reçu une réponse de Claude Opus 5 après un refus de sécurité. L'exécuteur Claude Opus 5 à faible effort avec un conseiller Claude Fable 5.1 a été exécuté deux fois le 30 août 2026, sous les mêmes réglages (63,0 et 67,0, moyenne 65,0, à 0,72 $ par graphique ; le conseiller a été consulté sur 88 % des tâches dans chaque exécution, et 4 de ses 219 réponses provenaient à la place de Claude Opus 5, chacune après qu'un filtre de sécurité de production a arrêté la propre réponse du conseiller). La comparaison des taux de consultation pour les appariements antérieurs provient de la réexécution des mêmes configurations sur l'API Messages avec un jeu d'outils de conteneur, du 10 au 11 août 2026.
14. Évaluation d'audit de prompt de service d'assistance : Un ensemble construit par Anthropic de 44 tickets d'assistance avec notation déterministe, exécuté début août 2026 et rapporté le 8 août 2026, sous six invites système, chacune ajoutant au même prompt propre un motif 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 d'exactitude d'Opus 5 a un intervalle de confiance à 95 % de 3 à 8 points ; les différences d'exactitude de Sonnet sont dans le bruit.
15. Ensemble de questions sur fichier de données : Un ensemble construit par Anthropic de 25 questions d'agrégation sur une tranche de 1 862 lignes d'un CSV public de ventes d'alcool, avec une vérité terrain calculée par pandas et une notation par correspondance exacte, exécuté sur Claude Sonnet 5 et Claude Opus 5 avec la réflexion désactivée (le bras en contexte ne peut pas terminer au réglage par défaut), un plafond de sortie de 4 000 jetons et sans mise en cache des prompts, trois exécutions par configuration, exécutées le 19 août 2026. Le bras fichier téléverse le CSV via l'API Files et utilise l'outil code_execution_20260120.
16. Mesure de la durée du cache : La tâche de triage de 20 tickets de Réduire les jetons d'entrée et de contexte, exécutée le 23 août 2026, sur Claude Sonnet 5 et Claude Opus 5 sur l'API Messages avec le même harnais, les cellules Claude Opus 5 avec max_tokens relevé à 4 096, avec des pauses insérées avant une part de tours choisie aléatoirement (aucune, 5 %, 10 % et chaque tour à 6 minutes sur les 20 tickets sur les deux modèles, plus chaque tour à 2 minutes sur Claude Sonnet 5 ; pauses de 20 minutes sur un sous-ensemble de 5 tickets sur les deux modèles ; pauses de 45 minutes sur un sous-ensemble de 5 tickets sur Claude Sonnet 5 uniquement). Trois exécutions par cellule, coût calculé à partir des champs usage de chaque réponse sur une organisation facturée comme un client aux prix catalogue, exactitude par rapport aux mêmes étiquettes de référence. Le point de croisement se situe à environ 3,3 % des tours sur les deux modèles : la médiane de la part d'équilibre de chaque session, calculée par le modèle de coût à partir des tailles de contexte tour par tour de cette session, sur l'ensemble des 45 sessions Claude Sonnet 5 et 36 sessions Claude Opus 5 de vingt tickets de l'analyse (chaque calendrier de pauses exécuté sur la tâche complète, sous les trois réglages de cache, trois exécutions chacun ; les cellules de 5 tickets n'en font pas partie). La cellule à 5 % a fait égalité sur Claude Sonnet 5 parce que les pauses de ce tirage sont tombées sur de petits préfixes. La règle de 1 sur 20 de la page se situe au-dessus du point de croisement mesuré. Anthropic a mesuré les requêtes de maintien en activité qui rafraîchissent le cache de 5 minutes uniquement à titre de comparaison. Elles ont au mieux égalé le réglage de 1 heure et coûté davantage avec une pause avant chaque tour, donc ne les utilisez pas sur ces deux modèles ; sur Claude Fable 5.1, l'arithmétique s'inverse (référence 19).
17. Part de lecture de cache en production : Utilisation agrégée de l'API Claude de première partie pour les 14 jours se terminant le 23 août 2026, produit API direct uniquement, organisations internes à Anthropic exclues, aucune organisation identifiée. Une journée-organisation compte comme une boucle d'agent lorsque ses requêtes comportent des définitions d'outils et des résultats d'outils, que ses prompts contiennent en moyenne 9 appels d'outils antérieurs ou plus, que la mise en cache a été utilisée et qu'elle a effectué au moins 10 requêtes de ce type (l'API n'a pas d'identifiant de conversation, ceci tient donc lieu de longueur de conversation) : 303 003 journées-organisations réparties sur 106 487 organisations, part médiane de lecture de cache de 84,2 % de tous les jetons d'entrée, quartile supérieur 91,7 %. Les étiquettes de cas d'usage (le cas d'usage déclaré de l'organisation, ou sinon son cas classifié) couvrent 74 % de ces journées-organisations et 99 % de leurs jetons ; les organisations de codage fournissent 87 % des jetons d'entrée agentiques et lisent une médiane de 88,5 % (90,9 % à 25 appels d'outils antérieurs ou plus), quartile supérieur 93,4 %, avec environ 72 % des journées-organisations de codage à 80 % ou plus ; les agents d'assistance, de recherche et de données lisent 84 % à 85 %. Le décile supérieur des journées-organisations lit 95,9 % ou plus pour le codage et 94,2 % à 94,8 % pour les agents d'assistance, de recherche, de données et autres. La répartition au niveau des requêtes à 25 appels d'outils antérieurs ou plus provient d'un échantillon de six heures : codage 92 % en lecture, 7 % en écriture, moins de 1 % sans cache. Les organisations non étiquetées, pour la plupart petites, lisent une médiane de 11 %. Les journées-organisations sans définitions d'outils lisent une médiane de 34,6 %. Une requête indépendante sur la même fenêtre qui reconstruit les conversations de 10 requêtes ou plus, plutôt que de noter les journées-organisations, place la médiane à 90,2 % ; la différence tient au périmètre, non aux données.
18. Mesure du moment de la compaction : La variante longue de l'agent de triage de Réduire les jetons d'entrée et de contexte, exécutée le 24 août 2026, sur Claude Sonnet 5 avec le cache de 5 minutes, coût issu des champs d'utilisation aux prix catalogue, cinq sessions par bras : un bras sans changement à l'effort par défaut tout au long (0,81 $ par session), et deux bras qui commencent à faible effort et effectuent les deux mêmes changements invalidant le cache, un passage à l'effort par défaut et un outil ajouté, soit en milieu de session aux requêtes 12 et 17 (0,95 $), soit ensemble sur la première requête après la première compaction (0,75 $). Un quatrième bras de six sessions, exécuté le 25 août 2026, a effectué les deux mêmes changements sur la requête qui a déclenché la première compaction (0,92 $ par session) : la passe de résumé de cette requête a écrit le contexte de 81 000 jetons dans le cache au lieu de le lire, de sorte que cette passe a coûté 0,21 $ contre 0,04 $ pour la même passe dans le bras à la frontière. Les sessions ont été compactées pour la première fois aux requêtes 21 à 25 (16 des 21 sessions à la requête 22), une fois que le prompt a dépassé le seuil de compaction de 80 000 jetons, et deux sessions sans changement ont été compactées une seconde fois vers la fin. Le total inférieur du bras à la frontière par rapport au bras sans changement reflète ses requêtes à faible effort avant le changement et ces secondes compactions plutôt que la mise en cache : les coûts de réécriture des deux bras diffèrent de moins d'un cent. Le bras en milieu de session a payé 0,23 $ par session en réécritures de cache ; la différence entre les bras en milieu de session et à la frontière était de 0,20 $ avec un intervalle de confiance à 95 % de 0,11 $ à 0,29 $. Une session en milieu de session a été peu coûteuse (0,82 $) après que son modèle a mal appelé l'outil de recherche à la suite de la compaction et obtenu des résultats vides ; elle est incluse, et sans elle le bras affiche une moyenne de 0,98 $. L'exactitude était en moyenne de 14,2 étiquettes sur 20 dans chaque bras du 24 août et de 14,7 dans le bras du 25 août ; les lectures de cache représentaient 91 % des jetons de prompt sans changement, 85 % en milieu de session, 91 % à la frontière et 86 % avec les changements sur la requête déclenchante.
19. Mesure de la durée du cache sur Claude Fable 5.1 : La même tâche de triage de 20 tickets et le même harnais que la référence 16, exécutés les 23 et 26 août 2026, sur l'instantané de lancement de Claude Fable 5.1 à ses prix de lancement (10 $ en entrée, 12,50 $ en écriture de 5 minutes, 20 $ en écriture de 1 heure, 0,25 $ en lecture de cache, 50 $ en sortie par million de jetons), trois réglages par calendrier : le cache de 5 minutes, le cache de 1 heure et le cache de 5 minutes maintenu chaud par une requête max_tokens: 0 sur le préfixe inchangé toutes les 4 minutes d'inactivité (les exécutions du 23 août ont envoyé des pings avec max_tokens: 1 ; chaque ping du 26 août a rafraîchi le cache et n'a facturé aucune sortie). Calendriers : aucune pause, 10 % des tours et chaque tour à 6 minutes sur les 20 tickets, et pauses de 45 minutes sur le sous-ensemble de 5 tickets ; trois exécutions par cellule, coût calculé à partir des champs usage de chaque réponse aux prix catalogue, exactitude par rapport aux mêmes étiquettes de référence (12 à 17 étiquettes exactes sur 20). Moyennes par session le 26 août pour les réglages 5 minutes, 1 heure et maintien en activité : aucune pause 2,42 $, 3,09 $, 2,29 $ ; 10 % en pause 4,50 $, 2,96 $, 2,36 $ ; chaque tour 22,89 $, 3,01 $, 2,62 $ ; les cellules du 23 août concordent à 6 % près. Les chiffres à 45 minutes (1,68 $, 0,59 $ et 0,71 $ par session de 5 tickets) proviennent d'une réexécution propre le 26 août après qu'un incident de facturation du cache a gâché les premières cellules de ce jour ; les exécutions du 23 août ont donné 1,67 $, 0,58 $ et 0,70 $. Le point de croisement entre les réglages 5 minutes et 1 heure est de 3,1 % des tours, la même mesure que la référence 16.
20. Terminal-Bench 3 : les 74 tâches du benchmark public d'agents de terminal, exécutées sur Claude Managed Agents avec deux outils personnalisés, un shell et un éditeur de fichiers que le harnais d'évaluation exécute dans le propre conteneur de chaque tâche, à la place des outils intégrés de la plateforme, et par ailleurs aux réglages par défaut de la plateforme pour les comptes externes, deux exécutions par modèle à l'effort high, du 27 au 28 août 2026. Les scores sont des taux de réussite bruts sur les 148 tentatives par modèle ; les exécutions uniques varient de 5 à 11 points. Les coûts correspondent à ce qui serait facturé à un client aux prix catalogue, revalorisés requête par requête à partir des enregistrements d'utilisation des exécutions avec la durée de vie du cache de 5 minutes. Claude Opus 4.7 a terminé 11 de ses 148 tentatives à son plafond de sortie.

Prochaines étapes