19 / 20Context7 MIN READ

Extended Thinking

Extended thinking is reasoning the model emits before its answer, and on current models the effort level is the primary control over how much of it happens.

Reasoning branches compared before one answerA prompt on the left fans into three reasoning branches that are explored in parallel and compared. One branch is selected and converges into a single answer on the right.PROMPToption aoption boption cANSWEReffort level bounds how far this fans outthinking tokens bill as output tokens

What it is

Thinking is on by default because it measurably improves complex planning and reasoning. On models with adaptive reasoning — Fable 5, Sonnet 5, and Opus 4.7 and later always; Opus 5, Opus 4.8, Opus 4.6, and Sonnet 4.6 in their own ways — the model decides per step whether to think and how much, within the budget the effort level sets. That is why the effort level, not a token budget, is the control you reach for.

Effort levels are low, medium, high, xhigh, and max, with availability by model: Opus 4.6 and Sonnet 4.6 offer low, medium, high, and max; the newer models add xhigh. The default is high everywhere except Opus 4.7, which defaults to xhigh. Set a level the model does not support and Claude Code falls back to the highest supported level at or below it. max and ultracode are session-only.

Two separate things are often confused with the effort setting. ultrathink anywhere in your prompt requests deeper reasoning for that one turn by adding an in-context instruction; the effort level sent to the API does not change, and phrases like "think hard" are just prompt text. ultracode is a Claude Code setting rather than a model level: it sends xhigh and additionally has Claude orchestrate dynamic workflows for substantive tasks.

What it does for you

  • It buys correctness on problems where the first plausible answer is wrong: multi-constraint design, subtle concurrency bugs, and migrations where the order of steps matters.
  • It lets you trade cost for depth per task. Dropping to low for a mechanical rename and raising to xhigh for an architecture decision costs less overall than running everything at one level.
  • It gives you a one-turn escape hatch. ultrathink in a single prompt gets deeper reasoning on the hard question without changing the session and without invalidating the prompt cache.

How it works

  1. 01The effort level bounds how much thinking the model does

    Adaptive reasoning makes thinking optional on each step, so Claude answers routine prompts quickly and reserves depth for steps that benefit. The level sets the ceiling, not a fixed spend.

  2. 02Thinking tokens are billed as output tokens

    They count whether or not you see them. The default budget can run to tens of thousands of tokens per request depending on the model, which is why low is meaningfully cheaper than xhigh.

  3. 03The effort level is part of the prompt cache key

    Each level has its own cache within a model, so changing it mid-session recomputes the entire request. Claude Code shows a confirmation dialog before applying a change that would invalidate the cache.

  4. 04Precedence runs environment, then setting, then model default

    CLAUDE_CODE_EFFORT_LEVEL beats everything. Then your configured effortLevel. Then the model default. Skill and subagent effort frontmatter overrides the session level while that component is active, but not the environment variable.

  5. 05Subagents inherit the session’s thinking configuration

    As of v2.1.198, if thinking is on in your session it is on for the subagent, and if it is off it stays off. There is no per-subagent thinking setting; there is a per-subagent effort field.

  6. 06Display is separate from spend

    Thinking output is collapsed by default; Ctrl+O toggles verbose mode. Interactive sessions on the Anthropic API receive redacted thinking blocks unless you set showThinkingSummaries: true. Redaction changes what you see, not what you are billed for.

How to implement it

  1. 01Leave the default alone until you have a reason

    high is the default on every model that supports effort except Opus 4.7. It is calibrated for coding work; changing it without a reason mostly costs you the prompt cache.

  2. 02Set the level at the start of a session, not the middle

    Run /effort xhigh, adjust the slider inside /model, or launch with --effort xhigh. Mid-session changes reprocess the whole conversation.

  3. 03Use ultrathink for a single hard question

    Include the word anywhere in the prompt. The effort level is unchanged, so nothing is invalidated and the cost is confined to that turn.

  4. 04Pin effort where the work is predictable

    Set effort: low in the frontmatter of a mechanical skill or subagent, and effort: xhigh on a design-review agent. The override applies while that component is active.

  5. 05Control the spend explicitly when you need to

    Lower the level for cost-sensitive work, or disable thinking in /config. On models with a fixed thinking budget, MAX_THINKING_TOKENS sets it; adaptive-reasoning models ignore nonzero budgets, so use effort levels there.

Examples

Controlling depthbash
# Session level — a cache key, so set it before you start working
/effort xhigh
/effort auto        # back to the model default
/effort low         # mechanical work: renames, formatting, scaffolding

# Launch with it, avoiding a mid-session switch entirely
claude --effort xhigh

# One turn only — no effort change, no cache invalidation
"ultrathink: we need idempotent webhook delivery with at-least-once
 semantics, ordering per customer, and a 30-day replay window. Compare
 an outbox table against a log-backed queue, and name what breaks in
 each during a partial region failure."

