Otimizando para custo e inteligência

Quando uma carga de trabalho passa do protótipo para a produção, o custo se torna uma restrição de design de primeira classe. O modelo mais capaz pode ser caro demais em escala, e o modelo mais barato pode ficar aquém em qualidade. Gerenciar bem o custo significa entender como cada alavanca de custo afeta a qualidade da saída, porque algumas alavancas são trocadas por qualidade e outras não. A Claude Platform dá a você controle direto sobre essa troca. Você escolhe o modelo, o nível de "effort" (esforço) e a arquitetura para cada requisição, o que permite posicionar uma carga de trabalho em quase qualquer ponto da fronteira custo-inteligência.

Custo e inteligência geralmente são representados como uma fronteira em que um compra o outro. O primeiro grupo de alavancas nesta página move uma carga de trabalho em direção a essa fronteira, cortando custo sem tocar na qualidade; apenas o segundo grupo se move ao longo dela:

As alavancas vêm em dois tipos:

• Ganhos gratuitos cortam gastos sem tocar na qualidade: "prompt caching" (cache de prompt), higiene de tokens, uma auditoria de prompt em relação ao modelo que você está executando, processamento em lote com 50% de desconto para trabalho que pode esperar até 24 horas, e limites de gastos do workspace como salvaguarda.
• Trade-offs (compensações) trocam custo por inteligência: escolha de modelo, esforço, limites de saída e orçamentos de tarefa, e arquiteturas multimodelo.

Cada alavanca vem com resultados medidos e a regra de quando ela compensa. Nas medições da Anthropic, o cache de prompt foi a maior alavanca por ampla margem: ele cortou o custo do loop de agente por um fator de 2,7 a 5,3 nos benchmarks deste guia e cortou a conta de um pequeno agente de triagem em 83%, ou 88% com o corte de entrada adicionado. As alavancas multimodelo são mais estreitas; um segundo modelo compensou em dois formatos, um conselheiro e um orquestrador.

Comece aqui

Associe sua situação a uma linha.

Esses resultados são internos da Anthropic (Benchmarks referenciados) e direcionais, não garantias, então meça na sua própria carga de trabalho com o método de quatro etapas.

Corte gastos sem perder qualidade

Cache de prompt, higiene de tokens, processamento em lote e uma auditoria de prompt em relação ao seu modelo atual reduzem o que você paga sem reduzir a qualidade da saída. Duas ressalvas se aplicam: o processamento em lote troca latência pelo seu desconto, e a edição de contexto, uma alavanca de higiene de tokens, custou mais do que economizou na execução medida nesta seção.

Armazene contexto repetido em cache

Por que o cache vem primeiro

Ative o cache de prompt antes de qualquer outra alavanca, porque cada turno de uma tarefa agêntica reenvia toda a conversa crescente: prompt do sistema, definições de ferramentas e cada turno anterior. Uma tarefa de 40 turnos envia seu primeiro turno 40 vezes, então o custo da tarefa cresce aproximadamente com o quadrado do número de turnos. O cache não impede o reenvio, mas cada reenvio custa cerca de um décimo e é processado mais rápido: o prefixo é cobrado na taxa de leitura de cache, um décimo do preço de entrada, e cada turno paga a taxa de escrita de cache de 1,25x apenas pelo que é novo.

Como é um bom resultado. Ao longo de um dia inteiro de tráfego real, os loops de agente leram uma mediana de 84% de sua entrada do cache, e os 10% melhores "harnesses" (estruturas de execução), de codificação ou não, leram 94% ou mais¹⁷. No meio de uma tarefa, um loop bem construído paga preço cheio em menos de 1% de sua entrada. Abaixo de cerca de 80%, procure algo que esteja quebrando o cache (consulte O que quebra o cache).

Nas execuções medidas pela Anthropic, as leituras de cache são rotineiramente o maior componente individual do custo da tarefa, tornando o cache mais valioso do que a maioria das decisões de escolha de modelo. A Anthropic precificou as execuções do DeepResearch Bench II⁷ com e sem cache:

O tempo de vida padrão do cache é de 5 minutos e os turnos de um loop de agente têm segundos de intervalo, então o desconto se aplica à maioria dos tokens em cada turno. As execuções do gráfico de cache leram de 79% a 90% de seus tokens de entrada do cache. A economia varia com a profundidade do episódio, porque loops mais curtos releem menos, mas o cache permaneceu a maior alavanca individual em todos os modelos e benchmarks medidos.

Escolha a duração do cache

Se o seu loop espera por uma pessoa entre os turnos, use a duração de cache de 1 hora. Ela custa mais para escrever (2x o preço de entrada em vez de 1,25x). Uma falha de cache em qualquer das durações cobra o prefixo inteiro pelo preço de escrita em vez do preço de leitura, então a duração mais longa compensa quando alguns turnos por sessão seguem uma pausa entre 5 minutos e uma hora.

Para decidir, conte os intervalos entre requisições consecutivas em uma conversa:

• Mais de cerca de 1 intervalo em 20 fica entre 5 minutos e uma hora, e intervalos acima de uma hora são raros: use a duração de 1 hora.
• Os turnos chegam com segundos de intervalo: fique no padrão de 5 minutos. Quando nada pausou, ele custou 15% menos que a configuração de 1 hora no Claude Sonnet 5 e 11% menos no Claude Opus 5.
• Intervalos acima de uma hora são comuns: fique no padrão. Um intervalo acima de uma hora expira ambas as durações, e a configuração de 1 hora então reescreve o prefixo pelo seu preço de escrita mais alto, então ela perde em cada um desses intervalos. Das suas pausas maiores que 5 minutos, se cerca de 60% ou mais também passarem de uma hora, fique no padrão; a duração de 1 hora compensa apenas quando pelo menos cerca de 40% das pausas longas terminam dentro da hora.

A Anthropic mediu o trabalho de triagem de Corte tokens de entrada e de contexto com pausas inseridas antes de alguns turnos para simular o atraso de uma pessoa¹⁶. Em ambos os modelos medidos, o cache de 1 hora se tornou a configuração mais barata quando cerca de 1 turno em 30 seguia uma pausa, então a regra de 1 em 20 deixa uma margem, e a diferença aumenta rapidamente após o ponto de cruzamento porque cada turno pausado na configuração de 5 minutos reescreve o prefixo inteiro. Todos os modelos atuais usam os mesmos multiplicadores de escrita de cache, e todos os modelos exceto o Claude Fable 5.1 e o Claude Mythos 5.1 usam o mesmo preço de leitura, então o ponto de cruzamento fica na mesma faixa nos outros modelos; o Fable 5.1 é o caso abordado a seguir. A precisão ficou dentro do ruído entre execuções em todas as células. O turno após uma pausa manteve sua latência de cache aquecido na configuração de 1 hora. O gráfico a seguir plota o custo por sessão em relação à parcela de turnos pausados no Claude Sonnet 5:

A Anthropic também mediu requisições extras que mantêm o cache de 5 minutos aquecido. No Claude Sonnet 5 e no Claude Opus 5, elas não economizaram nada mensurável em relação à duração de 1 hora em nenhuma parcela de turnos pausados e custaram mais com uma pausa antes de cada turno, então use a duração em vez disso.

No Claude Fable 5.1, a configuração mais barata é outra. Sua leitura de cache custa 0,025x o preço de entrada ($0,25 por milhão de tokens), enquanto suas escritas de cache mantêm os multiplicadores padrão, então uma requisição de keep-alive que relê o prefixo é barata e o prêmio de escrita da duração de 1 hora é a conta maior. A Anthropic mediu o trabalho de triagem no Claude Fable 5.1 com as mesmas três configurações¹⁹. Manter o cache de 5 minutos aquecido custou de 13% a 20% menos por sessão do que o cache de 1 hora sempre que as pausas duravam minutos; apenas com pausas próximas de 45 minutos o cache de 1 hora venceu, por cerca de 12 centavos por sessão. No Claude Fable 5.1, mantenha o cache de 5 minutos aquecido enquanto uma pessoa estiver ausente por minutos, e compre a duração de 1 hora quando as pausas se aproximarem de uma hora:

Para manter o cache aquecido, envie a requisição anterior novamente com max_tokens definido como 0 dentro de 4 minutos do início da requisição anterior, e a cada 4 minutos depois disso, removendo stream se estiver definido. Conte a partir do início da requisição, não do fim de sua resposta: o tempo de vida de 5 minutos do cache corre a partir do início da requisição que escreveu ou atualizou a entrada, então o tempo que a resposta passou gerando conta contra ele. Essa é a requisição de pré-aquecimento: ela atualiza o tempo de vida do cache, não gera nada e cobra apenas a leitura de cache. Não altere um byte do prefixo, e não use max_tokens: 1, que amostra um token sem motivo. Reenvie os cabeçalhos da requisição assim como seu corpo: se suas requisições carregam um cabeçalho anthropic-beta (para um orçamento de tarefa, por exemplo), a requisição de keep-alive precisa do mesmo cabeçalho, ou os campos restritos a beta no corpo reenviado são rejeitados. Uma requisição max_tokens: 0 é rejeitada quando a requisição define thinking.type: "enabled" (o pensamento adaptativo padrão no Claude Fable 5.1 funciona), saídas estruturadas ou uma escolha de ferramenta forçada (suas limitações); nessas cargas de trabalho, compre a duração de 1 hora em vez disso.

# Dentro de 4 minutos do início da última requisição (o tempo gasto gerando conta
# contra a vida útil do cache), reenvie essa requisição com max_tokens definido como
# 0, removendo stream (uma requisição com max_tokens: 0 não pode usar streaming). Envie os mesmos
# cabeçalhos da requisição original, incluindo qualquer cabeçalho 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 @-

Ative o cache

