Are you actually choosing your Claude Code model and effort level on purpose?

Hey everyone, it's Shiichan! Today I found a great read from Anthropic that answers something that quietly nags at every Claude Code user: what should you actually pick, the model or the effort level?

Claude Blog claude.com

What was announced?

On the Claude Blog, Lydia Hallie from the Claude Code team explained how model selection and effort level work in Claude Code and how to choose between them. It's not a new feature launch — it's a clear explainer of two dials Claude Code already has: which model you use, and how hard you ask it to work.

Why it matters

Claude Code gives you a lineup of models, Fable, Opus, Sonnet, and Haiku, plus a separate effort setting you can tune. It's easy to assume "just max out the strongest model at the highest effort," but that's not exactly light on your wallet or your time. Understanding how these two dials actually work lets you use Claude Code more efficiently.

What changes

After reading this, it's much clearer that "model" and "effort" are two completely different axes.

• Model: the fixed set of weights itself, which defines the model's overall range of capability.
• Effort: how much work that model does, how many files it reads, how many tools it uses, and how many steps it takes.

The analogy used is that Fable is "a specialist who's seen problems almost no one else has," Opus is "the expert," and Sonnet is "a really good generalist." Getting five minutes with an expert (Opus at low effort) and getting a generalist's full afternoon of careful reading (Sonnet at high effort) suit very different jobs, and that difference becomes much easier to picture.

Dive Deep

How model selection actually works

When Claude Code sends a request, it bundles your message, the system prompt, tool definitions, your CLAUDE.md file, conversation history, and context files into a single API call. That gets tokenized server-side into integers from a fixed vocabulary.

The model predicts the next token by computing probabilities across its entire vocabulary, using weights, billions of numbers set during training that are read-only by the time you send a request. Prompts and context can steer predictions, but they can't rewrite the weights themselves. That's why a library that didn't exist during training simply isn't baked in; you can only supply docs in context to steer around the gap.

Switching models means swapping out that entire frozen set of weights, which also changes the per-token price. And generation isn't instant: the model predicts one token per pass through the weights, so a 200-token reply means 200 separate passes.

How effort actually works

Output tokens fall into three buckets, thinking, tool calls, and text shown to you, but they're all billed the same as ordinary output tokens. The effort level gets sent along with the request, and how the model should behave at each level was baked into the weights during training. Higher effort tends to mean more tokens spent chasing a higher-confidence answer.

At higher effort, Claude tends to start by planning, and effort shapes how deep and broad that plan gets, though the plan isn't fixed; steps that turn out to be unnecessary get skipped along the way. Anthropic says its training teams pay close attention to "overthinking" during training because it hurts effectiveness, so effort isn't just padding output for its own sake. One example in the post showed a high-effort path generating roughly 7x more tokens than a standard approach for the same prompt (the post notes this is illustrative, not real benchmark data).

Picking an effort level, and what to change when things go wrong

The advice is to stick with the default effort level for most tasks; defaults are calibrated to how most people want to spend tokens. Treat effort as a dial for your general thoroughness preference, not something you retune for every single task.

When results disappoint, check your context first, then diagnose:

• Claude had enough context but still failed → raise the model.
• Claude skipped files, skipped tests, or didn't double-check → raise the effort.

And if you'd assigned a big model to routine, mechanical work, dropping down usually cuts cost without hurting quality.

Effort, model, and token consumption

On routine tasks at the same effort level, small and large models both tend to succeed; the large model just costs more per token, so downgrading saves money without a quality hit. On harder, multi-step tasks, smaller models can burn a lot of iterations bumping into their capability ceiling, while a larger model reaches the same quality in fewer steps, so total cost can actually end up lower with the bigger model. Some tasks, especially long multi-step ones, apparently can't be completed by smaller models at all, which is where a model like Fable comes in.

The only hard ceiling is max_tokens, which truncates a response mid-stream; effort shapes generation but doesn't strictly cap it. For finer control, task budgets or explicit brevity instructions work better than hard limits.

Wrap-up

• "Model" is the capability foundation (a frozen set of weights); "effort" is a separate dial for how much work gets done.
• Predictions come from trained, read-only weights; context can steer them but can't rewrite them.
• Higher effort means more careful planning and more tokens (up to about 7x in one example), but it's tuned during training to avoid pointless padding.
• When something goes wrong, diagnose whether it's a model gap or an effort gap before adjusting.
• For hard tasks, a bigger model can end up cheaper overall by finishing in fewer steps.

If you use Claude Code daily and have quietly wondered how to balance cost against quality, this one's for you!