Parâmetro de Esforço do Claude Opus 5: Trocando Custo por Capacidade

Todo artigo principal sobre o lançamento do Claude Opus 5 em 24 de julho de 2026 nomeou a mesma funcionalidade. A Fortune chamou-a de uma forma de alternar entre custo e capacidade. CNBC, Bloomberg e TechCrunch todos apontaram para ela. Nenhum deles disse o que é, quais são os níveis, o que acontece quando você muda um, ou o que isso faz à sua conta.

É um parâmetro de requisição chamado effort, tem cinco níveis no Opus 5, e o padrão é high. Essa é toda a funcionalidade. O que a torna digna de um artigo é que a Anthropic recalibrou os níveis para este modelo, o que significa que as configurações que você ajustou no Opus 4.8 estão agora erradas, e uma combinação específica de configurações retorna um erro 400 que aparecerá em muitos logs de migração esta semana.

O que o parâmetro `effort` realmente é

O `effort` reside no objeto output_config em uma requisição da API de Mensagens:

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "output_config": { "effort": "high" },
  "messages": [
    { "role": "user", "content": "Refatorar este módulo e explicar os trade-offs." }
  ]
}

Ele controla quanto raciocínio interno o modelo faz antes de responder. O Opus 5 executa o pensamento adaptativo por padrão, e o `effort` é o seletor que define o quão generosamente esse orçamento de pensamento é gasto. Um `effort` mais alto significa mais tokens de raciocínio, mais custo e mais latência. Um `effort` mais baixo significa menos dos três.

As interfaces de consumidor expõem a mesma ideia como um seletor de `effort` em vez de um campo JSON bruto, que é de onde vem a abordagem da imprensa de uma alternância entre custo e capacidade. Por baixo, está este parâmetro. Se você constrói na API, o parâmetro é o que você realmente controla, então é sobre isso que o resto deste artigo fala. O formato completo da requisição está no nosso guia da API do Opus 5, e a referência do parâmetro está na visão geral de modelos da Anthropic.

Uma coisa que o `effort` não é: um controle de verbosidade. O guia de prompt da Anthropic para o Opus 5 é explícito que diminuir o `effort` reduz o raciocínio, não o comprimento da resposta visível. O Opus 5 já escreve respostas padrão mais longas e entregas mais longas que o Opus 4.8. Se você quer uma saída mais curta, peça uma saída mais curta no prompt. Diminuir para low não fará isso por você.

Os cinco níveis

Duas coisas sobre esta tabela são fáceis de passar despercebidas.

O padrão é high, não low e não xhigh. Se você envia uma requisição sem output_config, você obtém high. Isso importa para a previsão de custos: uma requisição intocada no Opus 5 está realizando um trabalho de raciocínio real e cobrando você por isso, enquanto a mesma requisição intocada no Opus 4.8 não fazia raciocínio algum. Essa mudança é uma das duas alterações disruptivas na migração do Opus 4.8 para o Opus 5, e é a mais provável de surpreender uma equipe financeira.

E xhigh é a recomendação para codificação e trabalho agêntico, não max. A Anthropic posiciona xhigh como o ponto de partida para essas cargas de trabalho. max existe acima dele, mas começar lá significa pagar por uma margem da qual você provavelmente não consegue medir um benefício. Comece em xhigh, depois varra para baixo.

O que a recalibração mudou

Aqui está a parte que torna a transferência de configurações entre modelos uma má ideia.

A Anthropic recalibrou o que cada nível de `effort` significa no Opus 5. O rótulo medium no Opus 5 não descreve a mesma quantidade de raciocínio que medium descrevia no Opus 4.8. A orientação da Anthropic é realizar uma nova varredura de `effort` no Opus 5, em vez de portar sua configuração 4.8.

A consequência prática é mais interessante do que o aviso. Nos modelos Opus anteriores, low e medium eram principalmente teóricos para trabalhos sérios: eram baratos, mas também visivelmente piores, então as equipes estacionavam tudo em high ou acima e pagavam por isso. No Opus 5, os níveis mais baixos são significativamente mais fortes do que eram, o que é a primeira vez que low e medium são genuinamente utilizáveis em um modelo de nível Opus para tarefas de produção.

Essa é a verdadeira alavanca de custo no lançamento, e é a que a cobertura da imprensa comprimiu na palavra "alternar". O Opus 5 custa $5 por milhão de tokens de entrada e $25 por milhão de tokens de saída, o mesmo que o Opus 4.8. Os tokens de raciocínio caem no lado da saída dessa conta. Então, a diferença entre executar um pipeline de classificação em high e executá-lo em low não é um erro de arredondamento, é uma grande fração do seu gasto de saída em uma carga de trabalho onde o raciocínio extra nunca estava comprando precisão em primeiro lugar. Nosso detalhamento de preços do Opus 5 tem a tabela de taxas completa, incluindo o desconto de 50% para lote e o mínimo de cache de 512 tokens, ambos acumuláveis com uma configuração de `effort` mais baixa.