A configuração dá pouco trabalho. O cache automático posiciona os pontos de interrupção para você; caso contrário, a skill Claude API que acompanha o Claude Code pode adicionar cache a uma integração existente a partir de um único prompt. O trecho a seguir mostra a skill adicionando-o ao harness que produziu essas medições:

$ 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.
...

Esses posicionamentos de pontos de interrupção seguem o padrão descrito em Pontos de interrupção de cache explícitos.

O que quebra o cache

Várias coisas podem quebrar seu cache durante uma tarefa. Qualquer coisa que mude por requisição, como um timestamp ou uma posição na fila, colocada antes do prefixo estável transforma cada requisição em uma escrita de cache completa: na execução de triagem em Corte tokens de entrada e de contexto, uma linha de status de 25 tokens no início do prompt do sistema custou $4,24 por execução em vez de $0,59, mais do que executar com o cache desativado. Mantenha o texto por requisição no turno de usuário mais recente.

O cache é uma correspondência de prefixo exata em bytes sobre a requisição em ordem (ferramentas, depois prompt do sistema, depois mensagens), então uma mudança em qualquer lugar invalida tudo depois dela. Alterar effort ou a configuração de pensamento entre requisições invalida o cache daquele ponto em diante, e em alguns modelos também as ferramentas e o prompt do sistema antes dele; qualquer edição no prompt do sistema invalida o cache daquele ponto em diante; definir ou alterar um formato de saída invalida o cache para a conversa inteira; adicionar, remover ou reordenar uma definição de ferramenta invalida tudo. A página de cache de prompt lista esses casos, exceto o formato de saída, que saídas estruturadas cobre. Nos modelos mais recentes, altere instruções com uma mensagem do sistema no meio da conversa, uma mensagem {"role": "system"} anexada a messages, em vez de editar o campo system de nível superior: o prefixo em cache permanece intacto. Verifique essa página para saber quais modelos oferecem suporte. Nos modelos que oferecem suporte, uma mudança de esforço por mensagem também deixa o prefixo em cache intacto. O risco é maior no Claude Fable 5.1 e no Claude Mythos 5.1: uma quebra reescreve o prefixo a 1,25x o preço de entrada em vez de lê-lo a 0,025x, então em um prefixo de 100.000 tokens um turno quebrado custa $1,25 em vez de $0,03, 50 vezes a leitura, contra 12,5 vezes ($0,63 em vez de $0,05) no Claude Opus 5.

A Anthropic mediu isso nas sessões longas do agente de triagem¹⁸. Uma mudança de esforço e uma ferramenta adicionada feitas no meio da sessão reescreveram 39.000 e 60.000 tokens em cache, e essas sessões custaram $0,95 por sessão. As mesmas duas mudanças na primeira requisição após a compactação custaram $0,75, e na requisição que disparou a compactação $0,92, porque a passagem de sumarização da compactação então reprocessou o contexto de 81.000 tokens pelo preço de escrita de cache: essa passagem de sumarização custou $0,21, contra $0,04 quando as mesmas mudanças vieram uma requisição depois, com precisão dentro do ruído entre execuções em todos os braços:

Alterar um orçamento de tarefa no meio do caminho invalida qualquer prefixo em cache que contenha o valor do orçamento, então defina-o uma vez, na primeira requisição. Cada passagem de edição de contexto invalida o prefixo a partir do ponto que ela limpa e a próxima requisição paga para recolocar em cache tudo depois dele, então limpe em alguns lotes grandes em vez de muitos pequenos. No Claude Fable 5.1 e no Claude Mythos 5.1, cada um desses custa 50 vezes o preço de leitura por token, então eles importam mais ali. Faça toda mudança que invalida o cache em pausas naturais, depois confirme que as leituras de cache não caíram; se caíram, o diagnóstico de cache mostra onde o prefixo divergiu.

Corte tokens de entrada e de contexto

A maioria das requisições de agente carrega tokens que nunca influenciam a resposta. Cortá-los raramente custa qualidade de saída, embora nem toda alavanca aqui tenha economizado dinheiro quando medida. Dois lugares para procurar:

• Corte de entrada. A filtragem dinâmica na ferramenta de busca web mantém o conteúdo padronizado fora das páginas buscadas, o redimensionamento de imagens ajusta o tamanho das entradas de visão, e a busca de ferramentas com carregamento adiado carrega definições de ferramentas apenas quando necessário (medido mais adiante nesta seção). A chamada programática de ferramentas permite que o Claude execute várias chamadas de ferramentas a partir de código para que apenas o resultado filtrado entre no contexto; sua documentação relata 24% menos tokens de entrada em benchmarks de busca agêntica, com uma pontuação mais alta. Gerencie o contexto de ferramentas compara busca de ferramentas, chamada programática de ferramentas, cache de prompt e edição de contexto.
• Ciclo de vida do contexto. A edição de contexto limpa resultados de ferramentas obsoletos, e a compactação automática com seu limite impede que loops longos carreguem todo o seu histórico adiante.

As alavancas interagem com o cache e entre si, então julgue-as pelo efeito líquido, e use o diagnóstico de cache para confirmar que seu prefixo em cache sobrevive a cada mudança. A Anthropic as mediu em um agente de triagem de issues trabalhando em 20 relatórios de bugs reais com capturas de tela de um repositório público, e em uma variante mais longa do mesmo trabalho com 2,6 vezes os tokens. Com o cache ativado, o corte de entrada (redimensionamento de imagens e busca de ferramentas) tirou mais 26% da execução curta e 21% da longa.

Adie definições de ferramentas não utilizadas

Cada definição de ferramenta anexada a uma requisição é entrada em cada turno, e alguns servidores MCP somam centenas delas. A Anthropic executou o agente de triagem com suas próprias duas ferramentas mais um catálogo de definições de ferramentas reais de servidores MCP públicos, para um total de até 502 ferramentas, carregando todas elas ou marcando as extras com defer_loading atrás da busca de ferramentas:

Com todas as definições carregadas, o custo da execução quase dobrou conforme o catálogo cresceu, acompanhando os tokens de esquema em cada requisição. Com a busca de ferramentas, ele ficou estável em todos os tamanhos de catálogo, 45% menos com 502 ferramentas. A precisão foi de 15 a 18 de 20 em todas as células de qualquer forma, e o modelo nunca chamou uma ferramenta errada, então nessa escala o catálogo custa dinheiro, não correção. O mesmo vale para ferramentas que vêm pelo conector MCP: com um servidor MCP público do GitHub anexado, adiar seu conjunto de ferramentas (default_config: {defer_loading: true}) cortou a execução em 20% com a mesma precisão.

Mantenha arquivos de dados fora do prompt

Quando o modelo precisa computar sobre uma tabela, faça o upload dela com a Files API e deixe o modelo consultá-la com execução de código em vez de colá-la. A Anthropic fez 25 perguntas agregadas¹⁵ (somas, contagens filtradas, agrupamentos e um filtro de data) sobre um CSV público de 1.862 linhas, com as respostas computadas pelo pandas:

Colada no prompt, a tabela tem cerca de 91.000 tokens de entrada em cada requisição, e o Claude Sonnet 5 respondeu corretamente 6 de 25 perguntas. Enviada, com execução de código, ele respondeu todas as 25, e a execução custou cerca de um doze avos. O Claude Opus 5 mostrou o mesmo padrão.

Gerencie o ciclo de vida do contexto

As alavancas de contexto só compensam em uma sessão longa o suficiente para precisar delas:

Na execução de 20 issues elas não economizaram nada, e a edição de contexto custou 74% mais. Na execução longa, a poda economizou 39% e a compactação 32%, enquanto a edição de contexto não mudou nada. A poda são algumas linhas que você mesmo escreve: em cada limite de tarefa, substitua resultados de ferramentas grandes e obsoletos por um extrato de uma linha. Ela funciona bem com o cache porque as edições ficam na cauda da conversa, onde a próxima tarefa adiciona conteúdo novo de qualquer forma: 89% de leituras de cache na primeira requisição após um limite e 81% nas requisições entre limites. Na execução inteira, a poda e a edição de contexto funcionam com o cache aproximadamente igualmente bem. A poda é mais barata porque a edição de contexto reescreve no meio da tarefa conteúdo que a poda exclui (cerca de dois terços da diferença) e porque ela mantém o contexto com cerca de metade do tamanho (o outro terço). Se você usar edição de contexto, limpe em alguns lotes grandes. A poda, adaptada do harness:

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
            # limita resultados de linha única para manter o extrato curto
            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

Coloque em lote o trabalho que pode esperar

A Batch API tira 50% de cada token de uma requisição, incluindo os em cache, em troca de os resultados chegarem a qualquer momento dentro de 24 horas. Encaminhe por um lote toda requisição pela qual ninguém está esperando, e mantenha o caminho interativo para o restante. O processamento em lote é a segunda maior alavanca gratuita depois do cache para trabalho de agente não supervisionado: execuções de avaliação, preenchimentos retroativos e trabalhos agendados, como uma execução recorrente do agente de triagem de issues da medição de corte de tokens. Ele se combina com tudo nesta página exceto interatividade, mas não está disponível para sessões do Claude Managed Agents, que são interativas por design (consulte preços do Claude Managed Agents).

Audite prompts em relação ao modelo atual

Cada geração de modelo responde a prompts de forma diferente, então um prompt acumula texto escrito para um modelo que você não usa mais. O caso usual é instrução excessivamente específica adicionada para compensar um modelo mais antigo: "verifique duas vezes", "seja maximamente minucioso", um procedimento passo a passo obrigatório ou um rascunho de raciocínio feito à mão. Um modelo mais novo segue isso ao pé da letra, produzindo rodadas extras de ferramentas e escrita extra, então a conta sobe sem ganho em precisão. Auditar prompts em relação ao modelo que você executa agora, e novamente sempre que trocar de modelo, é um ganho gratuito.

