Claude Extended Thinking in 2026: Adaptive Thinking, Effort and How to Prompt It

Most Claude responses come back in seconds. Give it a hard debugging problem at high effort and it can think for a minute or more before the first visible word. That pause is Claude working through the problem before it commits to an answer.

Extended thinking is Claude's internal reasoning phase. It arrived with Claude 3.7 Sonnet as an opt-in feature with a fixed token budget. On today's models (Fable 5.1, Opus 5.5 and Sonnet 5) it has changed in three ways that break most older tutorials:

1. Thinking is adaptive. Claude decides how much to think for each request. The old budget_tokens setting returns an error on current models.
2. Depth is controlled by effort, a single low to max dial.
3. You never see the raw reasoning. You can ask for a summary.

This guide covers how Claude's extended thinking works now, how to call it, which problems benefit, and how to prompt for it.

What extended thinking actually does

With standard generation, Claude writes the answer token by token and every token is visible. Classic chain-of-thought prompting steered that visible output ("think step by step"), so the reasoning happened in the response.

Extended thinking moves the reasoning into a separate phase before the response. Claude uses it to explore approaches, backtrack, check intermediate results and test assumptions. The answer comes only after that phase finishes.

It's the same model, not a separate one. The difference is that Claude gets room to generate tokens you don't read, so it can reason exploratorily without every step having to read well.

Enabling thinking via the API

On current models you ask for adaptive thinking and set an effort level:

India developers: AICredits provides Claude API access with INR / UPI billing — no USD card needed to start experimenting with extended thinking.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=16000,
    thinking={"type": "adaptive", "display": "summarized"},
    output_config={"effort": "high"},
    messages=[{
        "role": "user",
        "content": "A snail is at the bottom of a 30-foot well. Each day it climbs 3 feet. "
                   "Each night it slides back 2 feet. How many days does it take to reach the top?",
    }],
)

for block in response.content:
    if block.type == "thinking":
        print("Thinking summary:", block.thinking)
    elif block.type == "text":
        print("Answer:", block.text)

What each setting does:

• thinking: {type: "adaptive"} lets Claude decide when and how much to think. On Fable 5.1, Opus 5.5 and Sonnet 5 this is also what happens if you leave thinking out.
• display: "summarized" returns a readable summary in the thinking block. Without it, the default on current models is "omitted": the thinking block is there, but its text is empty. Thinking happens and is billed the same either way.
• output_config: {effort: ...} controls depth. More on that below.

If you have older code

This pattern is everywhere in 2025 tutorials:

thinking={"type": "enabled", "budget_tokens": 10000}  # don't use this

It returns a 400 error on Fable 5 and 5.1, Opus 5, 5.5, 4.8 and 4.7, and Sonnet 5, and it's deprecated on Opus 4.6 and Sonnet 4.6. Replace it with adaptive thinking plus an effort level. The one current exception is Haiku 4.5, which still uses budget_tokens for thinking.

Two model-specific details:

• Claude Fable 5.1 and Opus 5.5 always think. Sending {type: "disabled"} returns a 400. If you want less thinking, lower the effort.
• Opus 5.5 defaults to medium effort, one level below the high default on other models. Set effort explicitly so you know what you're getting.

Choosing an effort level

Effort is the dial that replaced the thinking budget. It controls how much Claude thinks and, more broadly, how many tokens it spends on a task. Values are low, medium, high, xhigh and max.

Lower effort also changes behavior beyond thinking: fewer and more consolidated tool calls, less preamble, shorter confirmations. That's usually what you want for sub-agents.

Don't pick by feel. Run 20–30 real tasks at two adjacent levels and compare quality and cost. On the newest models, a lower effort level often matches what older models needed high effort for.

Cost math

Thinking tokens are billed as output tokens, even when the display is omitted. At current list prices:

For one-off tasks that's noise. For a pipeline processing 100,000 documents it's the whole budget, which is why effort is the first setting to tune. Current prices for every model are on our models page.

Problems that benefit most from extended thinking

Adaptive thinking means Claude already thinks less on easy requests. Raising effort pays off most on:

