Se você aprendeu a usar o pensamento estendido do Claude configurando budget_tokens, tenho uma novidade que vai te incomodar ou te aliviar. No Opus 4.7, 4.8 e Fable 5, esse parâmetro sumiu. Envie thinking: {type: "enabled", budget_tokens: 8000} para qualquer um deles e você recebe um 400. Todo o modelo de "dar ao modelo uma cota fixa de tokens para pensar" foi substituído por dois novos controles que funcionam melhor e confundem as pessoas no começo. Deixa eu te explicar o que realmente mudou e como dirigir o novo sistema.
O modelo antigo e por que ele morreu
O pensamento estendido com budget_tokens era um teto rígido: você dizia "pense com até N tokens," e o modelo gastava até N tokens raciocinando em um rascunho antes de responder. Funcionava, mas era desajeitado. Você tinha que adivinhar o orçamento por tarefa, e o modelo não conseguia decidir por conta própria que uma pergunta fácil precisava de quase nenhum raciocínio enquanto uma difícil precisava de muito. Você estava fazendo o trabalho do modelo.
Pensamento adaptativo: o modelo decide quanto pensar
O substituto é thinking: {type: "adaptive"}. Com o pensamento adaptativo ativado, o modelo decide por requisição quanto pensar e quando — incluindo intercalar pensamento entre chamadas de ferramentas automaticamente, sem precisar de cabeçalho beta. Sem orçamento para ajustar. Uma consulta simples recebe uma resposta rápida; um problema de raciocínio com múltiplas etapas recebe pensamento mais profundo. O modelo se calibra sozinho.
Uma coisa que confunde todo mundo: no Opus 4.7 e 4.8, o pensamento adaptativo está desativado por padrão. Se você simplesmente omitir o campo thinking, o modelo funciona sem pensar. Você tem que definir thinking: {type: "adaptive"} explicitamente para ativá-lo. (Fable 5 é a exceção — o pensamento está sempre ativado lá, e um disabled explícito na verdade retorna 400.)
Effort: o quão duro trabalhar no geral
O segundo controle é effort, e é um eixo diferente do pensamento. Ele fica dentro de output_config, não no nível superior:
output_config: {effort: "high"}
Os níveis são low, medium, high, xhigh e max. O padrão é high. O effort controla a profundidade do pensamento e o gasto total de tokens juntos — effort mais baixo significa menos chamadas de ferramentas e mais consolidadas, menos preâmbulo, confirmações mais curtas. Mais alto significa mais exploração, mais verificação, mais minuciosidade.
As recomendações práticas de trabalhar com esses parâmetros:
xhighé o ponto ideal para codificação e trabalho agêntico — é literalmente o padrão no Claude Code.highé o mínimo para qualquer coisa sensível à inteligência.mediumelowpara trabalho rotineiro ou sensível à latência, subagentes, classificação simples.maxquando a correção importa mais do que o custo e você está disposto a pagar pelo teto.
Aqui está uma descoberta contra-intuitiva: no Opus 4.8, não aumente reflexivamente o effort para xhigh. O teto de inteligência é mais alto do que nos modelos anteriores, então high costuma ser suficiente, e no trabalho agêntico, um effort mais alto no início pode reduzir o custo total porque o modelo planeja melhor e leva menos turnos. A relação não é monótona. Faça um varredura de medium, high e xhigh nas suas próprias avaliações e meça. Já vi medium igualar xhigh em tarefas onde a deliberação extra era puro desperdício.
Uma sutileza sobre a saída do pensamento que vai desperdiçar a sua tarde
O pensamento que o modelo faz e o pensamento que você vê são coisas separadas. No Opus 4.7, 4.8 e Fable 5, os blocos de pensamento ainda aparecem no fluxo de resposta, mas seu texto fica vazio por padrão — display tem como padrão "omitted". O raciocínio acontece e é cobrado da mesma forma; você simplesmente não recebe o texto de volta.
Então, se você transmite raciocínio para seus usuários e migrou do 4.6, sua UI de "thinking" de repente não renderiza nada e parece uma longa pausa congelada antes da saída. A correção é um parâmetro:
thinking: {type: "adaptive", display: "summarized"}
Isso te dá um resumo legível do raciocínio. Observe que o nome do campo no bloco ainda é thinking — não vá renomear seu handler de resposta, os dados ficam vazios a menos que você opte por recebê-los. E a cadeia de pensamento bruta nunca é retornada nesses modelos de qualquer maneira; summarized é o máximo que você consegue.
Orçamentos de tarefa: a nova forma de limitar um loop inteiro
Há mais uma alavanca, em beta, para loops agênticos: task_budget. Isso não é o antigo budget_tokens de volta dos mortos — é diferente. Um orçamento de tarefa diz ao modelo quantos tokens ele tem para um loop agêntico inteiro (pensamento mais chamadas de ferramentas mais saída), e o modelo vê uma contagem regressiva em execução e regula o próprio ritmo para terminar com elegância em vez de ser cortado abruptamente:
output_config: {effort: "high", task_budget: {type: "tokens", total: 64000}}
Requer o cabeçalho beta task-budgets-2026-03-13, o mínimo é 20.000 tokens, e você deve usar streaming porque um max_tokens grande correria o risco de timeout. A distinção chave: max_tokens é um teto rígido, aplicado, por resposta que o modelo não conhece. task_budget é uma sugestão suave, cumulativa, de loop inteiro que o modelo conhece e planeja em torno dela. Use task_budget para fazer o modelo se autorregular; use max_tokens como a proteção rígida de último recurso.
Como eu configuro esses parâmetros agora na prática
Para um endpoint de chat ou classificação: adaptive desativado ou thinking: {type: "disabled"} onde for compatível, effort: "low", max_tokens pequeno. Barato e rápido.
Para um agente de codificação: thinking: {type: "adaptive"}, effort: "xhigh", max_tokens de streaming generoso, e um task_budget se for um loop autônomo longo.
Para uma tarefa de raciocínio difícil de uma única tentativa onde me importo com acertar: adaptive ativado, effort: "high" e testo max, display: "summarized" para que eu possa auditar como chegou lá.
O modelo mental que faz tudo isso fazer sentido: o pensamento adaptativo é quando e quanto raciocinar, o effort é o quão duro trabalhar no geral, o orçamento de tarefa é quanto gastar no trabalho todo. Três controles, três perguntas. Pare de adivinhar alocações de tokens e deixe o modelo fazer o que agora faz bem — decidir por conta própria.