Se você está buscando economias em todo um ecossistema Claude, em vez de um único endpoint, as alavancas em como cortar sua conta da API Claude se aplicam aqui também, com o `effort` agora adicionado à lista.

A interação de `xhigh` e `max` com `max_tokens`

`max_tokens` limita os tokens de raciocínio mais os tokens de resposta juntos. É um teto rígido no lado de saída completo da requisição, não apenas no texto visível.

Aumente o `effort` e você aumenta o quanto desse teto o modelo gasta em raciocínio antes de começar a escrever. Leve o `effort` para xhigh ou max enquanto deixa `max_tokens` em um valor que você dimensionou para um modelo que não estava pensando, e o modelo pode queimar o orçamento raciocinando e truncar antes de terminar a resposta. Você obtém uma resposta cortada sem nada obviamente errado na requisição.

A solução é dar espaço. A orientação da Anthropic é começar com max_tokens: 64000 ao executar xhigh ou max no Opus 5:

{
  "model": "claude-opus-5",
  "max_tokens": 64000,
  "output_config": { "effort": "xhigh" },
  "messages": [
    { "role": "user", "content": "Corrigir o teste de integração com falha e explicar a causa raiz." }
  ]
}

Um `max_tokens` alto é um teto, não uma compra. Você é cobrado pelos tokens realmente produzidos, então definir 64000 não significa pagar por 64000. Significa que o modelo não é forçado a parar no meio do pensamento.

O erro 400 que ninguém ainda documentou

Este vai gerar chamados de suporte.

Desabilitar o raciocínio e solicitar um `effort` alto são instruções contraditórias, e o Opus 5 rejeita a combinação diretamente. Enviar thinking: {type: "disabled"} junto com `effort` xhigh ou max retorna um 400, aplicado por requisição:

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "thinking": { "type": "disabled" },
  "output_config": { "effort": "xhigh" }
}

Essa requisição falha. Desabilitar o pensamento limita você a um `effort` high. Então as combinações válidas são:

• Pensamento ativado (padrão) com qualquer um dos cinco níveis.
• Pensamento desativado com low, medium ou high apenas.

O caminho de migração que produz esse erro é previsível: uma equipe transfere thinking: {type: "disabled"} de uma configuração do Opus 4.8 onde era inofensivo, depois aumenta separadamente o `effort` para xhigh porque essa é a recomendação para codificação. Ambas as edições parecem razoáveis isoladamente. Juntas, elas causam um erro 400.

O próprio conselho da Anthropic é não desabilitar o pensamento no Opus 5 de forma alguma. Com o pensamento desativado, dois modos de falha aparecem ocasionalmente: o modelo escreve chamadas de ferramentas como texto simples que nunca são executadas, e tags XML internas vazam para a saída visível. Em um loop agêntico, o texto vazado então contamina as interações posteriores. A maneira recomendada de controlar o custo no Opus 5 é um nível de `effort` mais baixo, não o pensamento desativado. Aprofundamos em ambos os artefatos no guia de prompt do Opus 5.

Como executar uma varredura de esforço em suas próprias avaliações

A Anthropic pede para você refazer a varredura. Aqui está um procedimento que cabe em uma tarde.

1. Congele um conjunto de tarefas. Puxe de 30 a 50 prompts reais dos logs de produção, não exemplos sintéticos. Inclua os casos difíceis com os quais você realmente se preocupa. As diferenças de `effort` desaparecem em tarefas fáceis, e é exatamente por isso que um conjunto de amostras limpo não lhe dirá nada.

2. Anote o critério de aprovação antes de olhar qualquer saída. Testes aprovados, JSON validado contra um esquema, campo extraído corresponde à verdade fundamental, um avaliador humano diz sim ou não. Se seu critério é uma "vibe", sua varredura produzirá uma "vibe".

3. Execute cada prompt em cada nível. Cinco níveis vezes 40 prompts são 200 chamadas. No Opus 5, isso é barato o suficiente para não pensar, e você pode enviá-lo através da API Batch pela metade do preço, já que nada é sensível à latência.

4. Capture três números por execução, não um: aprovado ou reprovado, usage.output_tokens e latência de tempo real. O bloco usage na resposta é onde o sinal de custo real reside, porque ele conta os tokens de raciocínio que você estaria adivinhando de outra forma.

5. Escolha o nível mais barato que atende aos seus critérios, depois confirme-o em um conjunto de validação contra o qual você não ajustou. Equipes que pulam o conjunto de validação tendem a enviar uma configuração ajustada para 40 prompts específicos.