A auditoria é um único comando. A skill Claude API que acompanha o Claude Code tem um comando prompt-audit que lê os prompts e o código de requisição de um projeto e relata o que foi escrito para um modelo diferente. Este trecho resumido mostra ele sendo executado em um prompt de central de suporte e código de requisição contendo esses padrões:

$ 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.

O comando então propõe suas edições como um diff (um trecho mostrado) e lista o que deliberadamente deixou intacto: a janela de reembolso, o requisito de tom e o padrão de qualidade. Você revisa um patch, não uma reescrita.

O efeito é mensurável. Em uma avaliação de central de suporte¹⁴, prompts escritos para o Claude Opus 4.8 custaram 36% mais por ticket no Claude Opus 5 sem mudança na precisão. Executar a auditoria sobre os mesmos prompts tornou o Opus 5 tanto mais barato que a versão não auditada (em 14%) quanto mais preciso (97% dos tickets, acima de 92%, um ganho fora do ruído). Na migração do Claude Sonnet 4.6 para o Claude Sonnet 5, a auditoria tirou 14% com a mesma precisão:

Os dois tipos de texto obsoleto têm custos diferentes. Instruções que o modelo novo segue literalmente demais custam dinheiro: remover "verifique duas vezes" cortou o custo por ticket do Opus 5 em um terço, e remover "seja maximamente minucioso" quase tanto. Texto que não se encaixa mais no modelo custa precisão em vez disso: uma configuração de pensamento desativada, regras contraditórias e um rascunho feito à mão que conflita com o próprio pensamento do modelo restauraram cada um de 7 a 11 pontos no Opus 5 quando removidos:

Os mesmos padrões tendem a aparecer em descrições de ferramentas e skills, que também vale a pena auditar.

Troque custo por inteligência

Essas alavancas definem onde um único modelo fica entre custo e inteligência: escolha de modelo, esforço, reexecução de falhas em uma configuração mais alta, e os orçamentos e limites dentro dos quais ele trabalha. Comece com uma varredura de esforço no seu modelo atual (Ajuste o esforço). Do menor para o maior custo e capacidade, os modelos atuais são Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5 e Claude Fable 5.1 (o modelo de fronteira); a Visão geral dos modelos tem a linha completa e os preços.

Compare modelos pelo custo por tarefa

As listas de preços são escritas por token, e por token o modelo de fronteira parece caro: o preço por token do Claude Fable 5.1 é várias vezes o do Claude Sonnet 5. Você paga por tarefas concluídas, porém, então compare modelos pelo custo por tarefa concluída. Um modelo mais capaz termina uma tarefa com menos trabalho: menos turnos, menos busca, menos releitura de seu próprio contexto e menos retrocesso. O prêmio por token é frequentemente superado por fazer menos de tudo.

A Anthropic mediu isso no subconjunto do SWE-bench Pro³, precificado como um cliente é cobrado:

O Claude Fable 5.1 com esforço low resolveu 88,6% das tarefas por $0,54 por tarefa resolvida, contra 77,4% por $0,84 do Claude Sonnet 5 em seu padrão: 11 pontos a mais por 35% menos por tarefa resolvida, apesar de um preço por token cinco vezes maior. Ele nem sempre vence, porém. No mesmo subconjunto, que ambos os modelos em grande parte saturam e cujas pontuações não são comparáveis ao ranking público, o Claude Opus 5 sozinho igualou o Claude Fable 5.1 sozinho no padrão (91,7% comparado com 92,1%, dentro do ruído entre execuções) a cerca de 15% menos por tarefa resolvida ($1,01 contra $1,19), e o Opus 5 em low resolveu 84,0% por $0,25. E em loops longos de pesquisa o modelo de fronteira faz mais trabalho, não menos: no DeepResearch Bench II⁷, o Fable 5.1 em low pontuou 10 pontos acima do Sonnet 5 (66% contra 56%) a cerca de quatro vezes o custo por tarefa ($4,66 contra $1,20), porque ele executa um loop de pesquisa mais longo sobre um contexto maior. O Claude Opus 5 em seu padrão pontuou 71% na mesma base por $6,71 por tarefa, acima do Fable 5.1 em seu padrão (65% por $7,12), então em pesquisa também o Fable 5.1 justifica seu preço apenas em low.

Para a maioria das cargas de trabalho de agente, comece com o Claude Fable 5.1 com esforço low e aumente o esforço onde ele falhar. Por token ele custa o dobro do Claude Opus 5 em entrada não armazenada em cache, mas metade em entrada em cache ($0,25 contra $0,50 por milhão), e em um loop de agente a entrada em cache é o maior termo. No benchmark de codificação em Estratégia de conselheiro, o Fable 5.1 em medium igualou o Opus 5 em seu padrão por cerca de um terço do custo por tentativa ($2,91 contra $8,50). No Chartography¹³, um benchmark de leitura de gráficos, o Fable 5.1 em low pontuou 62,5 por $0,15 por gráfico, comparado com 49 por $0,38 do Opus 5 em low. No subconjunto do SWE-bench Pro, o Claude Opus 5 em seu padrão continua sendo o caminho mais barato para a pontuação máxima, como observado anteriormente. Na outra ponta, o Claude Haiku 4.5 respondeu perguntas do GPQA Diamond⁹ a cerca de um décimo do custo por pergunta do Opus 5, com 63% de precisão comparado com 92% do Opus, e ficou muito mais atrás em tarefas longas de codificação. Ele se encaixa em trabalho de alto volume com saídas verificáveis, não em loops agênticos longos.

A classificação se inverte conforme a carga de trabalho, e nenhuma lista de preços diz para qual lado. Precifique cada candidato em custo por tarefa concluída no seu próprio tráfego, incluindo o Claude Opus 5 e o modelo de fronteira com esforço reduzido.

Precifique a cauda da sua carga de trabalho, não a mediana: compare modelos no décimo mais difícil das suas tarefas, não na típica. Na tarefa típica todo modelo parece semelhante e o mais barato parece o melhor, mas a conta é decidida pelas tarefas em que o modelo mais barato falha, porque uma tarefa que falhou ainda cobra seus tokens, depois a nova tentativa, depois o que quer que a falha custe adiante. A cauda também é para onde o dinheiro vai mesmo quando nada falha. Em uma execução de 20 problemas do WideSearch¹, dois problemas carregaram 43% do gasto:

As estratégias multimodelo existem para gastar inteligência de fronteira nessa cauda sem pagar taxas de fronteira pelo restante.

Atualize o modelo

Se você está um ou dois modelos atrás, a alavanca mais barata é a string do modelo. A Anthropic executou modelos recentes do Claude Opus, Claude Sonnet e Claude Fable pelo mesmo harness no subconjunto do SWE-bench Pro³, cada um em seus padrões de fábrica e precificado pelas taxas de tabela, e executou a linha Opus novamente no Terminal-Bench 3²⁰:

A Anthropic precifica a linha Opus de forma idêntica por token entre versões, então qualquer diferença vem de quanto trabalho cada modelo faz por tarefa: precificado como um cliente é cobrado, o Claude Opus 4.8 resolve a mesma parcela de tarefas que o Claude Opus 4.7 por 14% menos por tarefa resolvida, e o Claude Opus 5 então resolve 12 pontos a mais de tarefas a 21% mais por tarefa resolvida. O Claude Opus 5 com esforço low supera o padrão do Opus 4.8 neste benchmark por cerca de 30% de seu custo por tarefa resolvida, então a atualização mais barata é o modelo novo em uma configuração mais baixa. A economia do Sonnet 5 vem de seu preço por token mais baixo, que mais do que compensa os tokens extras que ele usa por tarefa em comparação com o Sonnet 4.6: 15% menos por tarefa resolvida por 5 pontos a mais. O nível de fronteira ganhou da mesma forma: o Claude Fable 5.1 iguala a pontuação do Claude Fable 5 por 43% menos por tarefa resolvida, a maior parte disso pelo preço de leitura de cache mais baixo. Essa direção não é garantida: no DeepResearch Bench II⁷ a mesma atualização custa 41% mais por tarefa em high (79% mais em low) por seus 2 a 3 pontos extras nas tarefas limpas em todos os braços (referência 7), porque o modelo novo faz mais trabalho por tarefa ali. Os preços de entrada e saída são os mesmos e a leitura de cache é 4x mais barata, então meça a atualização na sua própria carga de trabalho antes de presumir que ela economiza.

Em trabalho mais difícil a diferença aumenta. No Terminal-Bench 3²⁰, onde as tarefas são difíceis o suficiente para que a taxa de aprovação, e não os tokens, defina a conta, o Claude Opus 4.7, o Opus 4.8 e o Opus 5 gastam cada um de $8 a $15 por tarefa, mas resolvem 7%, 15% e 41% das tarefas, então o custo por tarefa resolvida cai de $183 para $63 para $28 subindo a escada. O prêmio de 21% que o Claude Opus 5 carrega sobre o Opus 4.8 no subconjunto de codificação saturado se torna uma economia de 56% no Terminal-Bench 3, onde o modelo mais antigo falha na maior parte: quanto mais sua carga de trabalho derrota o modelo antigo, mais a atualização economiza por resultado.

Compare pelo custo por tarefa resolvida, não por token: o mesmo texto custa cerca de 30% mais tokens no Claude Opus 4.7 e posteriores, então uma comparação por token faz os modelos mais novos parecerem mais caros por construção.

Ajuste o esforço

O esforço é a maneira mais direta de ajustar um modelo à sua tarefa. O parâmetro effort governa quanto pensamento, chamadas de ferramentas e autoverificação o modelo faz, e o padrão (high) é adequado para tarefas exigentes. O custo escala com toda essa atividade; a precisão escala apenas com a parte de que sua tarefa precisa. Abaixo do teto do modelo, os níveis de esforço mais altos pagam por uma profundidade que a tarefa nunca usa.

