Effort levels in Claude Code — when low is enough and when you need max

Most operators let Claude Code run on one level and never notice there are five. Effort is the dial for thinking depth, meaning how much the model thinks before it answers. That's not the same as the model itself. Opus on low thinks shallower than Opus on max, even though both are the same model. Whoever only thinks about the model and ignores effort either leaves money on the table or burns tokens on a task that doesn't need a deep reasoning chain at all. This playbook shows you how to switch levels live, set one at launch, save it persistently and pick the right one per task. Tested with Claude Code v2.1.206.

Step 1: Understand what effort is and what it isn't

Effort controls how deeply Claude thinks per answer. Low means minimal thinking and the fastest answer. Max means the deepest reasoning chain with no token cap at all. Two distinctions matter. Effort is something different from the feature Anthropic calls "extended thinking", and it's something different from the choice between Opus, Sonnet and Haiku.

You combine both dials. A strong model on low can be faster and cheaper on a simple file search than a weak model on high on a task that needs real reasoning. If you don't keep these apart, you turn the wrong knob and wonder why the answer stays shallow despite the expensive model.

Step 2: Know the five levels plus ultracode

There are five levels. low for minimal thinking and the fastest answers, good for file lookups and trivial edits. medium for moderate thinking. high for deep reasoning, which is the default on most models. xhigh for extended reasoning. On most models high is the default; individual models like Opus 4.7 start on xhigh. On models that don't support xhigh it automatically falls back to high. And max for the deepest thinking depth with no token limit at all.

On top of that comes ultracode, available since Claude Code v2.1.203. Ultracode combines xhigh effort with dynamic workflow orchestration for substantial tasks. If workflows are disabled in your setup, ultracode falls back to plain xhigh. Remember the levels as a ladder from fast and shallow to slow and deep, then the choice comes easy in daily work.

Step 3: Check your current state

Before you change anything, look at where you currently stand. The interactive slider in /model shows you the active level. In the VS Code extension it's additionally shown in the status line, so you see live whether you're running on high or max.

The point: many operators believe they're running on high, because that's the default vibe, but are sitting on medium because an old config or a set env var overrides it. Check first, then turn. That saves you the guessing about why an answer was weaker than expected.

Step 4: Switch live with /effort

The fastest way mid-session is the slash command. Type /effort and you get a menu, or pass the level directly: /effort high. The change takes effect immediately for the next turn, you don't have to restart anything.

This is the dial you touch most often in daily work. A trickier refactoring question comes up, you turn it up, then back down for the small stuff. One deliberate reach for this slash command per task saves noticeably on tokens over the day.

Step 5: Set it at launch with --effort

If you know an entire session needs a certain depth, pass the level right at launch: claude --effort high. The launch flag overrides the configured effortLevel setting, but applies only to this one session and doesn't persist beyond it.

This is handy for a headless run in CI or for a dedicated debug session where you don't want to type /effort every time. You start once with the right level and have your peace.

Step 6: Set it persistently with effortLevel

For a permanent setting you use the config key effortLevel. The levels low, medium, high and xhigh persist when you set them in an interactive session, so they survive a restart and become your new default.

Two levels are deliberately excluded. max and ultracode can NOT be saved as a default and apply only to the running session. For max there's an exception: if you set it via the environment variable CLAUDE_CODE_EFFORT_LEVEL, it also takes effect across sessions. ultracode, by contrast, doesn't accept this env var. That's not a bug but by design, so you don't accidentally run permanently at maximum token load through every bit of small stuff.

Step 7: Env var and the precedence order

There's a third way, the environment variable CLAUDE_CODE_EFFORT_LEVEL. Useful when you want to set effort per project or per shell, for example in a project-specific startup script.

What matters is the order of who wins when values conflict. The env var has the highest priority, then come the configured settings, at the very bottom the model defaults. So if your /effort seems to be ignored, the most common cause is a set CLAUDE_CODE_EFFORT_LEVEL that overrides everything else. That was the classic for me: an old line in the .bashrc silently overrode every slider change for weeks.

Step 8: max and ultracode, the session weapons

You bring out max when a task really needs deep, multi-stage thinking and you accept the token cost. There's no token limit on this level, which is feature and warning at once. For a hard architecture question or debugging across many files it's exactly right, for daily work it's waste.

ultracode is the special level for substantial tasks, xhigh effort plus automatic workflow orchestration. Both are session-only, they disappear on the next launch. Use them deliberately for a big chunk and then consciously turn back down, otherwise the bill runs away from you without you getting better output.

Step 9: Pick the level per task

As a rule of thumb: low for lookups, renames and short questions where the answer is basically settled. high or xhigh for real coding and agentic work with several tool steps, that's the sweet spot for most development work. max or ultracode for the rare complex multi-step problems, architecture decisions, tricky debugging.

Lower levels save tokens and cost, higher ones buy you thinking depth. The expensive mistake is confusing the two and leaving everything blanket on one level. Whoever runs on max all day pays for thinking the task doesn't need, whoever sticks to low gets shallow answers on hard questions and doesn't notice why.

Step 10: Reset with /effort auto

If you've lost track of which level is currently in effect and where from, just reset. /effort auto brings you to the model default. The default varies by model, most are on high. From there you decide cleanly anew.

This one line is your reset button when config, env var and slash command have overridden each other and you no longer know what's really active. When in doubt /effort auto, then deliberately turn up where you need it.

What comes next

Effort and cost are directly linked, higher levels pull more tokens. If you want to keep that in check, read the playbook Cost controls for daily drivers. If your sessions get long and you want to combine effort with context management, Managing the context window fits. And if you want to understand why deep reasoning even helps on some tasks, go back to the lesson Reasoning and extended thinking. For structured large tasks the combo with Using plan mode properly pays off.

Sources

• Claude Code Model Config, effort level, reset and precedence: https://code.claude.com/docs/en/model-config
• Claude Code Commands, /effort: https://code.claude.com/docs/en/commands
• Claude Code CLI Reference, --effort flag and values including ultracode: https://code.claude.com/docs/en/cli-reference