Prompting Claude's Extended Thinking

TL;DR: "Extended thinking" now names two different mechanisms depending on the model: a deprecated manual token budget on Claude 4.6 and earlier, and adaptive thinking with an effort parameter on 4.7 and later. Thinking tokens always count toward max_tokens. Effort shapes volume, not length. On current Claude models, the more common mistake is prompting for more deliberation than the model needs.

What does "Claude's extended thinking" actually mean right now?

It depends entirely on which model you're calling, and Anthropic's own documentation has quietly split the feature in two. If you learned "extended thinking" as a single mechanism with a budget_tokens number you tune, that description is now only true for a shrinking set of models.

Anthropic's docs are direct about the current state: manual extended thinking with budget_tokens is deprecated on the Claude 4.6 models (requests using it "still succeed" for now), and on anything newer, "Claude 4.7 and later models do not support it and reject requests that use it, returning a 400 error." On Claude 4.5 and earlier models that support thinking, it's the only mode available. Everything newer either deprecates it or refuses it outright, replaced by adaptive thinking, where Claude decides for itself whether and how much to think, steered by a separate effort parameter.

Here's the current landscape, straight from Anthropic's per-model configuration table:

That conditional case on Opus 5 has a specific shape: it accepts disabled at effort high or below, but combining disabled with xhigh or max effort returns its own separate 400 error.

The practical upshot: if you're on Opus 4.5, Sonnet 4.5, or Haiku 4.5, you're stuck with the manual budget for now, and that's fine. It's the only mode those models have. If you're on anything from the 4.6 generation forward, you should be steering with effort, not a hand-tuned token count, and the rest of this guide assumes that's your target.

How does Claude's token accounting for thinking actually work?

This is the part that trips people up, and it applies whether you're on the old manual mode or the new adaptive one: thinking is not free real estate outside your token budget.

On manual mode, budget_tokens must be set lower than max_tokens, and Anthropic's own rule explains why: "Thinking tokens count toward the max_tokens limit for the turn, so the budget must leave room for the final response." The one exception is interleaved thinking between tool calls, where the budget can span multiple thinking blocks across a turn. Beyond that exception, the arithmetic is fixed: whatever you set for thinking comes out of the same pool as your visible answer.

Anthropic is also explicit that the number you set is a ceiling, not a promise Claude will use it: "The budget is a target rather than a strict cap. Actual token usage varies with the task, and Claude may stop reasoning well before the budget is exhausted; max_tokens remains the hard ceiling on total output." Claude might think for 800 tokens against a 10,000-token budget on an easy question, or push close to the limit on a genuinely hard one. The budget bounds the maximum; it doesn't guarantee the spend.

On adaptive-thinking models the same physics apply, just with a different dial: tokens spent thinking are billed as output tokens and count against max_tokens for the current turn regardless of which mode generated them. What differs by model is whether prior turns' thinking blocks also occupy context window space going forward: some models keep them (and bill them as input on later turns), others strip them automatically. Either way, max_tokens is described as "enforced as a strict limit" on the turn that generates the thinking.

What does the effort parameter actually control?

Not response length — that's the single most common misreading of it, and Anthropic corrects it directly in the parameter's own docs: "Effort controls thinking volume, not visible response length: on Claude Opus 5, changing effort does not reliably shorten responses", so if you actually want a shorter answer, prompt for length explicitly rather than reaching for effort.

What effort does control is how many tokens Claude spends across the entire response: thinking, tool calls, and the final text together, across five levels:

By default, "Claude uses high effort, spending as many tokens as needed for excellent results". Setting it explicitly to high changes nothing: Anthropic's docs confirm it "produces exactly the same behavior as omitting the effort parameter entirely." Not every model supports every level; xhigh and max availability varies, and per-model recommendations differ meaningfully. Claude Sonnet 4.6, for instance, is explicitly recommended to run at medium effort by default rather than the API's own high default, for a better balance of speed and quality on that particular model.

Effort and the thinking parameter are two separate knobs that interact: thinking governs whether Claude reasons in dedicated blocks at all, and effort governs how much work goes into the whole response, thinking included. Anthropic is direct that these aren't interchangeable: "Don't pass adaptive as an effort value: adaptive is a thinking mode, not an effort level." If you need a hard ceiling on spend rather than a behavioral nudge, max_tokens is the strict limit; effort is soft guidance layered on top of it.

How do you migrate from a fixed thinking budget to adaptive thinking plus effort?

If you're moving a working prompt off a model that only understood budget_tokens, the mapping is small: you remove the budget and add an effort level.

// Before: manual extended thinking with a fixed budget
{
  "model": "claude-sonnet-4-5-20250929",
  "max_tokens": 16000,
  "thinking": { "type": "enabled", "budget_tokens": 10000 }
}

// After: adaptive thinking with effort
{
  "model": "claude-opus-4-8",
  "max_tokens": 16000,
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "high" }
}

Expect a behavioral shift alongside the syntax change, not just a rename. With a fixed budget, Claude thinks on every single request whether the question warrants it or not. With adaptive thinking, Claude decides per request; at lower effort levels it may skip thinking entirely on easy inputs, which is usually what you want but can surprise you if you were relying on thinking always firing.

