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 menos caro 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 esforço e a arquitetura para cada requisição, o que permite posicionar uma carga de trabalho em quase qualquer ponto da fronteira entre custo e inteligência.

As alavancas vêm em dois tipos:

• Ganhos gratuitos reduzem o gasto sem tocar na qualidade: "prompt caching" (cache de prompt), higiene de tokens, uma auditoria de prompts 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 gasto do workspace como salvaguarda final.
• Tradeoffs 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: reduziu o custo do loop de agente por um fator de 2,5 a 3,7 nos benchmarks deste guia e reduziu a conta de um pequeno agente de triagem em 83%, ou 88% com o corte de entrada adicionado. As alavancas multimodelo são mais restritas; um segundo modelo compensou em dois formatos, um conselheiro (advisor) e um orquestrador (orchestrator).



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.



Reduza o gasto sem perder qualidade

Cache de prompt, higiene de tokens, processamento em lote e uma auditoria de prompts 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 em cache o contexto repetido

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 todos os turnos anteriores. 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 pela 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.

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 execuções do WideSearch¹ e 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 alcançaram taxas de acerto de 81% a 90%. 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.

Se o seu loop espera por humanos entre 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), mas se paga na primeira falha de cache evitada, porque uma falha reenvia todo o prefixo pelo preço cheio e o escreve novamente.

A configuração dá pouco trabalho. O cache automático posiciona os pontos de interrupção para você; caso contrário, a skill da 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.

Três configurações podem quebrar seu cache durante uma tarefa. Alterar effort entre requisições invalida o prefixo em cache, então altere-o apenas onde você faria o recache de qualquer forma, como em um limite de compactação. Alterar um orçamento de tarefa no meio do caminho faz o mesmo, 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 refazer o cache de tudo depois dele, então limpe em poucos lotes grandes em vez de muitos pequenos. Faça todas as três alterações em pausas naturais e 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 não custa nada em 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 web fetch 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. A chamada programática de ferramentas permite que o Claude execute várias chamadas de ferramentas a partir de código, de modo 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. Gerenciar 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 limiar 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 alteração. A Anthropic ativou as alavancas uma de cada vez para 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, para o segundo painel, uma variante mais longa do mesmo trabalho):

O cache fez quase todo o trabalho, e o corte de tokens levou o total a 88%. Cada barra é uma execução, então diferenças de $0,10 são ruído; as mostradas aqui não são. A compactação precisa de uma sessão longa o suficiente para acioná-la: a execução de 20 issues nunca atingiu o piso de 50.000 tokens depois que suas entradas foram cortadas, mas na variante mais longa do segundo painel ela disparou uma vez e reduziu a conta em mais 38%.

A edição de contexto é a única alavanca aqui que não é gratuita. Cada passagem de limpeza reescreve a conversa em cache, o que trabalha contra o cache de prompt; nesta execução, a edição de contexto custou mais do que economizou. Use-a para abrir espaço na janela de contexto, e limpe em poucos lotes grandes.



Processe 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, backfills e jobs 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 de 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 da 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 o comando 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 hunk mostrado) e lista o que deixou deliberadamente intocado: 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 nenhuma 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 dos 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 novo modelo segue de forma literal demais custam dinheiro: remover "verifique duas vezes" reduziu o custo por ticket do Opus 5 em um terço, e remover "seja maximamente minucioso" quase tanto. Texto que não se ajusta mais ao 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 aparecem em descrições de ferramentas e skills, e vale a pena removê-los lá também.



Troque custo por inteligência