Nos benchmarks de pesquisa e trabalho de conhecimento (WideSearch¹, DeepWideSearch⁶, BrowseComp⁴ e GDPval², todos com Claude Fable 5), a curva de precisão em relação ao custo é quase plana: low abriu mão de 1 a 3 pontos por um terço a metade de desconto no custo por tarefa, medium igualou a precisão do padrão a cerca de 70% a 87% do seu custo, e o padrão não comprou nada mensurável acima de medium em nenhum dos quatro. No DeepWideSearch, low também igualou um orquestrador com um worker Claude Sonnet 5 a um custo 29% menor: reduzir o esforço superou uma mudança de arquitetura.

Configurações de esforço mais baixas costumam ser mais rápidas, o que importa quando a "latency" (latência) é a restrição. Nessas execuções, low levou 4,5 minutos por problema no DeepWideSearch, em comparação com 7,9 minutos no padrão. No benchmark de corpus, cuja entrada não cabe em nenhuma "context window" (janela de contexto) única, o Fable 5.1 levou 15,2, 17,5 e 19,9 horas por episódio em low, medium e high.

A codificação de longo horizonte é onde o esforço genuinamente compra precisão. No SWE-bench Pro³, o Claude Opus 5 abriu mão de cerca de 2 pontos em medium pela metade do custo e de cerca de 8 pontos em low por um quarto dele: um tradeoff real, que reexecutar falhas com esforço mais alto transforma de volta em economia. Este gráfico plota a precisão em relação ao custo para os benchmarks de pesquisa e trabalho de conhecimento e para o SWE-bench Pro:

Duas consequências se seguem. Primeiro, desenhe essa curva para sua própria carga de trabalho antes de adicionar um segundo modelo: nessas medições internas, uma configuração multimodelo que parecia mais barata do que o modelo único padrão custou mais do que esse mesmo modelo com esforço mais baixo. Segundo, essa curva é a linha de base de modelo único que qualquer estratégia multimodelo precisa superar, então o passo 2 de medir na sua própria carga de trabalho estabelece linhas de base em todos os níveis de esforço.

Trabalho difícil não precisa automaticamente de esforço alto. No DeepResearch Bench II⁷, o Claude Fable 5.1 pontuou quase o mesmo em low, medium e high enquanto o custo por tarefa subiu de $4,66 para $7,12, então aumentar o esforço nesse caso não aumenta a qualidade da saída de forma perceptível; nas 21 tarefas limpas em todos os braços (referência 7), o Claude Fable 5 também ficou plano em todos os níveis de esforço, embora a base de 33 tarefas do gráfico, que descarta as tentativas interrompidas de cada modelo, o mostre subindo. Meça a curva no modelo que você coloca em produção, não no que você mediu por último:

A descrição da tarefa por si só não revela que tipo de carga de trabalho você tem, então varra dois ou três níveis de esforço em uma amostra do seu próprio tráfego e leia a resposta na curva. Teste cada nível em uma sessão separada: mudar o esforço de nível superior no meio da sessão invalida o cache (consulte Faça cache de contexto repetido) e distorce a comparação. Para detalhes do parâmetro, consulte Esforço.

Reexecute falhas com esforço mais alto

Quando o resultado de uma tarefa é verificável, a política mais barata na curva de esforço não é uma configuração fixa: execute todas as tarefas em uma configuração baixa e reexecute apenas as falhas em uma mais alta.

A Anthropic calculou essa política tarefa por tarefa a partir das execuções de esforço no subconjunto do SWE-bench Pro³ em Ajuste o esforço. Com o Claude Opus 5 em low, 16% das tarefas falharam; com essas reexecutadas no padrão, cerca de 93% passaram por cerca de $0,45 cada, contra 91,7% por $0,93 executando tudo no padrão: a mesma taxa de aprovação pela metade do custo, contando as tentativas baratas que falharam. Começar em medium em vez disso resolveu cerca de 94% por cerca de $0,61. A maior parte do pequeno ganho é a segunda tentativa (reexecutar as próprias falhas do padrão no padrão pontua aproximadamente o mesmo, por mais dinheiro), então use essa política pela economia, não pelo ganho:

Duas condições se aplicam. Primeiro, você precisa de um sinal de falha (aqui, os próprios testes do benchmark); um verificador que aprova trabalho ruim deixa essas falhas passarem. Segundo, cada falha de primeira passagem leva o tempo de relógio de duas execuções, então a economia é paga em latência nas falhas.

Defina orçamentos e limites de saída

A maioria das execuções de tarefas agênticas é barata, mas uma minoria gasta muitas vezes o custo mediano em buscas, reverificações e testes excessivos. Um orçamento de tarefa mira essa cauda. O modelo vê uma contagem regressiva de tokens ao vivo para a tarefa inteira e se autorregula, cortando buscas de baixo valor, pulando verificações redundantes e concluindo em vez de entrar em espiral.

A Anthropic mediu a taxa de aprovação e o custo por tarefa no SWE-bench Pro³ com o Claude Fable 5.1 à medida que o orçamento apertava:

Um orçamento generoso cortou o custo por tarefa em 44% por cerca de 3 pontos de taxa de aprovação, no limite do ruído entre execuções, e o orçamento mais apertado permitido cortou-o em 58% por 6 pontos. Os orçamentos compraram eficiência aqui, a um preço em taxa de aprovação que cresce à medida que o orçamento aperta.

Três controles fazem três trabalhos diferentes. Um orçamento de tarefa economiza dinheiro, porque o modelo o vê. max_tokens é um limite de segurança: reduzi-lo cortou o custo por tentativa sem reduzir o custo por tarefa resolvida. No Claude Managed Agents, um orçamento de sessão é a parada rígida em dólares por trás de ambos. Defina os três: um orçamento de tarefa, um max_tokens alto e um limite de sessão para a execução que você nunca quer ver em uma fatura, com um limite de gastos do workspace como a proteção final.

• Orçamentos de tarefa estão em beta (cabeçalho beta task-budgets-2026-03-13) nos modelos mais recentes; verifique a tabela de suporte para saber quais. Comece perto do uso de tokens do 90º percentil do seu loop e depois aperte (Escolhendo um orçamento mostra como coletar essa distribuição). Orçamentos abaixo do piso atual de 20.000 tokens são rejeitados, e orçamentos muito apertados podem produzir comportamento semelhante a recusa. Defina o orçamento uma vez, na primeira requisição, porque uma mudança no meio da tarefa invalida o cache. O orçamento é consultivo, direcionando o modelo em vez de pará-lo, então verifique a aderência na sua carga de trabalho.
• max_tokens limita uma única resposta, de forma invisível para o modelo, então reduzi-lo não faz o modelo economizar. Os turnos que precisavam do espaço são descartados e ainda assim cobrados. Em um benchmark interno de tarefas de repositório¹², um limite de 16.384 tokens encerrou 15% das tentativas do Claude Opus 5 e 43% das do Claude Fable 5.1 no esforço padrão, e apenas 9 das 117 tentativas limitadas do Fable ainda passaram. Execuções limitadas gastaram menos por tentativa, mas compraram proporcionalmente menos soluções, então o custo por tarefa resolvida foi aproximadamente o mesmo que em 64.000 ($21 contra $22). Em 64.000, 2 de cerca de 14.000 turnos no esforço padrão ainda foram cortados, e o Fable 5.1 resolveu 58,5% das tarefas em vez de 36,3% (em um corte separado do subconjunto do SWE-bench Pro³, descrito na referência 12, nenhuma diferença: 94 de 100 em qualquer dos limites). Tentar novamente tentativas limitadas raramente ajuda: no mesmo limite a maioria delas falha novamente, e em um mais alto você também paga pela tentativa desperdiçada. Defina max_tokens como 64.000 para trabalho agêntico, ou como 128.000, o máximo, quando uma única tentativa cortada é custosa; em 128.000 o Fable 5.1 resolveu 60,0% pelo mesmo custo por tarefa resolvida. Faça streaming de respostas desse tamanho, trate stop_reason: max_tokens como uma falha e economize dinheiro com esforço e orçamentos de tarefa, que o modelo pode ver.
• Orçamentos de sessão no Claude Managed Agents são a parada rígida. Um orçamento de sessão é um limite em dólares para uma sessão a preços de tabela para tokens, buscas e tempo de sessão. No limite, a sessão pausa com stop_reason: budget_reached; aumentar o orçamento a retoma. Ele é aplicado pela plataforma, funciona em qualquer modelo com preço de tabela, incluindo modelos em que orçamentos de tarefa ainda não estão disponíveis, e se combina com o orçamento de tarefa consultivo. Deployments aplicam o mesmo campo a cada execução.

Peça respostas mais curtas. Tokens de saída custam cinco vezes os tokens de entrada no Claude Sonnet 5, e em um loop de agente cada token que o modelo escreve volta como entrada em cada turno posterior, então você paga por uma resposta longa de novo e de novo. A Anthropic executou o trabalho de triagem sob três instruções de resposta final, três execuções cada, com o mesmo modelo e ferramentas. A original pedia duas linhas:

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>

A variante mais curta pedia uma:

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.

A variante mais longa pedia um memorando com cinco seções com cabeçalho: resumo do problema, evidências, verificação de duplicatas, rótulo recomendado e próximos passos. Para uma issue, um prompt enfileirado que nunca é enviado após uma pergunta pulada, as duas primeiras respostas foram:

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.

A resposta de uma linha usou 39% menos tokens de saída do que a original de duas linhas e custou 14% menos por execução. O memorando usou seis vezes os tokens de saída e custou 2,8 vezes a resposta de uma linha. Todas as três pontuaram dentro do ruído entre execuções umas das outras em relação aos rótulos de referência, então os formatos diferem muito mais no que você paga do que no que acertam. Peça a resposta que você vai ler, não a que parece minuciosa.