# Display, not spend: toggle visible reasoning
#   Ctrl+O          verbose mode
#   Option+T / Alt+T  toggle thinking for the session
Session-level, one-turn, and launch-time controls. All three are different mechanisms.
.claude/agents/architecture-reviewer.mdmarkdown
---
name: architecture-reviewer
description: Evaluates a proposed design against scale, failure modes, and migration cost. Use before committing to a design that is expensive to reverse.
tools: Read, Grep, Glob
model: opus
effort: xhigh
---

You evaluate designs, not code style. Read the proposal and the code it would
touch before saying anything.

For each option under consideration, state:

1. What it costs to build, in units of "which existing subsystems change"
2. What breaks first as load grows tenfold, and at what point
3. What the migration away from it looks like if it turns out to be wrong
4. The one assumption that, if false, makes the option indefensible

Do not recommend the safest option by default. Name the tradeoff you are
making and the condition under which you would choose differently.
Pinning effort where it pays. The override applies while this subagent runs and then the session level resumes.
~/.claude/settings.jsonjson
{
  "effortLevel": "high",
  "alwaysThinkingEnabled": true,
  "showThinkingSummaries": true
}
A persisted default. `max` and `ultracode` are session-only and are not accepted here.

Use it when

  • Choosing between architectures where the constraints interact and the wrong choice is expensive to reverse.
  • Debugging a failure whose symptom is far from its cause, such as a race condition or a cache-coherence problem.
  • Planning a migration where the order of steps determines whether each stage can ship independently.
  • Reviewing a security-sensitive change, where the question is what an attacker can do rather than whether the code runs.
  • Reconciling requirements that conflict, where naming the tradeoff matters more than producing an answer.

Avoid it when

  • The task is mechanical. A rename, a formatting pass, or scaffolding from a template gains nothing from deeper reasoning and pays for it in output tokens.
  • You are latency-sensitive. Thinking happens before the answer, so a quick lookup at max feels slow for no benefit.
  • The problem is underspecified. More reasoning over a vague prompt produces a more elaborate guess, not a better one. Specify the constraints first.
  • You would switch levels mid-task. Effort is a cache key, so the switch reprocesses the whole conversation — often costing more than the depth gains.

Common mistakes

  • SYMPTOMWriting "think hard" or "think more" and expecting deeper reasoning.

    FIXOnly ultrathink is recognised as a keyword. Everything else is passed through as ordinary prompt text.

  • SYMPTOMSetting MAX_THINKING_TOKENS on a current model and seeing no change.

    FIXAdaptive-reasoning models ignore nonzero budgets. Use effort levels instead. MAX_THINKING_TOKENS=0 still disables thinking on the Anthropic API, except on Fable 5.

  • SYMPTOMRunning /effort max mid-task and getting a slow, expensive turn.

    FIXEffort is part of the cache key, so the next request reads the entire history uncached. Set the level at the start, or use ultrathink for one turn.

  • SYMPTOMAssuming a lower effort level reduces cost because the reasoning is hidden.

    FIXThinking tokens are billed as output tokens whether collapsed, redacted, or shown. Redaction changes display only; lower the level or disable thinking to reduce spend.

  • SYMPTOMTrying to turn thinking off on Fable 5.

    FIXFable 5 always uses extended thinking. The session toggle, alwaysThinkingEnabled, and MAX_THINKING_TOKENS=0 have no effect there; it decides per step based on the effort level.

Best practices

  • Choose the effort level at the start of a session and leave it there, because it is a prompt cache key.
  • Reach for ultrathink rather than an effort change when only one turn is hard.
  • Pin effort in the frontmatter of skills and subagents whose workload is predictable.
  • Spend the depth on ambiguity and interacting constraints, not on volume of code.
  • Specify the constraints before raising the effort — reasoning cannot recover information the prompt never contained.
  • Test max on your own workload before adopting it: the docs note it can show diminishing returns and is prone to overthinking.

Try it in five minutes

Compare three depths on one genuinely hard question, and watch what each one costs.

  1. 1.Start a session, run /effort low, and ask a design question with at least three interacting constraints. Note the answer and the response time.
  2. 2.Run /clear, then /effort xhigh, and ask the identical question. Compare which tradeoffs each answer names.
  3. 3.Run /clear and /effort high, then ask the same question again with ultrathink in the prompt. Note that no cache invalidation dialog appears.
  4. 4.Press Ctrl+O to turn on verbose mode and re-ask, so you can see the reasoning.
  5. 5.Run /usage and compare the output-token cost of the three runs.

Verified against code.claude.com/docs/en/model-config#extended-thinking on 2026-08-09. See content/SOURCES.md for the full table.

← / → MOVE BETWEEN CONCEPTS