Extended Thinking and the Effort Parameter Explained
When you ask Claude a hard question, there is work happening before the final answer appears.
//
Search across all documentation pages
When you ask Claude a hard question, there is work happening before the final answer appears.
Extended thinking is the feature that lets you see that work.
Instead of a single opaque response, Claude can emit a separate thinking content block that contains its reasoning, followed by the final answer content block.
The effort parameter is a related but distinct control.
It does not decide whether reasoning is visible.
It decides how much reasoning Claude does in the first place, trading thoroughness against cost and speed.
Understanding the difference between these two knobs, and how they interact with the underlying model, is the foundation for everything else in this section.
thinking content block, and the effort parameter controls how much reasoning Claude spends before answering.Extended thinking is a mode where Claude produces a thinking content block before its normal answer.
That block contains the model's intermediate reasoning: the steps it worked through to arrive at its conclusion.
This is different from a model simply writing a longer answer.
The thinking content is structurally separate from the final response, so your application can choose to display it, summarize it, or hide it.
You turn extended thinking on by passing a thinking configuration object in your request.
The grounding shape for this site is {"type": "adaptive"}, which enables adaptive thinking.
Adaptive thinking means Claude itself decides how much reasoning a given task warrants, rather than you specifying a fixed token budget up front.
A one-line factual question gets little or no visible reasoning.
A multi-step logic puzzle gets much more.
Think of it like a person asked a question in a meeting.
For "what's 12 plus 30," they answer instantly, no scratch work needed.
For "should we migrate this service before or after the holiday freeze," they pause, weigh trade-offs, and think out loud before answering.
Adaptive thinking gives Claude that same latitude, automatically, per request.
Claude Fable 5, the top-tier model in the current lineup, runs with always-on adaptive thinking by default, reflecting how central this behavior is to how it operates.
Extended thinking and the effort parameter operate at different layers of the request.
The thinking config answers the question "should reasoning be visible, and should Claude decide its own depth." The effort parameter, typically set under output_config.effort (or an equivalent field depending on SDK version), answers a separate question: "how much reasoning effort should Claude apply overall, regardless of whether it is shown." Effort is graded in levels, commonly low, medium, high, and max.
At low, Claude favors speed and economy, doing the minimum reasoning needed to produce a reasonable answer.
At max, Claude spends significantly more computation working through edge cases, alternative interpretations, and verification steps before committing to a final answer.
These two settings compose.
You can have adaptive thinking enabled with a low effort ceiling, in which case Claude still decides per-task whether to reason at all, but is capped in how deep it goes even on hard tasks.
You can also have adaptive thinking with max effort, which gives Claude the most latitude to reason extensively on problems that call for it.
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=2048,
thinking={"type": "adaptive"},
output_config={"effort": "high"},
messages=[{"role": "user", "content": "Plan a phased rollback strategy."}],
)The important mental model: thinking governs the presence and adaptivity of reasoning, effort governs its depth and cost ceiling.
They are not the same lever, and conflating them leads to confusing tuning decisions, like assuming you need max effort just to see a thinking block at all.
A related but separate concern is thinking display, which determines what your application actually receives back: a summarized version of the reasoning, or nothing at all, even when reasoning happened internally.
Display is a presentation setting, not a reasoning-depth setting, and it is covered in full on the effort levels and thinking display reference page.
In production systems, the effort parameter is usually the first thing you tune once you have a working integration, because it is the most direct lever on unit economics.
A support-ticket triage endpoint answering thousands of simple classification requests per day has very different needs than a code-review assistant working through a large diff.
The former wants low or medium effort to keep latency and cost predictable at scale.
The latter benefits from high or max effort, because a missed edge case in a code review is more expensive than the extra reasoning tokens spent finding it.
Effort tuning also interacts with model choice.
Claude Opus 4.8, the flagship reasoning model, and Claude Sonnet 5, the default general-purpose model, both support the effort parameter, but their baseline reasoning capability differs, so the same effort level does not produce identical depth across models.
Claude Haiku 4.5 is optimized for speed and cost, and is typically paired with lower effort levels for high-throughput, latency-sensitive workloads where extensive reasoning is not the bottleneck.
| Approach | Strength | Weakness | Best Fit |
|---|---|---|---|
| Low effort, adaptive thinking off | Fastest, cheapest, most predictable latency | Misses nuance on genuinely hard inputs | High-volume simple classification, formatting, extraction |
| Adaptive thinking, low-to-medium effort | Claude decides when reasoning is worth it, capped cost | Occasional under-reasoning on borderline-hard tasks | General-purpose chat and assistant workloads |
| Adaptive thinking, high-to-max effort | Deepest reasoning on genuinely hard problems | Highest cost and latency per request | Code review, multi-step planning, math-heavy or safety-critical tasks |
A common architecture pattern is to route requests to different effort levels based on a cheap upstream classifier, or to let the caller pass effort through as a request-time parameter so product teams can tune it without redeploying.
Because thinking content is a distinct content block, applications that log or audit model behavior can retain it separately from the user-facing answer, which is useful for debugging why Claude reached a particular conclusion without exposing that reasoning to end users.
thinking governs whether and how adaptively Claude reasons, effort governs how deep that reasoning goes and what it costs.thinking config and display settings, not by the effort level; low effort can still produce a visible, just shallower, reasoning trace.max does not justify the marginal cost over high.No. A longer response is just more final-answer text. Extended thinking is a separate content block containing the model's intermediate reasoning, produced before the final answer is written.
thinking config) controls whether reasoning happens and how adaptively its depth is chosen.output_config.effort or similar) sets the ceiling on how much reasoning depth and cost is allowed, independent of adaptivity.low, medium, high, and max, ordered from fastest and cheapest to most thorough and expensive.
No. Claude Fable 5 runs with always-on adaptive thinking by default, so it reasons adaptively without you needing to set the thinking config yourself.
Not necessarily. max effort increases latency and cost, and for tasks that do not require deep reasoning the quality gain over high or medium is often marginal, so it is best reserved for genuinely hard problems.
Yes. Effort controls reasoning depth and cost ceiling, not whether the thinking block is present. A low-effort request can still surface a shallower reasoning trace.
No. Thinking display controls whether the reasoning your request produced is returned to you summarized or omitted, while effort controls how much reasoning was done in the first place. They are separate settings that can be combined.
High-volume, latency-sensitive tasks like simple classification, short extraction, or formatting, where deep reasoning adds cost without meaningfully improving the result.
No. Baseline reasoning capability differs by model (Fable 5, Opus 4.8, Sonnet 5, Haiku 4.5), so the same effort level does not produce identical reasoning depth across models.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official
anthropicPython SDK (latest 0.x release). Model names, SDK versions, and pricing move quickly - verify current specifics at platform.claude.com/docs before relying on them.
Reviewed by Chris St. John·Last updated Jul 16, 2026