No limite de max_tokens mais baixo, ambos os modelos gastam menos por tentativa, mas resolvem proporcionalmente menos tarefas, então o custo por tarefa resolvida quase não se move:

Quase todos os turnos terminam muito abaixo de qualquer dos limites. O raro turno longo é o que o limite mais alto compra:

Combine modelos

Arquiteturas multimodelo se adequam a cargas de trabalho cuja complexidade de tarefa varia o suficiente para que diferentes etapas sejam melhor atendidas por diferentes modelos. Quando seu tráfego mistura trabalho rotineiro que um modelo menor lida de forma confiável com etapas mais difíceis que precisam de capacidade de fronteira, dividir o trabalho mantém a inteligência de fronteira onde ela importa enquanto a maioria dos tokens é cobrada a taxas de modelo menor. Quando uma carga de trabalho não tem essa mistura, porque sua dificuldade é uniforme ou é uma única cadeia dependente, um único modelo bem ajustado geralmente é a melhor escolha. Cada seção de estratégia dá a regra para distinguir os dois casos.

Duas estratégias cobrem a maioria das cargas de trabalho, e elas diferem em qual modelo mantém o loop principal:

Estratégia advisor: escale decisões difíceis

Na estratégia advisor, um modelo executor de menor custo executa o loop do agente e realiza a maioria dos turnos. Quando ele encontra uma decisão que precisa de julgamento mais profundo, como escolher uma abordagem ou se recuperar de uma falha, ele chama um modelo advisor de maior inteligência para orientação estratégica e depois continua. A maioria dos tokens é cobrada a taxas do executor, e apenas as consultas ocasionais a taxas do advisor.

Para usá-la, adicione a ferramenta advisor à sua requisição. Esse recurso beta executa toda a estratégia no lado do servidor em uma única requisição /v1/messages: o executor emite uma chamada de ferramenta, a Anthropic executa a inferência do advisor e o executor continua com o conselho; você não escreve nenhum código de orquestração. No Claude Managed Agents, dê à sessão um advisor adicionando uma entrada advisor à lista multiagent do agente; a thread principal da sessão o consulta da mesma forma. O Claude Code também oferece suporte; consulte escalando decisões difíceis com a ferramenta advisor.

O que define o retorno. O advisor vê a tarefa apenas através das chamadas do executor, então duas coisas decidem o quanto ele ajuda.

A primeira é a lacuna entre os modelos. O advisor só pode entregar capacidade que o executor não tem: no GPQA Diamond⁹ um executor Claude Haiku 4.5 ganhou muito com um advisor Claude Opus 5, um executor Claude Sonnet 5 ganhou alguns pontos, e um executor de fronteira quase nada.

A segunda, e a frágil, é se o executor realmente pergunta (a taxa de consulta). Um executor com esforço baixo pode parar de detectar que está travado: um pareamento que consulta na maioria das tarefas no esforço padrão pode cair para consultar em quase nenhuma quando o esforço é reduzido, e então pontua abaixo do executor sozinho. A taxa também varia por tarefa: no DeepSWE¹⁰ um executor Sonnet 5 com esforço baixo continuou perguntando e ganhou 23 pontos; no SWE-bench Pro³ o mesmo executor parou. Quando o executor pergunta, ele recupera grande parte da lacuna. Entre os pareamentos no gráfico a seguir cujo executor continuou perguntando, o advisor fechou pelo menos metade da lacuna para o modelo mais forte (o pareamento de codificação superou o modelo mais forte diretamente), e você paga pelo modelo mais forte apenas nas consultas, que é o que torna os casos de custo possíveis:

A taxa de consulta responde ao prompting. Com apenas a descrição embutida da ferramenta, os executores chamam menos do que deveriam, especialmente em trabalho de codificação, então a documentação da ferramenta advisor fornece um "system prompt" (prompt do sistema) que pede uma chamada antes do trabalho substantivo e uma antes de terminar, cerca de duas a três chamadas por tarefa. O pareamento de codificação medido a seguir rodou nessa cadência, cerca de duas consultas em cada tarefa. Essa página também cobre como estimular um executor que chama pouco e como limitar chamadas no lado do cliente para conter o custo. Então observe a taxa de consulta: faça prompt para ela, meça-a e restaure o esforço do executor se ela colapsar.

Quando compensa em custo. Um advisor economiza dinheiro quando algumas consultas curtas, cobradas à taxa do advisor, substituem executar o modelo do advisor para a tarefa inteira. Isso funciona melhor quando o modelo do advisor tem preço bem acima do do executor, então a configuração mais econômica é um advisor de fronteira sobre um executor de nível intermediário. Um pareamento pode se sustentar mesmo no topo da faixa, porque o conselho também economiza tokens do executor: um executor informado da abordagem certa explora menos becos sem saída, o que pode cobrir as consultas.

Em um benchmark interno de codificação agêntica¹¹, executado com um agente de API simples, um executor Claude Opus 5 com um advisor Claude Fable 5.1 foi a configuração mais precisa medida, a $7,69 por tentativa. Ele fica acima da linha que passa pelas próprias configurações de esforço de cada modelo: 3,5 pontos acima do Opus 5 sozinho na configuração padrão por um pouco menos de dinheiro, uma lacuna que cinco tentativas por tarefa separam do ruído, e cerca de 2,5 pontos acima do modelo do advisor sozinho por cerca de metade a mais do dinheiro:

Uma medição anterior através do modo advisor do Claude Code produziu a mesma ordenação. Leia esse resultado como uma forma a testar na sua carga de trabalho: o advisor compra alguns pontos a aproximadamente o próprio preço do executor. Uma lacuna de capacidade maior não garante um negócio melhor. O custo de latência são as próprias consultas: cerca de duas chamadas extras de modelo de fronteira por tarefa nesse benchmark, cada uma no caminho crítico da tarefa.

Quando o modelo mais forte sozinho é o melhor passo. Onde a precisão de uma carga de trabalho responde ao esforço, compare o pareamento com o modelo do advisor sozinho em uma configuração reduzida antes de construí-lo: o advisor é pago apenas nas tarefas que precisam dele, mas uma consulta que dispara na maioria das tarefas custa mais do que executar o próprio modelo mais forte. No Chartography¹³ o mesmo pareamento igualou o Claude Fable 5.1 sozinho em medium dentro do ruído entre execuções (65,0 contra 67,5) a cerca de 2,6 vezes o custo por tarefa, porque o advisor foi consultado em quase todas as tarefas. Meça sua própria taxa de consulta primeiro: se o executor pergunta na maioria das suas tarefas, você está pagando taxas de advisor em toda a carga de trabalho, e executar o próprio modelo do advisor é o caminho mais barato para a mesma pontuação.

Qualquer que seja o pareamento, primeiro precifique o modelo do advisor sozinho com esforço baixo; essa é a linha de base a superar. Verifique novamente a cada lançamento de modelo, porque os lançamentos movem tanto a lacuna de capacidade quanto a razão de preço.

Quando se adequa. A estratégia advisor se adequa a cargas de trabalho em que os turnos são em sua maioria mecânicos, mas um plano excelente importa: agentes de codificação, uso de computador e pipelines de pesquisa de múltiplas etapas. Ela se adequa mal quando cada turno genuinamente precisa de capacidade de fronteira, quando não há nada a planejar (perguntas e respostas de turno único) ou quando seu executor já está próximo da capacidade do advisor.

Estratégia orquestrador: delegue trabalho em massa

Na estratégia orquestrador, o modelo de fronteira mantém o loop. Ele decompõe a tarefa, despacha subtarefas para modelos worker de menor custo e mescla seus resultados. A própria transcrição do orquestrador permanece curta porque os workers absorvem a exploração pesada em tokens, então a maioria dos tokens é cobrada a taxas de worker enquanto o plano e a síntese ainda vêm do modelo de fronteira.

Para construir um, use a orquestração multiagente no Claude Managed Agents: configure um agente coordenador (o orquestrador) e uma lista de agentes worker, cada um com seu próprio modelo. Para um exemplo funcional completo com um coordenador de fronteira e workers Claude Sonnet 5, consulte a receita do Claude Cookbook Coordinator pattern: big models for planning, small models for execution.

Esse padrão economiza tempo de relógio quando os workers podem rodar em paralelo: no benchmark de corpus⁸, um episódio levou cerca de 2,3 horas com o coordenador executando o limite documentado da plataforma de 25 workers simultâneos, em comparação com 15 a 20 horas sozinho. Ele economizou dinheiro em apenas duas situações medidas. Em trabalho que um único modelo poderia lidar sozinho, o mesmo modelo com esforço mais baixo foi mais barato todas as vezes.

Caso 1: seguro contra a cauda de custo em trabalho rotineiro. Um modelo de fronteira rodando sozinho ocasionalmente entra em espiral em um problema rotineiro que normalmente resolveria. Como você não consegue dizer com antecedência quais serão esses, algumas dessas execuções dominam a fatura. Um coordenador que entrega trabalho rotineiro a um worker de menor custo limita essa cauda, porque qualquer espiral agora acontece a taxas de worker.

A Anthropic mediu isso em uma fatia deliberadamente fácil do BrowseComp⁴ (10 problemas que o modelo sozinho resolve de forma confiável; 50 execuções delegadas e 70 sozinhas). Um coordenador Claude Fable 5 com um worker Claude Sonnet 5 custou cerca de metade do Claude Fable 5 sozinho em média e cerca de um terço no 90º percentil ($12 em comparação com $33), e a execução única mais cara do modelo sozinho, a $84, também estava errada:

A delegação compensou na parcela rotineira, normalmente solucionável, do trabalho, o oposto da intuição de que workers são para problemas difíceis. No conjunto completo e mais difícil do BrowseComp, a economia se inverteu. Se seu tráfego tem uma longa cauda de custo em tarefas rotineiras, esse é o caso de orquestrador a medir primeiro.