Essas alavancas definem onde um único modelo se posiciona 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 (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 é 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 do próprio contexto e menos retrocessos. O prêmio por token é rotineiramente superado por fazer menos de tudo.

A Anthropic mediu isso diretamente no DeepResearch Bench II⁷, um benchmark de relatórios de pesquisa difícil o suficiente para separar os modelos:

O modelo de fronteira com esforço low foi mais preciso e cerca de 10% mais barato por tarefa que o modelo intermediário, apesar da diferença por token. Ele nem sempre vence, porém. No subconjunto do SWE-bench Pro³ desta página, que ambos os modelos em grande parte saturam e cujas pontuações não são comparáveis ao leaderboard público, o Claude Opus 5 sozinho igualou o Claude Fable 5 sozinho (91,7% comparado com 91,3%, dentro do ruído entre execuções) por cerca de 60% do seu custo. Em trabalho mais difícil, como as tarefas do DeepResearch Bench II, a vantagem do Fable reaparece.

Para a maioria das cargas de trabalho de agente, comece com o Claude Opus 5: por token ele custa metade do que o Fable 5 custa e 2,5 vezes o que o Sonnet 5 custa, e naquele subconjunto de codificação ele igualou a precisão do Fable. Na outra ponta, o Claude Haiku 4.5 respondeu perguntas do GPQA Diamond⁹ por 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.



Ajuste o esforço

O esforço é a forma mais direta de ajustar um modelo à sua tarefa. O parâmetro effort governa quanto pensamento, chamada 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 profundidade que a tarefa nunca usa.

Nos benchmarks de pesquisa e trabalho de conhecimento (WideSearch¹, DeepWideSearch⁶, BrowseComp⁴ e GDPval², todos com o Claude Fable 5), a curva de precisão contra 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 por 70% a 85% 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 trabalhador Claude Sonnet 5 por um custo 20% menor: reduzir o esforço superou uma mudança de arquitetura.

Configurações mais baixas também são mais rápidas, o que importa quando a latência é a restrição. Nessas execuções, low levou 4,5 minutos por problema no DeepWideSearch, comparado com 7,9 minutos no padrão. No benchmark de corpus, cuja entrada não cabe em nenhuma janela de contexto individual, o Fable 5 levou 7,9, 9,1 e 11,4 horas por episódio em low, medium e no padrão.

Codificação de longo horizonte é o outro formato. No SWE-bench Pro³, o Claude Opus 5 abriu mão de cerca de 2 pontos em medium por metade do custo e 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 precisão contra 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 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 a etapa 2 de medir na sua própria carga de trabalho estabelece linhas de base em todos os níveis de esforço.

Esforço mais baixo custa precisão em cargas de trabalho que atingem o teto do modelo, onde a precisão genuinamente escala com a profundidade do raciocínio. No DeepResearch Bench II⁷, onde cada relatório recompensa raciocínio profundo por subtópico, cada degrau de esforço comprou cerca de 2,4 pontos de pontuação de rubrica; não há corte de custo gratuito nessa curva:

A descrição da tarefa por si só não revela qual 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: alterar o esforço no meio da sessão invalida o cache (consulte Armazene em cache o 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 toda tarefa 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,70 cada, contra 91,7% por $1,39 executando tudo no padrão: a mesma taxa de aprovação por metade do custo, contando as tentativas baratas que falharam. Começar em medium em vez disso resolveu cerca de 94% por cerca de $0,95. 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 busca, reverificação e testes em excesso. 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ção redundante 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 à medida que o orçamento apertava:

Um orçamento generoso abriu mão de cerca de 2,7 pontos de taxa de aprovação por uma economia de custo de 18%, e o orçamento mais apertado permitido abriu mão de 4,4 pontos por uma economia de 47%. Os orçamentos compraram eficiência aqui, não precisão.

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 que não economiza nada. No Claude Managed Agents, um orçamento de sessão é a parada rígida em dólares por trás de ambos. Defina todos 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 conta, com um limite de gasto do workspace como salvaguarda final.

• Orçamentos de tarefa estão em beta (cabeçalho beta task-budgets-2026-03-13) no Claude Opus 5, Claude Fable 5, Claude Opus 4.8 e Claude Opus 4.7, mas não no Claude Sonnet 5; verifique primeiro a tabela de suporte. Comece perto do uso de tokens do 90º percentil do seu loop, 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 alteração 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 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 um terço das do Claude Fable 5, nenhuma delas resolvida. Execuções limitadas gastaram menos por tentativa, mas compraram proporcionalmente menos resoluções, então o custo por tarefa resolvida foi o mesmo que em 64.000. Nessa configuração nada foi cortado, e o Fable resolveu 54,6% das tarefas em vez de 36,6% nos problemas que ambas as execuções pontuaram (em um recorte separado do subconjunto do SWE-bench Pro³, descrito na referência 12, 92% em vez de 90%). Tentar novamente tentativas limitadas só adiciona custo: no mesmo limite elas nunca tiveram sucesso, e em um mais alto você também paga pela tentativa desperdiçada. Defina max_tokens como 64.000 para trabalho agêntico (128.000, o máximo, com esforço xhigh ou max), 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 consegue 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 pelas taxas de lista 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 lista (incluindo o Claude Sonnet 5) e se combina com o orçamento de tarefa consultivo. Deployments aplicam o mesmo campo a toda execução.

O primeiro de dois gráficos de max_tokens plota o custo por tentativa e por tarefa resolvida em cada limite:

O segundo plota o comprimento de saída por turno contra os limites:



Combine modelos

Arquiteturas multimodelo se encaixam em 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 pelas taxas do 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 de conselheiro: escalar decisões difíceis

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

Para usá-la, adicione a ferramenta de conselheiro à sua requisição. Este 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 conselheiro 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 conselheiro 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 de conselheiro.

O que determina o retorno. O conselheiro vê a tarefa apenas por meio das chamadas do executor, então duas coisas decidem o quanto ele ajuda.

A primeira é a diferença entre os modelos. O conselheiro só pode transferir a capacidade que falta ao executor: no GPQA Diamond⁹, um executor Claude Haiku 4.5 ganhou muito com um conselheiro Claude Opus 5, um executor Claude Sonnet 5 ganhou alguns pontos e um executor de fronteira quase nada.

A segunda, e a mais frágil, é se o executor realmente pergunta (a taxa de consulta, ou consult rate). Um executor com esforço baixo pode deixar de perceber que está travado: um par 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 chega à maior parte do caminho. Entre os pares no gráfico a seguir, o conselheiro fechou de 60% a 90% da diferença em relação ao modelo mais forte, enquanto esse modelo foi pago apenas nas consultas, o que torna os casos de custo possíveis:

A taxa de consulta responde ao prompting. Apenas com a descrição integrada da ferramenta, os executores chamam menos do que deveriam, especialmente em trabalho de codificação, então a documentação da ferramenta de conselheiro fornece um prompt do sistema que pede uma chamada antes do trabalho substantivo e uma antes de finalizar, cerca de duas a três chamadas por tarefa. O par de codificação medido a seguir rodou nessa cadência, cerca de duas consultas em cada tarefa. Essa página também aborda como incentivar um executor que chama pouco e como limitar as chamadas no lado do cliente para conter o custo. Portanto, observe a taxa de consulta: faça prompting para ela, meça-a e restaure o esforço do executor se ela despencar.

Quando compensa no custo. Um conselheiro economiza dinheiro quando algumas consultas curtas, cobradas na tarifa do conselheiro, substituem a execução do modelo do conselheiro para a tarefa inteira. Isso funciona melhor quando o modelo do conselheiro tem preço bem acima do executor, então a configuração mais econômica é um conselheiro de fronteira sobre um executor de nível intermediário. Um par pode se sustentar mesmo no topo da faixa, porque o conselho também economiza tokens do executor: um executor informado sobre a abordagem correta 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 conselheiro Claude Fable 5 foi a configuração mais precisa medida: 85,7% das tentativas resolvidas por $8,40 por tentativa. Ele fica acima da linha que passa pelas configurações de esforço próprias de cada modelo, mas apenas um ou dois pontos acima da melhor delas (Opus sozinho na configuração padrão, 84,4% por $8,50, e Fable sozinho em medium, 83,4% por $8,20), o que uma única execução não separa do ruído. O Fable sozinho com esforço medium atinge aproximadamente a mesma precisão que o par (83,4% em comparação com 85,7%) por aproximadamente o mesmo dinheiro ($8,20 em comparação com $8,40 por tentativa):

Uma medição anterior por meio do modo conselheiro do Claude Code produziu a mesma ordenação. Leia este resultado como um formato a testar na sua carga de trabalho, não como uma economia: no topo da faixa, o conselheiro compra um pouco de precisão ao preço de fronteira, e o caso de custo pertence a pares com uma diferença de capacidade maior, como o caso de leitura de gráficos a seguir. O custo de latência são as próprias consultas: cerca de duas chamadas extras ao modelo de fronteira por tarefa neste benchmark, cada uma no caminho crítico da tarefa.

Quando compensa em vez de aumentar o esforço. Onde a diferença de capacidade é maior e a precisão de uma carga de trabalho responde ao esforço, um executor com esforço baixo que consulta um conselheiro pode ser um degrau mais barato do que aumentar o esforço do próprio executor, porque o conselheiro é pago apenas nas tarefas que precisam dele.

No Chartography¹³, um benchmark público de leitura de gráficos executado no Claude Managed Agents com seu conselheiro, um executor Claude Opus 5 com esforço low e um conselheiro Claude Fable 5 pontuou 67,5 por $0,60 por tarefa. Isso está acima da linha que passa pelas configurações de esforço próprias de qualquer um dos modelos (o Opus sozinho foi de 49 para 75 entre low e medium por $0,38 a $0,94), embora as configurações medium e padrão do próprio executor ainda detenham as pontuações mais altas, a 1,6 e 3,3 vezes o preço:

O executor com esforço baixo consultou o conselheiro em 86% das tarefas, a condição que o par do SWE-bench Pro não conseguiu atender. Meça a taxa de consulta no seu loop de agente antes de confiar nesta configuração.

Qualquer que seja o par, primeiro calcule o preço do modelo do conselheiro 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 diferença de capacidade quanto a razão de preços.

Quando se encaixa. A estratégia de conselheiro é adequada para 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 várias etapas. Ela se encaixa mal quando cada turno realmente 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 conselheiro.



Estratégia de orquestrador: delegar trabalho em volume

Na estratégia de orquestrador (orchestrator strategy), o modelo de fronteira mantém o loop. Ele decompõe a tarefa, despacha subtarefas para modelos trabalhadores de menor custo e mescla seus resultados. A transcrição do próprio orquestrador permanece curta porque os trabalhadores absorvem a exploração pesada em tokens, então a maioria dos tokens é cobrada nas tarifas dos trabalhadores, 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 trabalhadores, cada um com seu próprio modelo. Para um exemplo funcional completo com um coordenador Claude Fable 5 e trabalhadores Claude Sonnet 5, consulte a receita do Claude Cookbook Coordinator pattern: big models for planning, small models for execution.

Este padrão economiza tempo de relógio quando os trabalhadores podem rodar em paralelo: no benchmark de corpus⁸, um episódio levou pouco mais de 2 horas com o coordenador executando o limite documentado da plataforma de 25 trabalhadores simultâneos, em comparação com 11,4 horas sozinho. Ele economizou dinheiro em apenas duas situações medidas. Em trabalho que um único modelo poderia realizar sozinho, o mesmo modelo com esforço menor 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 saber de antemão quais serão esses casos, algumas dessas execuções dominam a conta. Um coordenador que entrega trabalho rotineiro a um trabalhador de menor custo limita essa cauda, porque qualquer espiral agora acontece nas tarifas do trabalhador.

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 trabalhador Claude Sonnet 5 custou pouco menos da metade do Fable sozinho em média e cerca de um terço no percentil 90 ($12 em comparação com $33), e a execução individual mais cara do modelo sozinho, a $84, também estava errada:

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

Caso 2: trabalho maior que uma janela de contexto. Um modelo sozinho precisa processar uma entrada desse tamanho de forma serial, uma "context window" (janela de contexto) por vez, pagando para reler seu próprio estado a cada passagem. Os trabalhadores leem cada um sua própria partição, em paralelo e nas tarifas de trabalhador. Trabalho pesado em leitura que ainda cabe em uma janela de contexto é um problema de escolha de modelo, não 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 este 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 conta é a própria leitura do corpus: o Claude Fable 5 sozinho custou de $720 a $764 por episódio em todas as configurações de esforço, e apenas sua precisão mudou. A configuração com coordenador custou mais de 60% menos do que qualquer uma dessas configurações e pontuou de 2 a 6 pontos abaixo do Fable em medium ou no padrão, enquanto superou completamente uma linha de base do Claude Sonnet 5 sozinho:

A contabilidade de tokens mostra o porquê. Ambas as contas são em sua maioria leitura de corpus servida a partir do cache: a configuração com coordenador leu cerca de 570 milhões de tokens em cache por episódio, quase três vezes os aproximadamente 200 milhões do modelo sozinho, e ainda custou menos da metade, porque suas leituras foram cobradas na tarifa de leitura de cache do Claude Sonnet 5 em vez da do Claude Fable 5. O Fable 5 no esforço padrão ainda detém a precisão máxima, a 2,8 vezes o custo da configuração com 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 peças independentes, idealmente demais para uma janela de contexto. Quando o trabalho é uma 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 os casos desse tipo medidos, o modelo do coordenador sozinho com esforço menor saiu na frente.

O BrowseComp⁴ mostra a fronteira dentro de um único benchmark. A delegação compensou na fatia rotineira e perdeu no conjunto completo e mais difícil, onde o modelo de fronteira sozinho atingiu a precisão da configuração com coordenador a um custo de 22% a 30% menor. Trabalho externo independente relata o mesmo padrão⁵. Se o trabalho é uma cadeia, cabe em um contexto sem uma cauda de custo longa, ou um único modelo com esforço menor 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 peças independentes, ou é uma resposta alcançada por meio 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. Primeiro, varra o esforço no seu modelo atual. É o experimento mais barato desta página, e a maioria das cargas de trabalho termina aí.
2. Se a varredura mostrar uma diferença, calcule o preço do modelo mais forte sozinho com esforço baixo. Esse é o número que um par com conselheiro precisa superar, e os pares desta página que o superaram foram aqueles cujo executor realmente consultou.

Os resultados multimodelo desta página foram julgados em relação ao mesmo modelo com esforço menor e em relação ao modelo imediatamente abaixo rodando sozinho. Essa é a comparação a executar na sua própria carga de trabalho, e é por isso que o primeiro passo é uma varredura de esforço.

Quando você adicionar um conselheiro, trata-se de uma definição de ferramenta, não de uma rearquitetura.



Meça na sua própria carga de trabalho

Os números desta página são de julho e agosto de 2026, nos preços de tabela da época, e vão variar à medida que modelos e preços mudarem. Sua taxa de escalonamento, 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: calcule o preço das quatro contagens de tokens no usage de cada resposta em suas próprias tarifas, somadas entre as requisições da tarefa (a API de Uso e Custo informa 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 o 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 diferença que o esforço não consegue fechar, adicione a estratégia multimodelo que se encaixa e execute a suíte novamente.
4. Execute a vencedora em modo sombra em uma fatia do tráfego antes da migração, e então mantenha a suíte rodando.

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

# Preços por milhão de tokens da página de preços; altere estes dois para outro modelo.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # Gravações em cache custam 1,25x o preço de entrada (cache de 5 minutos); leituras de cache, 0,1x.
    + (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

Em loops de agente, o termo de leitura de cache geralmente é o maior dos quatro; se não for, verifique se o cache está ativado. Quando a ferramenta de conselheiro ou a compactação está habilitada, alguns tokens são informados 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 nas tarifas do modelo conselheiro.

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



Benchmarks referenciados

Todas as medições são execuções internas da Anthropic desses benchmarks. Salvo indicação em contrário, os custos estão em USD nos preços de tabela de agosto de 2026; 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 nessas tarifas em vez de informar 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. Os gráficos de cache e de esforço vêm de execuções separadas, então os custos por problema diferem ligeiramente. O gráfico de concentração de custo é uma execução separada de 20 problemas, 3 execuções por problema, com custos calculados a partir de registros de cobrança 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 em relação a rubricas de tarefa; uma execução de 210 tarefas do conjunto gold lançado, uma tentativa por tarefa. Um modelo Claude avalia, então 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. Os números de escalonamento vêm tarefa por tarefa dessas execuções: low primeiro, depois o padrão em suas falhas, resolveu de 92,5% a 93,6% entre os pares de execuções por cerca de $0,70; medium primeiro, de 93,8% a 94,2% por cerca de $0,95; o padrão reexecutado em suas próprias falhas, 94,0% por $1,58; tudo no padrão, de 90,9% a 92,5% por $1,39. Os pares com executor Claude Sonnet 5 no gráfico de conselheiro vêm da mesma série de agosto de 2026 neste subconjunto: o par Sonnet mais Opus foi executado duas vezes (uma execução e uma replicação exata) e o par de esforço baixo uma vez; os números de orçamento de tarefa são uma execução por orçamento no mesmo subconjunto. O número do Claude Fable 5 em Compare modelos é uma única execução de julho de 2026, também a linha de base sem orçamento do gráfico de orçamento de tarefa; toda execução com orçamento completou todos os 482 problemas sem erros de harness.
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. 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 e 70 sozinhas ($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 descoberta 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.
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 em relação a rubricas binárias derivadas de especialistas; medido em um subconjunto de 50 tarefas estratificado entre todos os temas, uma tentativa por tarefa, 3 execuções, pontuado nas tarefas que nenhuma configuração recusou. 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. As execuções são anteriores ao Claude Opus 5, daí sua ausência no gráfico de Compare modelos. O custo do Sonnet 5 difere ligeiramente entre o gráfico de cache (custo de inferência, com e sem cache) e aquele gráfico (custo total, cache ativado); ambos vêm das mesmas execuções.
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 de pacotes Python públicos 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. Toda configuração rodou no Claude Managed Agents. A configuração de equipe no gráfico é uma execução de agosto de 2026 na qual o coordenador Claude Fable 5 executou toda a varredura dentro da plataforma em seu limite documentado de 25 trabalhadores Claude Sonnet 5 simultâneos; seus três episódios pontuaram F1 0,842, 0,805 e 0,810 por $263, $299 e $261. As configurações sozinhas são execuções de julho de 2026 na mesma build do corpus. 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, medido em agosto de 2026, duas execuções por configuração, avaliado por modelo em relação a respostas de referência, tokens do conselheiro 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. Medido em agosto de 2026: 113 tarefas originais em cinco linguagens com verificadores baseados em programa. Os pares são duas execuções cada, com tokens do conselheiro medidos por requisição, e usaram um loop de conselheiro no lado do cliente em vez da ferramenta de conselheiro, com contabilidade idêntica. As varreduras de esforço de modelo único são execuções únicas precificadas a partir de contagens de tokens, uma aproximação que considera o cache. Os custos por tarefa são totais de 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 (Opus 5 sozinho, Fable 5 sozinho e o par) foram medidos em agosto de 2026 no esforço padrão com um limite de saída de 128.000 tokens, uma execução por configuração: cinco tentativas por tarefa nas configurações padrão e para o par, uma em low e medium; o par teve em média cerca de duas consultas ao conselheiro por tentativa; os custos são por tentativa. Os números do Claude Code são execuções de julho de 2026 das mesmas tarefas, 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 em agosto de 2026 com um loop de agente de API simples, uma tentativa por tarefa. Os números de 16.384 tokens são a média de duas execuções por modelo; os números de 64.000 tokens são execuções únicas (124 tarefas pontuadas para o Opus 5; 108 para o Claude Fable 5, o ambiente tendo pulado o restante antes de o modelo rodar). Cerca de metade das tentativas do Fable que o limite de 16.384 havia encerrado foram resolvidas em 64.000; uma execução adicional do Fable em 128.000 pontuou 56,1%, dentro do ruído da execução de 64.000. Os números de limite do SWE-bench Pro são uma execução do Claude Fable 5 por limite no esforço padrão 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. As distribuições por turno do gráfico vêm da execução do Opus em 64.000 e da execução do Fable em 128.000, então nenhuma é cortada pelo seu próprio limite.
13. Chartography: Surge AI, "Chartography," 2026. O conjunto completo lançado de 100 perguntas, medido em agosto de 2026 com a implementação da Anthropic no Claude Managed Agents (sandbox de nuvem padrão; as configurações com conselheiro usam o conselheiro do Managed Agents). O Claude Sonnet 4.6 avalia em vez do juiz de referência e o benchmark roda com ferramentas, então as pontuações são comparáveis entre configurações aqui, mas não ao 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%. A comparação de taxa de consulta vem da reexecução das mesmas configurações na Messages API com um conjunto de ferramentas de contêiner.
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 em agosto de 2026 sob seis prompts do sistema, cada um adicionando ao mesmo prompt limpo um padrão comum em prompts escritos para o Claude Opus 4.8 e o 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.



Próximos passos