o problema
Chain of thought começou como truque de prompt. Você escrevia “pense passo a passo”, embrulhava o rascunho em tags <thinking> e a entrega em <answer> para não misturar as duas, e torcia. O raciocínio era texto que você arrancava do modelo com jeitinho, não uma capacidade que você configurava. Funcionava, mas dependia de palavra escolhida, de exemplo bem posto e de o modelo não confundir rascunho com resposta final.
A geração seguinte trocou o truque por um orçamento. Extended thinking pedia budget_tokens: você declarava, antes de ver a pergunta, quantos tokens de raciocínio aquela chamada teria direito. O número era o mesmo para uma pergunta trivial e para um refactor de três arquivos. Errar para cima queimava latência e dinheiro. Errar para baixo cortava o raciocínio no meio. E o número tinha que ser escolhido pelo lado que menos sabe sobre a dificuldade da tarefa: o seu.
a ideia
Tirar a decisão das suas mãos. Com adaptive thinking (thinking: {type: "adaptive"}), o modelo decide quando pensar e quanto, calibrando por duas coisas: o parâmetro effort que você define e a complexidade da query. Em pergunta fácil ele responde direto, sem gastar raciocínio. A Anthropic afirma que, em avaliações internas, adaptive thinking bate extended thinking de forma confiável, e recomenda a migração.
O efeito prático inverte o trabalho de quem escreve prompt. Antes você lutava para o modelo raciocinar. Agora ele raciocina por padrão em boa parte dos casos, e a maior parte do guia é sobre conter: como fazer pensar menos, verificar menos, explorar menos, delegar menos para subagente.
como funciona
A configuração é curta: thinking vira adaptive e o antigo orçamento migra para output_config: {effort: "high"}. O budget_tokens continua funcional no Opus 4.6 e no Sonnet 4.6, mas está deprecado, e no Claude 4.7 em diante devolve 400. Se você precisa de teto duro, o teto é max_tokens.
O default varia por modelo, e isso é a parte que quebra migração silenciosamente. No Opus 4.6 até o 4.8 e no Sonnet 4.6, omitir o parâmetro thinking deixa o raciocínio desligado. No Opus 5 e no Sonnet 5, omitir deixa ligado — e no Opus 5 só dá para desligar em effort high ou abaixo. Nos Fable e Mythos 5 e 5.1, thinking é sempre ligado, com ou sem parâmetro.
O gatilho é promptável. Se o modelo pensa mais do que você quer, o guia sugere dizer isso em texto: que thinking adiciona latência e só se justifica em problema de múltiplos passos, e que na dúvida responda direto. Na direção oposta, “pense a fundo” costuma render mais que um roteiro escrito à mão. Exemplos multishot com tags <thinking> também funcionam: o modelo generaliza o padrão de raciocínio dos exemplos para os próprios blocos.
O chain of thought manual sobreviveu como fallback, para quando thinking está desligado — com a ressalva de que no Opus 5 é melhor manter thinking ligado em effort baixo, porque com ele desligado o modelo às vezes vaza tags XML internas na saída visível.
o que isso custou
O primeiro custo é a portabilidade do conselho. A própria página avisa: quando uma técnica nomeia um modelo, trate o resultado como medido naquele modelo e reteste nos seus evals antes de aplicar em outro. O guia é uma lista de exceções nominais. Autoverificação pega erro em código e matemática, exceto no Opus 5, onde a mesma instrução vira over-verification e a recomendação é remover. O Opus 4.5, com extended thinking desligado, é sensível à palavra “think” e responde melhor a “consider” ou “reason through”. O bloco anti-markdown, que ajuda nos outros, suprime estrutura necessária no Fable 5.1.
O segundo custo é o controle de gasto. O Opus 4.6 explora mais no começo, principalmente em effort alto, o que costuma melhorar o resultado final e às vezes só infla tokens de thinking e atrasa a resposta. O remédio agora é indireto: baixar effort ou pedir em texto que o modelo escolha uma abordagem e siga com ela em vez de revisitar decisões. Não existe mais o número que você fixa.
O terceiro é estrutural. O histórico virou append-only. Blocos de thinking precisam voltar exatamente como a api devolveu, e no Fable 5.1 modificar a conversa antes de um bloco dá erro ou derruba o bloco. Editar mensagens antigas, reconstruir system ou tools, resumir turnos in-place — tudo isso invalida os blocos posteriores. Quem escreveu harness que compacta contexto reescrevendo o array de mensagens vai reescrever o harness.
onde isso aparece hoje
A consequência mais visível é organizacional: prompt engineering de raciocínio deixou de ser uma página só e virou uma página por modelo, mais uma tabela dizendo o que muda em cada um. A página geral existe para o que sobrevive à troca de modelo; o resto está nas específicas.
O prompt chaining explícito encolheu para os casos em que você precisa inspecionar a saída intermediária ou impor um pipeline — com adaptive thinking e orquestração de subagente, o raciocínio de múltiplos passos acontece dentro de uma chamada. O padrão que continua valendo é o de autocorreção: gerar rascunho, revisar contra critério, refinar, cada etapa em uma chamada separada para você poder logar, avaliar ou ramificar.