Caso 2: trabalho maior do que uma janela de contexto. Um modelo sozinho precisa trabalhar através de uma entrada desse tamanho serialmente, uma janela de contexto por vez, pagando para reler seu próprio estado a cada passagem. Os workers leem cada um sua própria partição, em paralelo e a taxas de worker. Trabalho pesado em leitura que ainda cabe em uma janela de contexto é um problema de escolha de modelo, não um problema de delegação: apenas no custo de leitura, o orquestrador sai na frente somente quando nenhum contexto único consegue conter o trabalho.

A Anthropic construiu um benchmark para esse caso⁸: um corpus de 21,6 milhões de tokens de 14 pacotes Python públicos com 130 defeitos plantados, grande demais para qualquer janela de contexto. Reduzir o esforço não pode ajudar, porque a fatura é a própria leitura do corpus: o Claude Fable 5.1 sozinho custou de $468 a $552 por episódio nas três configurações de esforço, e apenas sua precisão se moveu. A configuração de coordenador, um líder Claude Fable 5.1 sobre 25 workers Claude Sonnet 5, custou cerca de metade dessas configurações (47% a 55% menos) e pontuou 10 a 12 pontos abaixo delas, em cerca de 2,3 horas por episódio contra 15 a 20, enquanto superava diretamente uma linha de base do Claude Sonnet 5 sozinho:

A contabilidade de tokens mostra a escala da leitura: a configuração de coordenador leu cerca de 560 milhões de tokens em cache por episódio, cerca de uma vez e meia os aproximadamente 365 milhões do modelo sozinho, quase todos eles à taxa de leitura de cache do Claude Sonnet 5, e ainda assim custou cerca de metade no total. O Fable 5.1 em esforço high ainda mantém a precisão máxima, a cerca de 2,2 vezes o custo da configuração de coordenador, então a delegação aqui compra a maior parte da precisão, não toda ela.

Quando a delegação não compensa. Um orquestrador compra algo apenas quando há volume a entregar: muitas partes independentes, idealmente demais para uma janela de contexto. Quando o trabalho é uma única cadeia dependente, ou cabe em um único contexto, o orquestrador paga por um plano, uma entrega e uma mescla que um único modelo obtém de graça. Em todos esses casos medidos, o modelo do coordenador sozinho com esforço mais baixo saiu na frente.

A fronteira é a dificuldade da tarefa, não o benchmark: no conjunto completo e mais difícil do BrowseComp⁴, o Claude Fable 5 sozinho alcançou a precisão da configuração de coordenador a um custo 22% a 30% menor. Trabalho externo independente relata o mesmo padrão⁵. Se o trabalho é uma única cadeia, cabe em um contexto sem uma longa cauda de custo, ou um único modelo com esforço mais baixo já atende ao seu critério, não construa um orquestrador.

Escolha entre as estratégias

A maioria dos casos se resume a uma pergunta: o trabalho se divide em partes independentes, ou é uma única resposta alcançada através de uma cadeia de etapas dependentes? A tabela de estratégias mapeia as duas respostas para as duas estratégias.

Se você não tem certeza, não construa nada ainda:

1. Varra o esforço no seu modelo atual primeiro. É o experimento mais barato desta página, e a maioria das cargas de trabalho termina aí.
2. Se a varredura mostrar uma lacuna, precifique o modelo mais forte sozinho com esforço baixo. Esse é o número que um pareamento de advisor precisa superar, e os pareamentos nesta página que o superaram foram aqueles cujo executor realmente consultou.

Os resultados multimodelo nesta página foram julgados em relação ao mesmo modelo com esforço mais baixo e em relação ao próximo modelo abaixo rodando sozinho. Essa é a comparação a executar na sua própria carga de trabalho, e o motivo pelo qual o primeiro passo é uma varredura de esforço.

Quando você adiciona um advisor, é uma definição de ferramenta em vez de uma rearquitetura.

Meça na sua própria carga de trabalho

Os números nesta página refletem preços de tabela no momento da medição e vão se desviar à medida que modelos e preços mudam. Sua taxa de escalação, quão limpamente as tarefas se dividem e o comprimento da transcrição também os movem. O método permanece o mesmo:

1. Extraia algumas tarefas dos logs de produção, ponderadas como o tráfego real, e escreva verificações de resultado para cada uma: testes passam, ticket fechado, contagem de linhas correta. Registre o custo por tarefa ao lado da pontuação: precifique as cinco contagens de tokens precificadas no usage de cada resposta às suas próprias taxas (entrada sem cache, escritas de cache de 5 minutos e 1 hora a 1,25x e 2x o preço de entrada, leituras de cache e saída), somadas em todas as requisições da tarefa (a API de Uso e Custo relata o agregado).
2. Estabeleça a linha de base dos níveis de modelo em todos os níveis de esforço, não apenas no padrão, e plote a pontuação em relação ao gasto. Uma configuração multimodelo precisa superar a curva inteira do modelo único.
3. Se a curva mostrar uma lacuna que o esforço não consegue fechar, adicione a estratégia multimodelo que se adequa e reexecute a suíte.
4. Execute o vencedor em shadow em uma fatia de tráfego antes da migração, e depois mantenha a suíte rodando.

O exemplo a seguir calcula o custo do passo 1 de uma requisição aos preços de tabela do Claude Opus 5:

# Preços por milhão de tokens da página de preços; altere estes três para outro modelo.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
# 0,1x o preço de entrada; 0,025x no Claude Fable 5.1 e no 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
    # Gravações de cache de 1 hora cobram 2x o preço de entrada, de 5 minutos 1,25x; leituras ao preço de leitura de 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}")

Em loops de agente, o termo de leitura de cache geralmente é o maior dos cinco; se não for, verifique se o cache está ativado. Quando a ferramenta advisor ou a compactação está habilitada, alguns tokens são relatados apenas em usage.iterations e não nos totais de nível superior, então some sobre usage.iterations em vez disso, precificando as entradas advisor_message às taxas do modelo advisor.

A tabela a seguir lista as alavancas na ordem em que devem ser tentadas:

Benchmarks referenciados

Exceto quando uma referência indicar o contrário, as medições são execuções internas da Anthropic desses benchmarks. Salvo indicação em contrário, os custos estão em USD aos preços de tabela em vigor quando cada benchmark foi executado; os números do Claude Sonnet 5 usam $2 e $10 por milhão de tokens de entrada e saída. Gráficos rotulados como "notional USD" (USD nocional) precificam as contagens de tokens de cada requisição a essas taxas em vez de reportar faturas.