Where does over-prompting quietly wreck a thinking model's reasoning?

This is the practical failure that costs people the most tokens and latency, and it comes from carrying forward instructions written for an older, more conservative model. Anthropic's own prompting guidance names the pattern directly: newer Claude models do "more upfront exploration than previous models", especially at higher effort settings. The model gathers context and pursues multiple threads without being explicitly told to, because it's genuinely more capable of deciding that's warranted.

If your prompts previously nudged Claude toward more thoroughness, that guidance is now doing the opposite of what you want. Anthropic's fix is specific:

• Replace blanket defaults with more targeted instructions. Swap a rule that always defaults to a tool for guidance that names the situation where the tool actually helps.
• Remove over-prompting outright. Tools that undertriggered on older models will likely trigger correctly now; a leftover instruction telling Claude to reach for a tool whenever it's unsure now causes overtriggering instead of fixing the undertriggering it was written for.
• Use effort as a fallback, not your first lever. If Claude is still overly aggressive after tightening the prompt, drop to a lower effort level rather than adding more constraining prose.

The same principle applies to how much structure you hand Claude for the reasoning itself. Anthropic's guidance argues for less scaffolding, not more: a prompt that just says "think thoroughly" often produces better reasoning than a hand-written, step-by-step plan, because, in their own words, "Claude's reasoning frequently exceeds what a human would prescribe." That's a genuinely counterintuitive result if you learned prompting on a model that needed every step spelled out, and it's the clearest version of the pattern this whole guide is pointing at: less instruction, more room for the model to actually think.

Two model-specific wrinkles worth knowing before you copy a pattern across models. When thinking is disabled, Claude Opus 4.5 is unusually sensitive to the literal word "think" and its variants: Anthropic suggests "consider," "evaluate," or "reason through" instead in that specific case. And Claude Opus 5 verifies its own work well without being told to, so a leftover self-check instruction telling it to double-check its answer before finishing, carried over from a prompt tuned for an older model, can cause over-verification on Opus 5 specifically: extra tokens and latency for no quality gain. Anthropic's recommendation there is to remove the instruction rather than rewrite it. If you still want manual step-by-step reasoning as a fallback when thinking is off, <G slug="chain-of-thought">chain-of-thought</G> prompting with structured tags still works — see our guide to using XML tags in Claude prompts for the pattern.

How does this compare to OpenAI's and Google's reasoning-token accounting?

The underlying constraint holds across all three major reasoning-capable vendors: reasoning tokens are real tokens that cost real money, and they count against a cap. What differs is how explicitly each documents the boundary and what happens when you hit it.

OpenAI's own reasoning guide is direct about the risk. The max_output_tokens parameter limits total generation, "including reasoning tokens, visible output tokens, and non-visible formatting tokens". Hit that cap while the model is still reasoning, and here's the specific warning OpenAI publishes: "This might occur before any visible output tokens are produced, meaning you could incur costs for input and reasoning tokens without receiving a visible response." The stated mitigation is blunt: reserve headroom. OpenAI's own guide "recommends reserving at least 25,000 tokens for reasoning and outputs when you start experimenting with these models."

Google is the outlier, and it's worth stating carefully rather than guessing. Gemini's own API reference documents thoughtsTokenCount as a distinct field in the usage object: "Output only. Number of tokens of thoughts for thinking models." That's separate from candidatesTokenCount, and rolls both into totalTokenCount ("prompt + thoughts + response candidates"). But the maxOutputTokens field is documented only as "The maximum number of tokens to include in a response candidate." Nothing in that description states whether a generation can be cut short by thinking alone, the way Claude's and GPT's can. Whether Gemini's output cap can be exhausted purely by thinking, before any visible text, isn't something the reference documents either way — so don't assume it behaves like Claude or GPT here without testing your own case.

A copy-paste template for steering when Claude thinks

Two levers, used in the right order, cover almost every real steering need: set effort for your workload's default posture, then add prompt-level guidance only if that alone doesn't match what you need.

// System prompt: discourage thinking on routine requests
Extended thinking adds latency and should only be used when it will
meaningfully improve answer quality, typically for problems that require
multistep reasoning. When in doubt, respond directly.

// Per-message: encourage it on one specific turn
[appended to a user message] Please think hard before responding.

// Per-message: suppress it on one specific turn
[appended to a user message] Answer directly without deliberating.

Reach for the effort level first, prompt-based steering second — Anthropic's own guidance is explicit that effort is "a calibrated control rather than a wording-sensitive instruction", which makes it the more reliable lever of the two. Whichever you change, measure it: run a representative sample with and without the adjustment and compare how often thinking actually triggers, output tokens spent, and answer quality on the cases you care about, before you ship the change.

If your problem isn't really about how much Claude should deliberate, and is actually about getting a huge amount of source material in front of it at all, the token math changes again — see our guide to Claude's long-context prompting for that side of the accounting, and our reasoning models vs. chat models guide if you're deciding whether a thinking-enabled model is the right tool at all. If your workflow leans on Claude's persistent project context rather than a single long prompt, Claude Projects covers that pairing directly.