Claude Code Models and Effort Levels: Picking the Right Setting

There are two dials in Claude Code that change your results more than any prompt engineering: which model you are on, and how much effort it spends thinking. Most people set neither and stay on the default forever.

The default is a reasonable middle. It is rarely the right answer for the task actually in front of you.

The models

You select a model with /model, either by alias or by full name. Aliases point at the current recommended version and update over time, which is usually what you want:

To pin an exact version instead, use the full name, for example claude-opus-5 or claude-sonnet-5.

Note that the version an alias resolves to depends on your provider. On the Anthropic API, opus is Opus 5 and sonnet is Sonnet 5. On Bedrock and Google Cloud's Agent Platform, sonnet currently resolves to Sonnet 4.5. If you are on a cloud provider and wondering why behaviour differs from a colleague's, this is usually why. Select the full model name explicitly to override.

opusplan is underrated

This one deserves calling out because it maps cleanly onto how the work actually splits.

Planning is the part that benefits from the strongest reasoning: understanding an unfamiliar codebase, spotting that your request has a hidden dependency, choosing between three architectures. Execution, once the plan is agreed, is often mechanical.

opusplan uses Opus while you are in plan mode and switches to Sonnet to carry the plan out. You pay for the expensive model during the part where it changes the outcome.

When Fable 5 is worth it

Fable 5 is the most capable model available in Claude Code and is aimed at work larger than a single sitting. It sustains long autonomous sessions, investigates before acting, and verifies itself more than smaller models do.

It is not the default. Select it with /model fable. Depending on your plan, its usage may bill to usage credits rather than your plan's included limits, and the /model picker tells you when that applies.

The guidance for using it well is genuinely different from the others:

• Describe the outcome, not the steps. Hand it the result you want and let it plan the path.
• Give it ambiguous problems. Root-cause investigations, outage debugging, architecture decisions.
• Skip the verification reminders. It checks its own work without being nagged.
• Size up. Give it work you would normally break into pieces.

If your instinct is to split a task into five tickets before handing it over, that is the signal to try Fable instead.

Effort levels

Effort controls adaptive reasoning: whether and how much the model thinks at each step. It is a separate dial from model choice, and it is the one people neglect.

The default is high on every model that supports effort, except Opus 4.7, which defaults to xhigh. Set a level the active model does not support and it falls back to the highest supported level at or below it, so xhigh runs as high on Opus 4.6.

Set it with /effort, with --effort at launch, with CLAUDE_CODE_EFFORT_LEVEL, or per-skill and per-subagent in frontmatter.

Choosing a level

Two things are worth internalizing here.

low is not a downgrade, it is a fit. Renaming a variable across twelve files does not benefit from deep reasoning. It benefits from being fast. Running mechanical work at high is paying for deliberation that changes nothing.

max is not simply "better". The documentation is unusually direct about this: it may show diminishing returns and is prone to overthinking. I read that as a real warning rather than hedging. Test it on your workload before adopting it broadly, rather than assuming more is more.

Also note the scale is calibrated per model. high on Sonnet and high on Fable do not represent the same underlying value.

ultrathink for one turn

If you want deeper reasoning on a single message without changing your session setting, include the word ultrathink anywhere in the prompt. Claude Code recognizes it and adds an in-context instruction.

Worth knowing: other phrasings people assume work, "think hard", "think step by step", are passed through as ordinary text. They are not keywords. ultrathink is.

ultracode

The /effort menu also offers ultracode, which is a Claude Code setting rather than a model effort level. It sends xhigh to the model and additionally has Claude orchestrate dynamic workflows for substantive tasks. Reach for it when the task is big enough to need structure, not just deeper thinking on each step.

Fast mode

/fast toggles faster output on Opus 5 and 4.8. The thing people get wrong is assuming it swaps in a smaller model. It does not: it is still Opus, just faster.

Good for interactive back-and-forth where latency is the annoyance. Less relevant for a long autonomous run where you are not sitting there watching.

A configuration that holds up

What I would actually recommend, rather than a matrix of every possibility:

# Daily driver
/model sonnet
/effort high

# Unfamiliar bug, architectural decision, or a plan you'll rely on
/model opusplan

# Mechanical work across many files
/effort low

# Something you'd otherwise break into five tickets
/model fable

And in frontmatter, so you stop thinking about it entirely:

---
description: Formats and lints changed files.
model: haiku
effort: low
---

That last pattern is the one that compounds. Per-skill and per-subagent overrides mean the cheap work routes itself to cheap settings without you touching the dial, and your session default only has to be right for the work you do by hand.

The short version

Match the dial to the task. Deep reasoning on mechanical work is waste; shallow reasoning on genuinely hard problems is false economy that costs more in rework than it saved. Neither the cheapest nor the most expensive configuration is correct as a blanket policy, which is exactly why the dials exist.

Related: skills, which can pin their own model and effort, and subagents, which can route work to cheaper models automatically.

• #Claude Code
• #AI
• #Developer Tools
• #Performance
• #Cost