Choosing a Claude model and effort level for analytics work

Claude Code gives you two dials that both look like “make the answer better”: the model and the effort level. They do different things, and mixing them up is how you end up paying for depth on a column rename, or getting a shallow answer to a reconciliation problem that needed a careful one.

The short version, from Anthropic’s own guidance: the model decides how capable Claude is; the effort level decides how thorough it is. Pick the model for how hard the problem is, and the effort for how much checking you want before it comes back to you.

Everything below reflects the documentation as of late September 2026. Models and defaults change often, so check the model configuration docs before copying any of it into a script.

The two dials

The model is which set of trained weights handles your request. A larger model brings knowledge and pattern recognition a smaller one doesn’t have, and no amount of prompting adds that. It also sets the price of every token.

Effort controls how much work Claude does on each turn. In Anthropic’s post Choosing a Claude model and effort level in Claude Code, effort covers more than thinking time: how many files Claude reads, how much it verifies, and how far it pushes through a multi-step task before checking in. At lower effort it would rather ask you for context than spend tokens finding it.

The same post gives the most useful diagnostic I’ve seen. When Claude gets something wrong, first check the context: a vague prompt, a missing file, an out-of-date memory file. If the context was fine, ask:

• Did it not know enough? It had everything it needed, clearly tried, and was still wrong. Use a more capable model.
• Did it not try hard enough? It skipped a file, didn’t run the tests, or stopped a refactor halfway. Raise the effort.

The current models

These figures are from Anthropic’s models overview and Claude Code’s model configuration page at the time of writing. Prices and context windows change, so check both before relying on them.

Three notes on reading that table:

• Per-token price is not cost per task. Anthropic’s post makes this point well. On routine work, both a large and a small model generally get it right, and the larger one spends more tokens at a higher rate. On hard, multi-step work the smaller model can burn iterations getting to the same place, so the larger model can cost less per task. And some tasks the smaller model can’t finish at any effort.
• Subscriptions work differently. On Pro and Max plans usage counts against plan limits rather than a per-token bill, and depending on your plan and seat, Fable usage can bill to usage credits instead. In an interactive session Claude Code shows a consent prompt before that happens, except for Enterprise members with organisation billing.
• Haiku has no effort dial. The effort levels only apply to the models listed in Claude Code’s effort table, and Haiku 4.5 isn’t one of them.

In Claude Code, the opus and sonnet aliases currently resolve to Opus 5.5 and Sonnet 5.5 on the Anthropic API (other providers can differ), and the default model on Pro, Max, Team, Enterprise and API accounts is Opus 5.5. Fable is never the account default: you select it with /model fable or claude --model fable.

The effort levels

Claude Code’s documentation describes the levels like this, and I’d take it at its word:

Two more controls are worth knowing. Putting the word ultrathink anywhere in a prompt asks for deeper reasoning on that one turn without changing the session’s level. And the opusplan model setting uses Opus while you’re in plan mode and switches to Sonnet to carry out the approved plan.

You set effort with /effort in a session, --effort at launch, or the CLAUDE_CODE_EFFORT_LEVEL environment variable. In the /effort slider, Enter saves the level as your default for that model and s applies it to the current session only. max applies to the current session only unless you set it through the environment variable.

Matching them to analytics work

This is how I’d map the common jobs. It’s a starting point, not a rule, and Anthropic’s advice is to start from each model’s default effort and adjust it as a general preference for the kind of work you do, rather than task by task.

Some patterns behind the table:

Lookups are about latency. If you’re asking where [Waiting List] is defined, you want the answer in seconds and you’ll check it yourself. Low effort on Sonnet is plenty. Better still, don’t let lookups clog your main session; the built-in Explore subagent handles searches in its own context.

Routine code is about scope, not model size. “Add a referral_source column to stg_referrals and carry it through to mart_referrals_weekly” is well specified. Sonnet at its default does this well, and the time goes into your review, not its reasoning.

Debugging is where effort pays. A common reason for a wrong answer on a reconciliation problem is that the agent didn’t check something: it didn’t compare against the source, didn’t look at the join cardinality, didn’t run the test. That’s an effort problem. Raise the level, and say what “checked” means in the prompt.

Genuinely hard problems need a bigger model. If it has the data, the definitions and the tests, and it still produces a confident wrong answer, more effort just produces a longer wrong answer. Move up a model.

Long builds need both. A multi-hour build on a large model at a high level costs more per token, but it’s the case where the extra verification saves you the most review time.

Speed, cost and depth

Qualitatively, speed falls as you go up in model size and effort: Haiku is the fastest, Fable the slowest, and higher effort means more steps before an answer. Depth rises with both, with diminishing returns at the top, so max isn’t a free upgrade. Cost per token rises with model size, but cost per task depends on the task, as above.

Two cost details from the docs matter for daily work. Switching the main model with /model also changes the model of subagents that inherit it, so a switch to Opus before a big fan-out makes all of that work run on Opus. And every subagent’s tokens count towards your usage, so giving routine subagents a smaller model is one of the easier savings.

Make it a habit, not a decision

The worst way to use these dials is to agonise over them for every prompt. The best way is to set up two or three defaults for the kinds of session you actually run, and switch only when a result tells you to.

My own shell does this with three functions:

cld() { claude --model claude-opus-5-5 --effort xhigh "$@"; }
cldo() { claude --model claude-opus-5-5 --effort xhigh "$@"; }
clds() { claude --model claude-sonnet-5-5 --effort xhigh "$@"; }

cld (and its twin cldo) starts Claude Code on Opus 5.5 at xhigh; clds does the same on Sonnet 5.5. A few details make these better than typing flags:

• They pin full model IDs. claude-opus-5-5 rather than the opus alias, so the model only changes when I edit the function. The cost of that is remembering to update them when a new model ships.
• --effort applies to that session only, so launching one never changes the saved default for other sessions.
• "$@" passes everything else through, so cld --worktree tmdl-refactor or clds -p "summarise this diff" work as expected.

They also encode a preference. Both start at xhigh, two levels above the default for these models, which suits long build sessions. For a quick lookup I’d drop the level for that session only with /effort and s. If I found myself doing that a lot, I’d add a fourth function along the lines of claude --model claude-sonnet-5-5 --effort low.

The same idea works at project level. A model setting in .claude/settings.json sets the starting model for everyone who opens the repo, unless they launch with --model, and a subagent’s front matter can set its own model and effort, so a search helper can run on Haiku while the main session stays on Opus.

For the rest of the day-to-day workflow, see A Claude Code workflow for analysts and BI developers. For running several agents at once, see Subagents and parallel work, and for getting the prompt itself right, Prompting for analysts.