Math and logic. Anything where an early mistake compounds. The snail-and-well problem above trips models that forget the snail doesn't slide back on the final day.

Complex debugging. Paste in a stack trace and the surrounding code, and Claude can map the execution path, form hypotheses and test them before answering. It's especially useful for async bugs and race conditions.

Multi-step planning. "Design a database schema for a SaaS app with these requirements" means weighing normalization, query patterns, scaling and tenant isolation at once.

Decisions with real trade-offs. "Postgres or DynamoDB for this workload?" Higher effort surfaces the actual decision drivers instead of a hedged "it depends."

Documents that must hold together. Legal memos, investment theses, design docs: anywhere the output needs internal consistency.

Where more thinking doesn't help

Simple Q&A and lookups. Use low effort. There's nothing to deliberate.

Classification. Sentiment, tagging, intent detection are pattern matching. Low effort, or a fast model like Haiku 4.5.

Straight summarization. The information is already in context.

Creative writing. Over-deliberation can flatten a voice that should feel spontaneous.

Live chat. If a user is waiting, long thinking hurts the experience. Keep effort low for interactive routes, or stream a progress indicator.

Prompting patterns that work best

Effort decides how much Claude thinks. Your prompt decides what it thinks about.

State the problem completely up front. Don't embed your assumptions. "Given that X is true, how do we handle Y?" constrains the reasoning before it starts. "Here's the situation: [facts]. What's the best approach to Y?" lets Claude form its own premises.

Don't script the steps. Prompts written for older models are often too prescriptive and reduce output quality on current ones. Describe the result you need and the constraints, not the order to think in.

Drop "think carefully" filler. On older models, "think through this carefully" nudged the model to spend its budget. Now that's what effort is for. Raise the setting instead of adding the phrase.

Ask for confidence. "How confident are you, and what would change your recommendation?" makes Claude flag uncertainty instead of smoothing it over.

Ask for verification. "After solving, check the answer against the original problem" still earns its keep on math and logic.

For planning, ask about failure modes. "Before recommending, consider what could go wrong with each option" pushes the thinking toward adversarial analysis.

Streaming thinking to a UI

On long thinking turns, a silent spinner feels broken. Stream the response and show the summary as it arrives:

with client.messages.stream(
    model="claude-sonnet-5",
    max_tokens=64000,
    thinking={"type": "adaptive", "display": "summarized"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": your_prompt}],
) as stream:
    for event in stream:
        if event.type == "content_block_delta":
            if event.delta.type == "thinking_delta":
                show_progress(event.delta.thinking)
            elif event.delta.type == "text_delta":
                show_answer(event.delta.text)

    final_message = stream.get_final_message()

Remember that the default display is "omitted". If you stream without display: "summarized", the thinking phase looks like a long pause with nothing in it.

Whether to show the summary at all is a product decision. It can build trust, but most production apps show a short "Reasoning…" indicator and the final answer only.

Multi-turn conversations

When you continue a conversation on the same model, pass the thinking blocks from the previous response back unchanged, along with the rest of response.content. Don't edit or strip them: current models check that earlier thinking is intact.

Combining with context engineering

Thinking and context engineering compound each other. With well-structured context (relevant documents, clear framing, explicit constraints), Claude spends its thinking on the problem instead of on figuring out what you're asking.

The worst use of extended thinking is a vague prompt at max effort. The best is a precise problem statement with the right documents attached, in XML tags, at an effort level you've tested.

When to raise effort, and when not to

Raise it when:

• The problem has a verifiably correct answer (math, logic, code) and you need it right
• The work runs async or in batch, so latency doesn't matter
• A wrong answer costs more than the extra output tokens
• You want Claude to catch its own mistakes before you see the output

Keep it low when:

• Users are waiting in real time
• The task is retrieval or pattern-matching, not reasoning
• You're running high volume on a tight budget
• The question is genuinely ambiguous and more reasoning won't produce a "correct" answer

For how OpenAI and Gemini handle the same idea, see how to prompt reasoning models.