Extended Thinking and the Effort Parameter Explained

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.

Summary

Core Idea: Extended thinking surfaces Claude's reasoning as a thinking content block, and the effort parameter controls how much reasoning Claude spends before answering.
Why It Matters: Harder problems (multi-step math, code review, ambiguous instructions) benefit from visible, deeper reasoning, but that reasoning costs tokens and time, so you need a way to dial it up or down per request.
Key Concepts: thinking content block, adaptive thinking, effort levels, thinking display, reasoning tokens.
When to Use: Multi-step analysis, debugging, planning tasks, math or logic problems, and any workload where you want to audit or expose Claude's reasoning path.
Limitations / Trade-offs: More reasoning means more tokens, more latency, and more cost, and not every task benefits from it, so applying it uniformly to simple requests wastes budget.
Related Topics: adaptive thinking configuration, effort tuning, thinking display modes, multimodal input.

Foundations

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.

Mechanics & Interactions

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.

Advanced Considerations & Applications

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.

Common Misconceptions

"Extended thinking always makes answers better." More reasoning helps on genuinely hard, multi-step, or ambiguous tasks, but on simple factual requests it mostly adds latency and cost with little quality gain, which is exactly why adaptive thinking exists.
"Effort and thinking are the same setting." They are independent controls: thinking governs whether and how adaptively Claude reasons, effort governs how deep that reasoning goes and what it costs.
"Adaptive thinking means Claude always thinks a lot." Adaptive thinking means Claude calibrates depth to the task, so a trivial question can still get little or no visible reasoning even with adaptive thinking enabled.
"You need max effort to see a thinking block." Visibility of the thinking block is controlled by the thinking config and display settings, not by the effort level; low effort can still produce a visible, just shallower, reasoning trace.
"Higher effort is free extra quality with no cost." Effort trades directly against latency and token cost, and for many workloads the marginal quality gain at max does not justify the marginal cost over high.

FAQs

What exactly is a "thinking content block"?

A structurally separate part of Claude's response that contains its reasoning, distinct from the final answer content block.
It is returned alongside the answer so your application can choose to log, summarize, or hide it.

Is extended thinking the same thing as a longer response?

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.

What does `thinking: {"type": "adaptive"}` actually do?

It enables adaptive thinking, where Claude itself decides how much reasoning a given request needs.
Simple requests get little or no visible reasoning, harder ones get more, without you specifying a fixed budget.

How is the effort parameter different from adaptive thinking?

Adaptive thinking (the thinking config) controls whether reasoning happens and how adaptively its depth is chosen.
The effort parameter (output_config.effort or similar) sets the ceiling on how much reasoning depth and cost is allowed, independent of adaptivity.

What are the typical effort levels?

low, medium, high, and max, ordered from fastest and cheapest to most thorough and expensive.

Does Claude Fable 5 need the thinking config enabled manually?

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.

Should I always use `max` effort for the best quality?

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.

Can I use a low effort level and still get a thinking block back?

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.

Why would I want to see Claude's reasoning at all?

To debug why Claude reached a particular conclusion.
To audit reasoning for safety-critical or compliance-sensitive workflows.
To build trust with end users by optionally surfacing a summarized rationale.

Is thinking display the same as the effort parameter?

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.

What kind of tasks benefit most from higher effort?

Multi-step math or logic problems.
Code review and debugging of non-trivial code.
Planning tasks with many interacting constraints.
Ambiguous instructions that require weighing trade-offs before answering.

What kind of tasks should use low effort?

High-volume, latency-sensitive tasks like simple classification, short extraction, or formatting, where deep reasoning adds cost without meaningfully improving the result.

Do different models reason the same way at the same effort level?

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.

Extended Thinking, Effort & Multimodal Basics - a minimal working example that enables adaptive thinking end to end.
Enabling Adaptive Thinking with thinking: {type: 'adaptive'} - the concrete configuration for turning adaptive thinking on.
Tuning the effort Parameter for Cost and Speed - how to choose an effort level for a given workload.
Effort Levels and Thinking Display Options Reference - a reference table for every effort level and display mode.
Extended Thinking, Effort & Multimodal Best Practices - numbered practices for tuning these settings in production.

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 anthropic Python 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.