AI Watch · Prompt engineering
Adaptive thinking: stop setting a budget, start setting an effort
Claude Opus 5.5 shipped with "always-on adaptive thinking" as one of its headline changes. That's a good excuse to look at how thinking actually works on current Claude models today, and what changed in how you're supposed to prompt for it.
1. What actually changed
Claude Opus 5.5 launched on September 22, 2026 as Anthropic's newest Opus-tier model: roughly the same quality bar as Fable 5.1 on most work, about 40% cheaper to run, a 1M-token context window, and — the detail that matters for this lesson — adaptive thinking that's always on and can't be turned off. On this model, reasoning between tool calls always shows up as thinking blocks, and there's no request-level switch to disable it entirely.
This isn't a brand-new feature invented for Opus 5.5. Adaptive thinking has been the default reasoning mode since Claude 4.6, replacing the older approach where developers manually set a budget_tokens value to cap how many tokens Claude could spend "thinking" before answering. What Opus 5.5 changes is that the always-on behavior is now mandatory rather than optional, and that manual budgets are fully removed as an option on the newest models — not just discouraged.
2. Adaptive thinking vs the old manual budget
The mental model shift is simple, even if the mechanics took a couple of model generations to land:
| Old approach | Current approach |
|---|
You (the developer) decide upfront how many tokens Claude is allowed to spend thinking, via budget_tokens. | Claude decides, per request, whether reasoning would help and roughly how much of it to do — you only nudge the dial. |
| Static: the same budget applies whether the question is trivial or genuinely hard. | Dynamic: a one-line factual question gets little or no thinking; a multi-step agentic task gets more. |
| Risk of either wasting tokens on easy requests or starving hard ones. | Risk shifts to "Claude thinks more than I want" on complex system prompts — which is solvable with steering (section 3). |
On Claude Sonnet 5 and Claude 4.7+ models, setting budget_tokens manually returns an error rather than being silently ignored — it's not deprecated-but-tolerated, it's removed. If you have older integration code that still sets a manual thinking budget, it needs to be rewritten around the effort parameter described next.
3. The effort parameter: your real dial now
Instead of a token budget, the practical control surface today is the effort parameter, which sets how aggressively Claude leans into reasoning:
- Low — minimizes thinking, skips it outright for simple tasks. Cheapest, fastest, best for classification, extraction, or anything close to a lookup.
- Medium (the default on Opus 5.5) — may skip thinking for simple queries but engages it for anything that looks like it needs a few steps of reasoning.
- High — thinks deeply almost every time. Good default for agentic loops, non-trivial coding tasks, and multi-step tool use.
- Max — always thinks, no constraints. Reserved for the hardest problems where cost and latency are secondary to correctness.
You still get a hard ceiling if you need one: max_tokens caps the total output — thinking tokens plus the visible response — even though it no longer lets you carve out a dedicated thinking-only allowance the way budget_tokens did.
Practical rule of thumb: start at the model's default effort level, measure quality on your actual workload, and only move the dial up if you can point to specific failures that more reasoning would fix. Cranking effort to max "just in case" mostly buys you latency and cost, not correctness.
4. Steering thinking with plain language
Because Claude decides on its own whether to think, you sometimes need to steer that decision directly in the prompt — no API parameter required. Two patterns documented by Anthropic:
- Appending "Please think hard before responding" to a user message pushes Claude toward reasoning on that specific turn, even at a lower effort setting.
- Appending "Answer directly without deliberating" suppresses thinking for that turn — useful when a large or complex system prompt is making Claude over-think trivial follow-up questions.
This matters in practice because system prompts with a lot of instructions, tools, and context (the kind you'd write for an agent) tend to trigger more thinking than a bare user question would, even when a given turn is simple. Plain-language steering is the fix, not a bigger or smaller effort value applied globally.
5. When extended thinking is actually worth it
Extended thinking has a real cost: it adds latency and consumes tokens even when it doesn't change the final answer. Anthropic's own guidance is narrower than "turn it up for anything that feels important" — it recommends reasoning for genuinely multi-step problems: agentic workflows with several tool calls in sequence, non-trivial coding tasks, math or logic puzzles with multiple dependent steps, and long-horizon agent loops where an early mistake compounds.
Conversely, thinking rarely helps with single-step lookups, short factual questions, simple formatting or rewriting tasks, or anything where the answer is essentially a retrieval, not a derivation. Forcing thinking on those doesn't just waste money — it can also make Claude second-guess a correct, simple answer into something more convoluted.
6. Putting it into practice
If you're building a simple assistant (FAQ bot, classifier, data extractor): leave effort at its default or drop it to low, and don't manually force thinking — the cost/latency tradeoff isn't worth it for single-step work.
If you're building an agent (multi-step tool use, coding assistant, research loop): favor high effort as a baseline, and use "answer directly without deliberating" selectively on turns you know are trivial (a confirmation, a simple lookup) so you're not paying the thinking tax on every single step.
If you're migrating old code that sets budget_tokens against Sonnet 5 or newer models: replace it with the effort parameter and re-test — the manual budget path isn't just legacy, it now returns a hard error.
The broader pattern behind this change fits where prompt engineering has been heading all year: less time spent hand-tuning low-level knobs, more time spent describing what you actually want and letting the model figure out the "how much effort does this deserve" part on its own.
IA Watch · Prompt engineering
Adaptive thinking: pare de definir um orçamento, comece a definir um esforço
O Claude Opus 5.5 chegou com "adaptive thinking sempre ligado" como uma das mudanças de destaque. É um bom gancho pra entender como o raciocínio realmente funciona nos modelos atuais do Claude, e o que mudou em como você deve pedir por ele.
1. O que realmente mudou
O Claude Opus 5.5 foi lançado em 22 de setembro de 2026 como o modelo mais novo da Anthropic no nível Opus: qualidade próxima da do Fable 5.1 na maior parte do trabalho, cerca de 40% mais barato pra rodar, janela de contexto de 1M de tokens e — o detalhe que interessa pra essa lição — adaptive thinking sempre ligado, sem opção de desligar. Nesse modelo, o raciocínio entre chamadas de ferramenta sempre aparece como blocos de "thinking", e não existe mais um switch no nível da requisição pra desativar isso por completo.
Isso não é um recurso novo inventado pro Opus 5.5. O adaptive thinking já é o modo de raciocínio padrão desde o Claude 4.6, substituindo a abordagem antiga em que desenvolvedores definiam manualmente um valor de budget_tokens pra limitar quantos tokens o Claude podia gastar "pensando" antes de responder. O que o Opus 5.5 muda é que o comportamento sempre-ligado agora é obrigatório, não opcional, e que orçamentos manuais foram totalmente removidos como opção nos modelos mais novos — não apenas desencorajados.
2. Adaptive thinking vs o antigo orçamento manual
A mudança de modelo mental é simples, mesmo que a mecânica tenha levado algumas gerações de modelo pra se consolidar:
| Abordagem antiga | Abordagem atual |
|---|
Você (o desenvolvedor) decide de antemão quantos tokens o Claude pode gastar pensando, via budget_tokens. | O Claude decide, a cada requisição, se raciocinar ajudaria e mais ou menos quanto disso fazer — você só ajusta o direcionamento. |
| Estático: o mesmo orçamento vale tanto pra uma pergunta trivial quanto pra uma tarefa genuinamente difícil. | Dinâmico: uma pergunta factual de uma linha recebe pouco ou nenhum raciocínio; uma tarefa agêntica de vários passos recebe mais. |
| Risco de desperdiçar tokens em requisições fáceis ou de limitar demais as difíceis. | O risco muda pra "o Claude pensa mais do que eu queria" em system prompts complexos — o que se resolve com direcionamento por linguagem (seção 3). |
No Claude Sonnet 5 e nos modelos 4.7+, definir budget_tokens manualmente retorna um erro em vez de ser silenciosamente ignorado — não é algo "descontinuado mas tolerado", é removido de fato. Se você tem código de integração antigo que ainda define um orçamento manual de thinking, ele precisa ser reescrito em torno do parâmetro effort descrito a seguir.
3. O parâmetro effort: seu controle real hoje
Em vez de um orçamento de tokens, a superfície de controle prática hoje é o parâmetro effort, que define o quão agressivamente o Claude investe em raciocínio:
- Low (baixo) — minimiza o raciocínio, pula ele completamente em tarefas simples. Mais barato, mais rápido, ideal pra classificação, extração, ou qualquer coisa próxima de uma consulta direta.
- Medium (médio) (o padrão no Opus 5.5) — pode pular o raciocínio em perguntas simples, mas engaja ele pra qualquer coisa que pareça precisar de alguns passos de lógica.
- High (alto) — pensa profundamente quase sempre. Bom padrão pra loops agênticos, tarefas de código não triviais, e uso de ferramentas em múltiplos passos.
- Max — sempre pensa, sem restrições. Reservado pros problemas mais difíceis, onde custo e latência são secundários frente à correção.
Você ainda tem um limite rígido se precisar de um: max_tokens limita a saída total — tokens de thinking mais a resposta visível — ainda que ele não permita mais reservar uma cota dedicada só pro thinking como o budget_tokens fazia.
Regra prática: comece no nível de esforço padrão do modelo, meça a qualidade na sua carga de trabalho real, e só suba o nível se conseguir apontar falhas específicas que mais raciocínio resolveria. Colocar o esforço no máximo "por garantia" geralmente compra latência e custo, não correção.
4. Direcionando o raciocínio com linguagem simples
Como o Claude decide sozinho se vai pensar, às vezes você precisa direcionar essa decisão diretamente no prompt — sem precisar de nenhum parâmetro de API. Dois padrões documentados pela Anthropic:
- Adicionar "Please think hard before responding" (pense bem antes de responder) numa mensagem do usuário empurra o Claude pro raciocínio naquele turno específico, mesmo com um nível de effort mais baixo.
- Adicionar "Answer directly without deliberating" (responda direto, sem deliberar) suprime o raciocínio naquele turno — útil quando um system prompt grande ou complexo está fazendo o Claude pensar demais em perguntas de acompanhamento triviais.
Isso importa na prática porque system prompts com muitas instruções, ferramentas e contexto (o tipo que você escreveria pra um agente) tendem a disparar mais raciocínio do que uma pergunta simples de usuário disparia sozinha, mesmo quando um turno específico é trivial. O direcionamento por linguagem simples é o ajuste certo aqui — não um valor de effort maior ou menor aplicado de forma global.
5. Quando extended thinking realmente vale a pena
Extended thinking tem um custo real: adiciona latência e consome tokens mesmo quando não muda a resposta final. A própria orientação da Anthropic é mais restrita do que "ativa pra tudo que parece importante" — ela recomenda raciocínio pra problemas genuinamente de múltiplos passos: fluxos agênticos com várias chamadas de ferramenta em sequência, tarefas de código não triviais, problemas de matemática ou lógica com passos dependentes entre si, e loops de agente de longo horizonte, onde um erro cedo se acumula.
Por outro lado, o raciocínio raramente ajuda em consultas de um passo só, perguntas factuais curtas, tarefas simples de formatação ou reescrita, ou qualquer coisa em que a resposta é essencialmente uma busca, não uma dedução. Forçar raciocínio nesses casos não só desperdiça dinheiro — também pode fazer o Claude questionar uma resposta correta e simples até transformá-la em algo mais complicado do que precisava ser.
6. Colocando em prática
Se você está construindo um assistente simples (bot de FAQ, classificador, extrator de dados): deixe o effort no padrão ou reduza pra low, e não force raciocínio manualmente — o trade-off de custo/latência não compensa pra trabalho de um passo só.
Se você está construindo um agente (uso de ferramentas em múltiplos passos, assistente de código, loop de pesquisa): prefira effort alto como base, e use "answer directly without deliberating" seletivamente em turnos que você sabe que são triviais (uma confirmação, uma busca simples), pra não pagar o "imposto do raciocínio" em cada passo único.
Se você está migrando código antigo que define budget_tokens contra o Sonnet 5 ou modelos mais novos: substitua pelo parâmetro effort e teste de novo — o caminho de orçamento manual não é só legado, agora ele retorna um erro rígido.
O padrão maior por trás dessa mudança combina com pra onde o prompt engineering vem indo o ano inteiro: menos tempo ajustando manualmente controles de baixo nível, mais tempo descrevendo o que você realmente quer e deixando o modelo decidir sozinho "quanto esforço isso merece".