6. Execute novamente no próximo modelo. A razão pela qual esta varredura existe é que os níveis foram recalibrados entre o 4.8 e o 5. Assuma que isso acontecerá novamente.

Comparando níveis lado a lado no Apidog

A parte mecânica de uma varredura é enviar um corpo de requisição cinco vezes com um campo alterado e alinhar o que retorna. Isso é uma boa quantidade de copiar e colar `curl`, e é a parte que o Apidog organiza.

Uma configuração que funciona:

1. Crie uma requisição para o endpoint Anthropic Messages e armazene sua chave como uma variável de ambiente, em vez de colá-la no corpo. As chaves ficam fora de qualquer coisa que você compartilha com a equipe.
2. Salve a requisição funcionando em uma coleção, depois duplique-a cinco vezes e altere apenas output_config.effort em cada cópia.
3. Inspecione o objeto usage em cada resposta para que você possa ver os tokens de saída por nível diretamente, além de cache_read_input_tokens quando estiver verificando se o seu cache está funcionando.
4. Ative o streaming e leia os eventos SSE se quiser observar para onde a latência realmente vai em xhigh versus low.
5. Adicione uma asserção de que stop_reason está presente e não é max_tokens, para que uma resposta xhigh truncada falhe ruidosamente em sua coleção, em vez de parecer silenciosamente uma resposta curta.

Essa última asserção é a que vale a pena configurar primeiro, porque um truncamento em `effort` alto é a coisa mais provável de dar errado. Baixe o Apidog se quiser construir a coleção de comparação enquanto lê. Nada aqui exige isso; apenas supera a manutenção de cinco scripts shell.

O teto honesto

O `effort` torna o Opus 5 mais barato para rodar bem. Não torna o Opus 5 o topo da pilha Claude.

Os próprios números de lançamento da Anthropic para o Opus 5 são fortes: mais que o dobro da pontuação do Opus 4.8 no Frontier-Bench v0.1, aproximadamente 3x o próximo melhor modelo no ARC-AGI 3, e dentro de 0,5% do Fable 5 no CursorBench 3.2 pela metade do preço. Todos esses são números fornecidos pelo fornecedor, publicados pela Anthropic, e nenhum foi reproduzido independentemente até 25 de julho de 2026. Trate-os como afirmações com uma fonte, não como medições neutras, e veja nosso detalhamento de benchmarks do Opus 5 para as ressalvas em cada um.

Acima do Opus 5, o Fable 5 ainda é o modelo mais capaz amplamente lançado da Anthropic, a $10 por milhão de tokens de entrada e $50 por milhão de tokens de saída. E o Opus 5 ainda fica atrás do Mythos 5 em exploração de segurança cibernética e pesquisa biológica autônoma, o que a Anthropic declara diretamente. Executar o Opus 5 em max não fecha nenhuma das lacunas. O resumo honesto é capacidade de classe de fronteira pela metade do preço de fronteira, com um teto nomeado acima dele. Se a diferença de preço vale a pena para sua carga de trabalho é a questão que analisamos em Opus 5 vs Fable 5.

FAQ

Qual é o nível de `effort` padrão no Claude Opus 5? high. Uma requisição sem o campo output_config é executada com `effort` high e pensamento adaptativo ativado.

Quais são os cinco níveis de `effort`? low, medium, high, xhigh e max. A Anthropic recomenda começar em xhigh para codificação e trabalho agêntico, e varrer para baixo a partir daí contra suas próprias avaliações.

Por que minha requisição retorna um erro 400 quando eu defino o `effort` como xhigh? Quase certamente porque você também enviou thinking: {type: "disabled"}. Desabilitar o pensamento limita o `effort` a high, e a combinação é rejeitada por requisição. Remova o bloco de desativação do pensamento ou diminua o `effort` para high ou abaixo.

Posso reutilizar minhas configurações de `effort` do Opus 4.8 no Opus 5? Não. Os níveis foram recalibrados, então o mesmo rótulo significa uma quantidade diferente de raciocínio. A Anthropic pede que você execute uma nova varredura. A lista completa do que mudou está no guia de migração.

Diminuir o `effort` torna as respostas mais curtas? Não. O `effort` controla o raciocínio, não o comprimento visível, e as respostas padrão do Opus 5 são mais longas que as do Opus 4.8. Peça explicitamente concisão no prompt se quiser uma saída mais curta.

Qual max_tokens devo usar em xhigh ou max? Comece em 64000. max_tokens limita o pensamento e a resposta juntos, então um orçamento dimensionado para um modelo que não pensa será truncado. Você só é cobrado pelos tokens produzidos, então o teto alto não custa nada por si só.

Para a folha de especificações completa, matriz de disponibilidade e contexto de preços sobre tudo isso, comece com o que é o Claude Opus 5.