Why fast mode isn't a lower effort level

Effort level, extended-thinking budget, and fast mode are three separate controls on a Claude session, not one setting. Effort scales every token Claude spends - text, tool calls, and thinking together. Thinking budget caps reasoning tokens specifically, but only on models still running the older fixed-budget mode. Fast mode changes neither: it pays a flat premium price - up to $150 per million output tokens on Opus 4.7 - for the same model to answer up to 2.5x faster. Anthropic’s own docs recommend stacking them, not picking one.

Definitions

Effort - a parameter (low/medium/high/xhigh/max) that scales how many tokens Claude spends on a response: text, tool calls, and any thinking together. It works with or without extended thinking turned on.

Extended thinking (adaptive reasoning) - the reasoning Claude emits before responding. Recent models decide per step whether and how much to think; older models use a manually set token budget instead.

Fast mode - a Claude Code setting that runs Opus through a different API configuration prioritizing speed over cost. Same model, same weights, same output quality - just faster and pricier per token.

MTok - one million tokens, the unit Anthropic’s per-token prices are quoted against (“$10 per MTok” means $10 per million tokens).

The levers at a glance

Effort level: the token-spend dial

Effort is a behavioral signal, not a hard token cap - at low effort Claude still thinks on a genuinely hard step, just less than it would at high effort on the same step. It affects every token in the response, which is what makes it different from a thinking-only control: lower effort also means fewer tool calls and terser explanations, not just less reasoning.

Level availability and defaults vary by model: Fable 5, Sonnet 5, Opus 4.8, and Opus 4.7 support all five levels; Opus 4.6 and Sonnet 4.6 skip xhigh but keep low/medium/high/max. The default is high everywhere except Opus 4.7, which defaults to xhigh. Model choice and effort choice are two separate decisions - Why most agents default to the wrong Claude tier covers picking the tier itself.

Set it through any of:

• /effort - opens a slider, or takes a level name directly; /effort auto resets to the model default
• --effort <level> - sets it for one CLI session
• CLAUDE_CODE_EFFORT_LEVEL environment variable - highest precedence, overrides everything else
• effortLevel in settings.json - a persistent default (accepts low/medium/high/xhigh, not max or ultracode)
• effort: in a skill or subagent’s frontmatter - overrides the parent session’s level while that skill or subagent runs, but not the environment variable

ultracode sits in the /effort menu but isn’t a sixth level: it sends xhigh to the model and lets Claude Code orchestrate multiagent workflows for a substantive task, session-only. ultrathink, dropped anywhere in a prompt, requests deeper reasoning for that one turn without touching the session’s effort setting at all.

On the API directly, the same parameter lives under output_config:

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "Analyze the trade-offs between microservices and monolithic architectures"}],
    output_config={"effort": "medium"},
)

Extended thinking: adaptive vs. fixed budget

Fable 5, Sonnet 5, and Opus 4.7 and later always use adaptive reasoning - the model decides per step whether to think and how much, guided by effort level. On these models, a nonzero MAX_THINKING_TOKENS value is ignored; effort is the only real dial. Opus 4.6 and Sonnet 4.6 default to adaptive too, but can revert to the older fixed-budget mode with CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1, at which point MAX_THINKING_TOKENS sets an actual token ceiling on reasoning.

One control cuts across both modes: MAX_THINKING_TOKENS=0 turns thinking off entirely on the Anthropic API, on any model, with one exception. Fable 5 cannot disable thinking under any setting - the session toggle, alwaysThinkingEnabled, and MAX_THINKING_TOKENS=0 all have no effect there.

Thinking tokens bill as output tokens whether or not you ever look at them - collapsed by default, expandable with Ctrl+O. That’s the direct link to cost: a model defaulting to high effort with adaptive reasoning can spend tens of thousands of thinking tokens on a request before it writes a single word of visible output.

# Session-wide spend dial (Claude Code only; on adaptive models this is the only thinking control)
export CLAUDE_CODE_EFFORT_LEVEL=medium

# Fixed-budget models only: revert from adaptive, then set a token ceiling
export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1
export MAX_THINKING_TOKENS=8000

Fast mode: paying for latency

Fast mode is a research-preview Claude Code setting, Opus-only, that runs the same model through a different API configuration prioritizing speed. It is not a cheaper or smaller model - output quality is identical, and the only thing that changes is how fast tokens arrive and how much each one costs.

Toggle it with /fast, or set "fastMode": true in your settings file. Either way, once it’s on it carries over into future sessions by default - Claude Code remembers however you last left it. The first fast-mode message in a conversation pays the full, uncached fast-mode input price for the entire existing context - not just the new message - so turning fast mode on at the start of a session is cheaper than switching mid-conversation. That cost applies once per conversation; toggling it off and back on later doesn’t repeat it.

Turning it on also requires usage credits, and for Team and Enterprise organizations, explicit enablement by an Owner - it’s off by default at the org level even when available on the plan. fastModePerSessionOptIn: true in settings overrides the default carry-over: every new session starts with fast mode off, no matter what you set last time.

{
  "fastMode": true,
  "effortLevel": "medium"
}

Combine them

Fast mode and effort level solve different problems, and the docs are explicit that you can run both at once:

For maximum speed on a straightforward task, stack low effort with fast mode: fewer tokens generated, and each one arrives faster. For a task where quality matters more than either speed or cost, drop fast mode and raise effort instead - paying more per token for identical output makes no sense next to a setting that changes what the model actually produces. Model choice still sits underneath both: Claude Sonnet 5 closes the gap to Opus without the Opus bill and Claude Fable 5: refusals are an API contract, not an error cover the per-model effort defaults these two levers ride on top of.

Effort and fast mode are two of several levers for cutting what an agent costs to run - Stop paying full price for repeat LLM calls covers the other three: prompt caching, batching, and model-tier routing, which stack with everything here.