What is Adaptive Thinking, and how does it differ from the older Extended Thinking?
Adaptive thinking is Claude's current mainstream reasoning mode, enabled in the API via thinking: {"type": "adaptive"}. Its most fundamental difference from the older extended thinking mode (type: "enabled" paired with budget_tokens) is who decides how much effort goes into thinking: the older mode had the developer manually specify a fixed thinking Token budget, which Claude would spend on every single request; the newer mode has Claude itself dynamically judge, based on each request's complexity, whether thinking is needed at all this time and how deep it should go — simple questions may skip thinking entirely and go straight to an answer, while complex ones trigger deeper reasoning.
This isn't just a syntax change, it's a fundamental shift in behavior: under the fixed-budget mode, Claude thinks on every single request; under adaptive mode, at lower effort settings, Claude may skip the thinking step entirely for simple inputs.
Why does Adaptive Thinking exist, and what problem does it solve?
The fixed-Token-budget mode has a structural inefficiency: regardless of how hard a question actually is, Claude has to spend the budget the developer set in advance thinking about it. For a real-world workflow mixing simple queries with complex tasks, this means simple questions are forced to incur unnecessary thinking cost, while complex ones can end up under-reasoned if the budget wasn't set high enough.
Adaptive thinking solves exactly this kind of efficiency loss from a one-size-fits-all approach. The official documentation notes that this mechanism reliably outperforms fixed-budget Extended Thinking for workloads mixing trivial and complex requests, and for long-horizon agentic workflows. In essence, it moves the judgment of "how deeply should this question be thought through" from a manual setting the developer makes before sending the request to a real-time decision Claude makes for itself at request time — shifting the granularity from "one shared budget for an entire batch of workflow" down to "each individual request decides for itself."
What does Adaptive Thinking actually look like in practice?
With adaptive thinking enabled, whether and how much Claude thinks depends on two factors: the effort parameter and the complexity of the request itself. At the default high effort level, Claude almost always thinks; at lower levels, it may skip thinking entirely for simple questions and answer directly, only triggering reasoning when the request itself is genuinely detected as complex. One important detail: effort is soft guidance, not a hard ceiling — even at low effort, if a problem is complex enough, Claude will still choose to think deeply, and won't be forced into a sloppy answer just because the level is set low.
Adaptive thinking also automatically enables interleaved thinking, letting Claude weave thinking steps between multiple tool calls — particularly helpful for agentic workflows like tasks requiring successive file reads, searches, and verification. Worth noting: the official documentation recommends pairing this with max_tokens as a hard ceiling on total output, since at high or max effort levels, Claude may think more extensively than expected. If a response shows stop_reason: "max_tokens", that means output got cut off by this hard ceiling — the fix is either raising max_tokens, or conversely lowering the effort level.
Understanding how Adaptive Thinking works — how does this actually affect how I use Claude?
If you develop through the API, the most direct effect is on your migration path: if you have existing code using the old budget_tokens setup, moving to adaptive thinking isn't as simple as swapping a parameter name — you need to understand the behavior has fundamentally changed. The old mode always spent the full budget thinking; the new mode may not think at all. That means you need to re-test latency and output quality rather than assuming behavior stays identical after the syntax change. One more thing worth watching: switching thinking modes (say, from enabled/disabled to adaptive) invalidates prompt-cache breakpoints, and the first request after switching rebuilds the cache.
If you only use Claude through Claude Code or claude.ai and never touch the API directly, this concept is still useful — it explains why, at the same effort setting, Claude's response speed can differ noticeably between a simple question and a complex one: it's not that the system got slower or faster, it's Claude judging, this time, whether the question genuinely needs deep thinking.
The official documentation lays out a concrete behavioral contrast: in adaptive mode at the default high effort level, Claude almost always thinks; but once effort is lowered, the same system skips the thinking step entirely for simple queries and answers directly, only triggering reasoning for genuinely complex problems. This contrast directly demonstrates the property that "effort is soft guidance, not a hard rule," and explains why the exact same code, with only the effort parameter changed, produces a noticeable difference in Claude's response speed and reasoning depth.
The advantage is dynamically allocating thinking cost based on request complexity, avoiding wasted budget on simple problems and insufficient budget on complex ones — especially suited to workflows with mixed difficulty. The drawback is losing the predictable "thinking amount is known in advance" property of the fixed-budget mode: at high effort levels, Claude may think more extensively than expected, requiring an additional max_tokens hard ceiling to keep cost and latency predictable.