Se você atualizou seu código para o Claude Opus 5 e começou a receber erro 400 do nada, a causa provavelmente é uma combinação específica: thinking desabilitado junto com effort xhigh ou max. É uma regra nova, documentada oficialmente pela Anthropic, que não existia no Opus 4.8.
O que significa esse erro 400 no Claude Opus 5?
Significa que sua requisição está pedindo duas coisas incompatíveis ao mesmo tempo. A documentação oficial da Anthropic é direta sobre isso:
"On Claude Opus 5, thinking cannot be disabled atxhighormaxeffort: requests that setthinking: {"type": "disabled"}at those levels return a 400 error." (platform.claude.com/docs/en/build-with-claude/effort, consultado em 09/09/2026)
Traduzindo: no Opus 5, você só pode desligar o thinking se o effort estiver em high ou abaixo. Em xhigh ou max, o modelo exige thinking ativo, e a API rejeita a requisição antes de processar qualquer coisa.
Por que isso quebrou justo quem migrou do Opus 4.8?
Porque no Opus 4.8 essa trava não existe: desabilitar o thinking era independente do nível de effort, então dava para rodar max com thinking desligado sem problema. Quem tinha esse padrão no código (comum em pipelines que desabilitam thinking pra reduzir latência ou forçar resposta em formato fixo) e trocou o model para claude-opus-5 sem mexer em mais nada começou a tomar 400 exatamente nas chamadas de effort mais alto, que costumam ser as mais críticas do fluxo.
Vale notar também que, se você simplesmente omitir o campo thinking em vez de desabilitá-lo, o comportamento muda de modelo pra modelo: no Opus 4.8 a requisição roda sem thinking; no Opus 5, a mesma requisição roda com thinking adaptativo por padrão. Isso afeta o orçamento de max_tokens, que no Opus 5 é um teto rígido sobre thinking mais texto de resposta somados.
Como corrigir agora, com o comando certo
Duas saídas, dependendo do que você realmente precisa.
Se você pode conviver com thinking ativo (a maioria dos casos), tire o campo thinking da requisição e deixe o xhigh ou max como está:
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" \
-d '{
"model": "claude-opus-5",
"max_tokens": 65536,
"output_config": {"effort": "xhigh"},
"messages": [{"role": "user", "content": "..."}]
}'A própria documentação recomenda começar em 64 mil tokens de max_tokens pra tarefas em xhigh ou max no Opus 5, porque o modelo precisa de espaço pra pensar e agir em ferramentas e subagentes dentro desse mesmo teto.
Se você realmente precisa de thinking desligado (formato de saída fixo, por exemplo), a saída é baixar o effort para high ou menos, não forçar o nível alto:
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" \
-d '{
"model": "claude-opus-5",
"max_tokens": 4096,
"thinking": {"type": "disabled"},
"output_config": {"effort": "high"},
"messages": [{"role": "user", "content": "..."}]
}'Esse não é um bug isolado: effort por modelo errado já quebrou produção antes
O caso do Opus 5 é novo, mas a categoria do problema não é. Em maio de 2026, o projeto open source TauricResearch/TradingAgents relatou exatamente o mesmo tipo de erro em outro contexto: um pipeline que roteava entre Claude Haiku 4.5 (pra tarefas rápidas) e modelos Opus maiores (pra raciocínio pesado) mandava o parâmetro effort pra todas as chamadas, sem checar se o modelo daquela vez o suportava. Resultado, direto da issue:
{"type": "error", "error": {"type": "invalid_request_error",
"message": "This model does not support the effort parameter."}}Mesma raiz nos dois casos: o código assume uma capacidade fixa por família de modelo, e a API valida por modelo específico. Cada lançamento pode mudar a regra sem avisar seu pipeline.
| Modelo | Aceita effort? | Suporta max | Suporta xhigh | thinking desabilitado bloqueado em xhigh/max |
|---|---|---|---|---|
claude-opus-5 | Sim, os 5 níveis | Sim | Sim | Sim, retorna 400 |
claude-opus-4-8 | Sim | Sim | Sim | Não documentado pra este modelo |
claude-sonnet-5 | Sim | Sim | Sim | Não documentado pra este modelo |
claude-sonnet-4-6 | Sim | Sim | Não | Não se aplica (sem xhigh) |
claude-haiku-4-5 | Não | N/A | N/A | Erro já ocorre no parâmetro effort |
A trava específica de thinking bloqueado em xhigh/max está documentada oficialmente só pra Opus 5. A Anthropic pode estender a mesma regra pra outros modelos sem aviso prévio, então tratar isso como exceção pontual do Opus 5 é arriscado.
Como checar, modelo por modelo, sem adivinhar
Em vez de manter essa tabela na cabeça (ou hardcoded no seu código), a Models API devolve a capacidade real de cada modelo, incluindo effort:
curl https://api.anthropic.com/v1/models \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01"Cada item de data traz um objeto capabilities.effort com um booleano supported por nível (low, medium, high, max, xhigh). Checar esse campo antes de montar a requisição, em vez de aplicar o mesmo effort pra qualquer modelo do seu roteamento, evita as duas classes de erro deste artigo de uma vez.
Esse erro acontece pra quem usa o Verboo Code?
Não pelos comandos do próprio CLI. Lendo o código-fonte de src/commands/effort/effort.tsx e src/utils/effort.ts no repositório verbeux-ai/code: o comando /effort não expõe nenhuma forma de desabilitar o thinking, só escolhe o nível de effort dentro do que o modelo ativo suporta. E, no modo de conta Claude nativa, essa lista de níveis válidos vem de getClaudeNativeModel(model)?.supportedReasoningLevels, buscado ao vivo na Models API real da Anthropic, exatamente o mesmo capabilities.effort mencionado acima.
Na prática, pedir um nível que o modelo ativo não suporta no Verboo Code não vira um 400 cru: vira uma destas duas mensagens, direto no terminal:
Invalid reasoning level: max. Available for claude-haiku-4-5: , auto
Reasoning is not supported for claude-haiku-4-5Quem esbarra no erro 400 de verdade normalmente está escrevendo a própria integração com a API, fora do CLI, que é onde a checagem de capabilities.effort precisa ser feita manualmente.
Se o seu código já roteia entre modelos diferentes por tarefa, esse é o tipo de trava que vai voltar a te pegar no próximo lançamento. Na Verboo Code o /effort lê a capacidade real de cada modelo antes de enviar a chamada, com tokens ilimitados pra rodar o teste quantas vezes precisar até achar o nível certo.