1. WideSearch: Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025. Tarefas amplas de pesquisa na web avaliadas pela completude e precisão de uma tabela de muitas linhas; 200 problemas, 3 execuções por configuração, executadas de 1 a 2 de agosto de 2026. O gráfico de concentração de custos é uma execução separada de 20 problemas, 3 execuções por problema, executada de 3 a 4 de agosto de 2026, com custos obtidos dos registros de faturamento por requisição.
2. GDPval: OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025. Entregáveis de trabalho de conhecimento avaliados segundo rubricas de tarefa; uma execução de 210 tarefas do conjunto gold publicado, uma tentativa por tarefa, executada em 2 de agosto de 2026. Um modelo Claude faz a avaliação, portanto as pontuações absolutas podem diferir dos resultados publicados.
3. SWE-bench Pro: Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025. Um subconjunto de 482 problemas selecionado por compatibilidade com o harness de avaliação da Anthropic; as pontuações não são comparáveis ao leaderboard público. O Claude Opus 5 no esforço padrão é a média de duas execuções; as configurações de esforço reduzido são execuções únicas; todas foram executadas em 4 de agosto de 2026. Os números de escalonamento vêm tarefa por tarefa dessas execuções: low primeiro, depois o padrão nas suas falhas, resolveu de 92,5% a 93,6% entre os pareamentos de execuções por cerca de $0,45; medium primeiro, de 93,8% a 94,2% por cerca de $0,61; o padrão reexecutado nas suas próprias falhas, 94,0% por $1,06; tudo no padrão, de 90,9% a 92,5% por $0,93. Os custos nesse subconjunto são precificados como a organização de um cliente é medida: o prompt anterior de cada requisição como uma leitura de cache e seus novos tokens como uma escrita de cache de 5 minutos, a partir dos próprios registros de uso das execuções, conferidos com um livro-razão de cliente; a medição própria da organização de avaliação, que fatura o cache em páginas de 8.192 tokens, deu números de 1,4 a 1,8 vezes maiores. Os pareamentos com executor Claude Sonnet 5 no gráfico do advisor vêm da mesma série de medições nesse subconjunto: o pareamento Sonnet-mais-Opus foi executado duas vezes (7 e 8 de agosto de 2026, uma execução e uma replicação exata), o pareamento de baixo esforço uma vez (8 de agosto de 2026) e o Claude Sonnet 5 sozinho duas vezes (77,4%, a linha de base para ambas as linhas Pro). O ponto do Claude Fable 5 em Atualizar o modelo é a média de três execuções no esforço padrão, executadas em 26 de agosto de 2026, precificadas da mesma forma. Os números de orçamento de tarefa do Claude Fable 5.1 são uma execução por orçamento (duas em 35.000 tokens) no mesmo subconjunto no esforço padrão, executadas em 26 de agosto de 2026, com uma execução sem orçamento no mesmo dia (92,1%, $1,10 por tarefa) como linha de base; um conjunto anterior no esforço low, executado em 21 de agosto de 2026, pontuou 88,6% sem orçamento a $0,48 por tarefa. A comparação em Comparar modelos pareia essa execução única com as duas execuções agrupadas do Claude Sonnet 5 do mesmo subconjunto; no esforço padrão do Fable 5.1 o par se lê ao contrário, 41% a mais por tarefa resolvida do que o Sonnet 5. A escada de atualização é uma execução por modelo em seus padrões de lançamento (duas cada para Opus 5 e Sonnet 5, e o ponto do Fable 5 conforme descrito acima), com as execuções de Opus e Sonnet na mesma semana em um único harness e organização.
4. BrowseComp: Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025. Os números de esforço usam um recorte de 500 problemas, de uma a três execuções por configuração, executadas em 3 de agosto de 2026, com o ponto padrão agrupando duas execuções de 26 a 27 de julho de 2026. O gráfico de seguro de custo usa 10 problemas resolvidos de forma confiável de uma fatia de 26 problemas, 50 execuções delegadas (1 a 2 de agosto de 2026) e 70 execuções solo (50 de 2 a 3 de agosto de 2026; 20 arquivadas de 12 a 13 de julho e 1 de agosto de 2026), $6,45 em comparação com $11,99 por execução em expectativa; os números delegados carregam uma faixa de medição de cerca de 20%.
5. Escalonamento de arquitetura de agentes: Kim et al., "Towards a Science of Scaling Agent Systems," arXiv:2512.08296, 2025. Estudo externo independente, citado apenas pela direção da conclusão sobre quando a delegação não compensa, não por qualquer número.
6. DeepWideSearch: "DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking," arXiv:2510.20168, 2025. As 220 perguntas abrangem 15 domínios, cada uma combinando coleta de muitas linhas com recuperação multi-hop; medido no conjunto de linhas vigente do benchmark, 3 execuções por configuração, executadas em 2 de agosto de 2026 (o ponto de equipe com um único worker foi executado de 26 a 27 de julho de 2026).
7. DeepResearch Bench II: Li et al., "DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026. Suas 132 tarefas de pesquisa em 22 domínios são avaliadas segundo rubricas binárias derivadas de especialistas; medido em um subconjunto de 50 tarefas estratificado por todos os temas, uma tentativa por tarefa, 3 execuções por configuração, no Claude Managed Agents com as próprias ferramentas de busca na web e fetch da plataforma (26 a 27 de agosto de 2026); pontuado nas 33 tarefas que nenhuma configuração recusou, com as tentativas interrompidas pelos classificadores de segurança de produção removidas; os custos são o que um cliente é cobrado, as requisições da plataforma mais as taxas de busca na web. As pontuações são a média de cada modelo na base de 33 tarefas com suas próprias tarefas interrompidas removidas; nas 21 tarefas limpas em todos os braços, o Claude Fable 5.1 mantém uma vantagem de 2 a 3 pontos sobre o Claude Fable 5 em todos os níveis de esforço e ambos os modelos ficam estáveis ao longo do esforço. O gráfico de cache reprecifica as mesmas requisições com cada token de entrada à taxa sem cache. O Claude Opus 4.6 julga sob o protocolo de rubrica do benchmark; o original usa um juiz diferente, e um juiz da Anthropic pode favorecer o estilo da casa. O Claude Opus 5 em seu esforço padrão foi executado na mesma superfície e subconjunto, três execuções, em 28 de agosto de 2026: 68,8% nas 50 tarefas brutas, 70,8% na base de 33 tarefas e 71,1% no conjunto de 21 tarefas, a $6,71 por tarefa ($23,72 sem cache); nenhuma de suas tentativas foi interrompida pelos classificadores de segurança, sob uma implantação de salvaguardas mais recente do que aquela sob a qual os outros modelos foram executados.
8. Varredura de defeitos em corpus: Interno da Anthropic, para trabalho maior que uma janela de contexto: um corpus de 21,6 milhões de tokens de 14 fontes públicas de pacotes Python com 130 defeitos plantados e avaliação determinística; protocolo fixado antes das execuções e revisado internamente; três execuções por configuração. Todas as configurações foram executadas no Claude Managed Agents. A configuração de equipe no gráfico é uma execução na qual o coordenador Claude Fable 5.1 executou toda a varredura dentro da plataforma em seu limite documentado de 25 workers Claude Sonnet 5 simultâneos, executada em 30 de agosto de 2026; seus três episódios pontuaram F1 0,764, 0,825 e 0,791 após a auditoria de extras (bruto 0,751, 0,821 e 0,781) por $225, $234 e $283. A configuração solo do Claude Sonnet 5 foi executada de 3 a 4 de agosto de 2026; as configurações solo do Claude Fable 5.1 foram executadas de 24 a 25 de agosto de 2026, sob as configurações de serviço de lançamento da plataforma, três seeds por configuração de esforço, na mesma build do corpus. A imagem do sandbox continha cópias instaladas de parte do corpus, e a etapa final de montagem do Claude Fable 5.1 comparou com elas em 7 de 9 episódios; a reavaliação sem essas adições moveu as seeds afetadas em até 3 pontos. O F1 absoluto é específico desta build do corpus, não comparável entre benchmarks; as comparações de configuração são equivalentes entre si.
9. GPQA Diamond: Rein et al., "GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023. O subconjunto Diamond de 198 perguntas, duas execuções por configuração, executadas em 7 de agosto de 2026, avaliado por modelo contra respostas de referência, tokens do advisor medidos por requisição. Uma verificação de segurança da plataforma recusou duas perguntas de biologia nos executores Sonnet e Opus; excluí-las não altera nenhuma comparação em mais de um ponto.
10. DeepSWE: Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026. O conjunto tem 113 tarefas originais em cinco linguagens com verificadores baseados em programas. Os pareamentos são duas execuções cada, executadas em 7 de agosto de 2026, com tokens do advisor medidos por requisição, e usaram um loop de advisor do lado do cliente em vez da ferramenta advisor, com contabilidade idêntica. As varreduras de esforço de modelo único são execuções únicas precificadas a partir das contagens de tokens, uma aproximação que considera o cache. Os custos por tarefa são os totais da execução divididos por 113.
11. Benchmark interno de codificação agêntica: Interno da Anthropic: 370 tarefas de repositório avaliadas pelos próprios testes dos repositórios. Os números da API foram medidos com um limite de saída de 128.000 tokens, uma execução por configuração: Opus 5 sozinho no esforço padrão de 9 a 10 de agosto de 2026, Claude Fable 5.1 sozinho em cinco valores de esforço definidos explicitamente em 20 de agosto de 2026, e o pareamento de 24 a 25 de agosto de 2026. Tentativas por tarefa: cinco para o pareamento e o controle Opus sozinho, uma para os pontos de modelo único; o pareamento teve em média cerca de duas consultas ao advisor por tentativa; os custos são por tentativa. Os números do Claude Code são execuções das mesmas tarefas de 8 a 23 de julho de 2026, uma execução por configuração, custos aproximados.
12. Benchmark interno de tarefas de repositório (medição de limite): Um conjunto interno separado da Anthropic de cerca de 130 tarefas de repositório, executado de 8 a 10 de agosto de 2026 (Claude Opus 5) e em 20 de agosto de 2026 (Claude Fable 5.1), com um loop de agente simples via API, uma tentativa por tarefa. As execuções do Claude Fable 5.1 são 135 tarefas por limite no esforço padrão definido explicitamente: o número de 16.384 tokens é a média de duas execuções (36,3% em ambas); os números de 64.000 e 128.000 são execuções únicas (58,5% e 60,0%). Seis problemas receberam uma recusa de segurança em todas as execuções e contam como falhas. O número de 16.384 tokens do Opus 5 é a média de duas execuções e seu número de 64.000 é uma execução única (124 tarefas pontuadas). Os números de limite do SWE-bench Pro são uma execução do Claude Fable 5.1 por limite no esforço padrão, executada em 26 de agosto de 2026, em um subconjunto de 100 problemas estratificado a partir do conjunto de 482 problemas da referência 3, não comparável às suas pontuações; os dois limites pontuaram o mesmo no padrão. As distribuições por turno do gráfico vêm da execução do Opus em 64.000 e da execução do Claude Fable 5.1 em 128.000; nenhum turno do Opus atingiu seu limite, e um turno do Fable 5.1 atingiu 128.000 (0,46% de seus turnos excederam 16.384).
13. Chartography: Surge AI, "Chartography," 2026. O conjunto completo publicado de 100 perguntas, medido de 8 a 10 de agosto de 2026, com a implementação da Anthropic no Claude Managed Agents (sandbox em nuvem padrão; as configurações com advisor usam o advisor do Managed Agents). O Claude Sonnet 4.6 avalia em vez do juiz de referência e o benchmark é executado com ferramentas, portanto as pontuações são comparáveis entre configurações aqui, mas não com o leaderboard publicado. Duas execuções por configuração, agrupadas; as variações entre execuções foram de 4 a 10 pontos. Os custos excluem o tempo de sandbox, que adicionou menos de 1%. As execuções solo do Claude Fable 5.1 são de 24 de agosto de 2026, sob as configurações de serviço de lançamento da plataforma, duas execuções por configuração; seis tentativas atingiram o limite de sessão de 15 minutos e pontuam 0, e dois gráficos por execução foram respondidos pelo Claude Opus 5 após uma recusa de segurança. O executor Claude Opus 5 de baixo esforço com um advisor Claude Fable 5.1 foi executado duas vezes em 30 de agosto de 2026, sob as mesmas configurações (63,0 e 67,0, média 65,0, a $0,72 por gráfico; o advisor foi consultado em 88% das tarefas em cada execução, e 4 de suas 219 respostas vieram do Claude Opus 5 em vez dele, cada uma após um filtro de segurança de produção interromper a própria resposta do advisor). A comparação de taxa de consulta para os pareamentos anteriores vem da reexecução das mesmas configurações na Messages API com um conjunto de ferramentas de contêiner, de 10 a 11 de agosto de 2026.
14. Avaliação de auditoria de prompt de central de suporte: Um conjunto construído pela Anthropic de 44 tickets de suporte com avaliação determinística, executado no início de agosto de 2026 e reportado em 8 de agosto de 2026, sob seis prompts do sistema, cada um adicionando ao mesmo prompt limpo um padrão comum em prompts escritos para Claude Opus 4.8 e Claude Sonnet 4.6. Cada ponto do gráfico é um de três casos (modelo mais antigo, modelo mais novo no mesmo prompt, modelo mais novo após a auditoria) com média sobre os seis prompts e 44 tickets. O ganho de precisão do Opus 5 tem um intervalo de confiança de 95% de 3 a 8 pontos; as diferenças de precisão do Sonnet estão dentro do ruído.
15. Conjunto de perguntas sobre arquivo de dados: Um conjunto construído pela Anthropic de 25 perguntas agregadas sobre uma fatia de 1.862 linhas de um CSV público de vendas de bebidas alcoólicas, com gabarito calculado pelo pandas e avaliação por correspondência exata, executado no Claude Sonnet 5 e no Claude Opus 5 com o pensamento desativado (o braço em contexto não consegue concluir no padrão), um limite de saída de 4.000 tokens e sem cache de prompt, três execuções por configuração, executadas em 19 de agosto de 2026. O braço de arquivo faz upload do CSV pela Files API e usa a ferramenta code_execution_20260120.
16. Medição de duração de cache: O trabalho de triagem de 20 issues de Reduzir tokens de entrada e contexto, executado em 23 de agosto de 2026, no Claude Sonnet 5 e no Claude Opus 5 na Messages API com o mesmo harness, as células do Claude Opus 5 com max_tokens elevado para 4.096, com pausas inseridas antes de uma parcela escolhida aleatoriamente dos turnos (nenhuma, 5%, 10% e todos os turnos a 6 minutos em todas as 20 issues em ambos os modelos, mais todos os turnos a 2 minutos no Claude Sonnet 5; pausas de 20 minutos em um subconjunto de 5 issues em ambos os modelos; pausas de 45 minutos em um subconjunto de 5 issues apenas no Claude Sonnet 5). Três execuções por célula, custo calculado a partir dos campos usage de cada resposta em uma organização faturada como cliente aos preços de tabela, precisão contra os mesmos rótulos gold. O ponto de cruzamento é cerca de 3,3% dos turnos em ambos os modelos: a mediana da parcela de equilíbrio de cada sessão, calculada pelo modelo de custo a partir dos tamanhos de contexto turno a turno daquela sessão, sobre todas as 45 sessões de vinte issues do Claude Sonnet 5 e 36 do Claude Opus 5 na análise (cada cronograma de pausas executado no trabalho completo, sob todas as três configurações de cache, três execuções cada; as células de 5 issues não estão incluídas). A célula de 5% empatou no Claude Sonnet 5 porque as pausas daquele sorteio caíram em prefixos pequenos. A regra de 1 em 20 da página fica acima do ponto de cruzamento medido. A Anthropic mediu requisições de keep-alive que renovam o cache de 5 minutos apenas como comparador. Elas igualaram a configuração de 1 hora no melhor caso e custaram mais com uma pausa antes de cada turno, portanto não as use nesses dois modelos; no Claude Fable 5.1 a aritmética se inverte (referência 19).
17. Parcela de leitura de cache em produção: Uso agregado de primeira parte da Claude API nos 14 dias encerrados em 23 de agosto de 2026, apenas o produto de API direta, organizações internas da Anthropic excluídas, nenhuma organização identificada. Um dia-organização conta como um loop de agente quando suas requisições carregam definições de ferramentas e resultados de ferramentas, seus prompts contêm 9 ou mais chamadas de ferramentas anteriores em média, o cache foi usado e ela fez pelo menos 10 dessas requisições (a API não tem identificador de conversa, então isso substitui o comprimento da conversa): 303.003 dias-organização em 106.487 organizações, parcela mediana de leitura de cache de 84,2% de todos os tokens de entrada, quartil superior 91,7%. Os rótulos de caso de uso (o caso de uso declarado da organização ou, caso contrário, o classificado) cobrem 74% desses dias-organização e 99% de seus tokens; organizações de codificação fornecem 87% dos tokens de entrada agênticos e leem uma mediana de 88,5% (90,9% com 25 ou mais chamadas de ferramentas anteriores), quartil superior 93,4%, com cerca de 72% dos dias-organização de codificação em 80% ou mais; agentes de suporte, pesquisa e dados leem de 84% a 85%. O decil superior de dias-organização lê 95,9% ou mais para codificação e de 94,2% a 94,8% para agentes de suporte, pesquisa, dados e outros. A divisão no nível de requisição com 25 ou mais chamadas de ferramentas anteriores vem de uma amostra de seis horas: codificação 92% leitura, 7% escrita, menos de 1% sem cache. Organizações sem rótulo, em sua maioria pequenas, leem uma mediana de 11%. Dias-organização sem definições de ferramentas leem uma mediana de 34,6%. Uma consulta independente sobre a mesma janela que reconstrói conversas de 10 ou mais requisições, em vez de pontuar dias-organização, coloca a mediana em 90,2%; a diferença é de escopo, não de dados.
18. Medição de momento de compactação: A variante longa do agente de triagem de Reduzir tokens de entrada e contexto, executada em 24 de agosto de 2026, no Claude Sonnet 5 com o cache de 5 minutos, custo a partir dos campos de uso aos preços de tabela, cinco sessões por braço: um braço sem alterações no esforço padrão do início ao fim ($0,81 por sessão), e dois braços que começam em baixo esforço e fazem as mesmas duas alterações que quebram o cache, uma troca para o esforço padrão e uma ferramenta adicionada, seja no meio da sessão nas requisições 12 e 17 ($0,95) ou juntas na primeira requisição após a primeira compactação ($0,75). Um quarto braço de seis sessões, executado em 25 de agosto de 2026, fez as mesmas duas alterações na requisição que disparou a primeira compactação ($0,92 por sessão): a passagem de sumarização daquela requisição escreveu o contexto de 81.000 tokens no cache em vez de lê-lo, de modo que essa passagem custou $0,21 contra $0,04 para a mesma passagem no braço de fronteira. As sessões compactaram pela primeira vez na requisição 21 a 25 (16 das 21 sessões na requisição 22), uma vez que o prompt ultrapassou o gatilho de compactação de 80.000 tokens, e duas sessões sem alterações compactaram uma segunda vez perto do fim. O total menor do braço de fronteira em relação ao braço sem alterações reflete suas requisições de baixo esforço antes da alteração e essas segundas compactações, e não o cache: os custos de reescrita dos dois braços diferem em menos de um centavo. O braço de meio de sessão pagou $0,23 por sessão em reescritas de cache; a diferença entre os braços de meio de sessão e de fronteira foi de $0,20 com um intervalo de confiança de 95% de $0,11 a $0,29. Uma sessão de meio de sessão saiu barata ($0,82) depois que seu modelo chamou incorretamente a ferramenta de busca após a compactação e obteve resultados vazios; ela está incluída, e sem ela o braço tem média de $0,98. A precisão teve média de 14,2 de 20 rótulos em cada braço de 24 de agosto e 14,7 no braço de 25 de agosto; as leituras de cache foram 91% dos tokens de prompt sem alterações, 85% no meio da sessão, 91% na fronteira e 86% com as alterações na requisição disparadora.
19. Medição de duração de cache no Claude Fable 5.1: O mesmo trabalho de triagem de 20 issues e harness da referência 16, executado em 23 e 26 de agosto de 2026, no snapshot de lançamento do Claude Fable 5.1 aos seus preços de lançamento ($10 entrada, $12,50 escrita de 5 minutos, $20 escrita de 1 hora, $0,25 leitura de cache, $50 saída por milhão de tokens), três configurações por cronograma: o cache de 5 minutos, o cache de 1 hora e o cache de 5 minutos mantido aquecido por uma requisição max_tokens: 0 no prefixo inalterado a cada 4 minutos de tempo ocioso (as execuções de 23 de agosto fizeram ping com max_tokens: 1; cada ping de 26 de agosto renovou o cache e não faturou saída). Cronogramas: sem pausas, 10% dos turnos e todos os turnos a 6 minutos em todas as 20 issues, e pausas de 45 minutos no subconjunto de 5 issues; três execuções por célula, custo calculado a partir dos campos usage de cada resposta aos preços de tabela, precisão contra os mesmos rótulos gold (12 a 17 rótulos exatos de 20). Médias por sessão em 26 de agosto para as configurações de 5 minutos, 1 hora e keep-alive: sem pausas $2,42, $3,09, $2,29; 10% pausados $4,50, $2,96, $2,36; todos os turnos $22,89, $3,01, $2,62; as células de 23 de agosto concordam dentro de 6%. Os números de 45 minutos ($1,68, $0,59 e $0,71 por sessão de 5 issues) são de uma reexecução limpa em 26 de agosto depois que um incidente de faturamento de cache estragou as primeiras células daquele dia; as execuções de 23 de agosto deram $1,67, $0,58 e $0,70. O ponto de cruzamento entre as configurações de 5 minutos e 1 hora é 3,1% dos turnos, a mesma medida da referência 16.
20. Terminal-Bench 3: as 74 tarefas do benchmark público de agentes de terminal, executadas no Claude Managed Agents com duas ferramentas personalizadas, um shell e um editor de arquivos que o harness de avaliação executa no próprio contêiner de cada tarefa, no lugar das ferramentas integradas da plataforma, e de resto nas configurações padrão da plataforma para contas externas, duas execuções por modelo no esforço high, de 27 a 28 de agosto de 2026. As pontuações são taxas brutas de aprovação sobre as 148 tentativas por modelo; execuções únicas oscilam de 5 a 11 pontos. Os custos são o que um cliente seria cobrado aos preços de tabela, reprecificados requisição por requisição a partir dos registros de uso das execuções com o tempo de vida de cache de 5 minutos. O Claude Opus 4.7 encerrou 11 de suas 148 tentativas em seu limite de saída.

Próximos passos