Big model at low effort beats small model at max

You have a task that needs actual judgement — a refactor across three files, a bug whose cause you cannot guess — and you are sitting there watching the spinner. The reflex is to reach for a cheaper, faster model. There is a second dial that does the same job, and the claim here is that it is usually the better one to turn.

Claude Code gives you two independent knobs: which model answers, and how much reasoning it spends per turn. They are set separately, with /model and /effort, and most people only ever move the first.

The two ways to spend less

The claim, from Anthropic PM Matt Bleifer's Code w/ Claude 2026 talk "The thinking lever": on a task that needs intelligence and needs to be quick, drop the effort on the big model rather than dropping to a small model at max. In his live demo the big model at low effort spent roughly the same number of output tokens as the small model at max, took only slightly longer, and produced a visibly better result.

He splits the two on which latency you care about:

• Small model — fast time to first token, and bulk work that is not intelligence-sensitive: classification, extraction, basic summarising, mechanical edits at volume.
• Big model at low effort — fast time to last token on anything where the answer has to be right.

What the docs actually back

The docs never make this trade. What they do document is the mechanism underneath it, and one line in particular is why the comparison is not absurd:

The effort scale is calibrated per model, so the same level name does not represent the same underlying value across models. — model configuration

low on Opus is not the same amount of thinking as low on Haiku, and it is not comparable to max on Haiku either. The ladder is relative to the model you are on, which is exactly what makes "big model, low effort" a real point in the space rather than a contradiction.

The same page's effort table also supports the other half of his framing:

• low — "Reserve for short, scoped, latency-sensitive tasks that are not intelligence-sensitive"
• max — "Can improve performance on demanding tasks but may show diminishing returns and is prone to overthinking. Test before adopting broadly"

That last row is the docs agreeing that max is often not where the value is. If you are running a small model at max to compensate for the model, you are paying for the ladder's least reliable rung.

Trying it

Set the model, then the effort — they are separate commands:

/model opus
/effort low

Where that level gets saved matters if you switch models often. Run /effort interactively on your own machine and Claude Code saves the level for the active model under modelSettings in your user settings, so the big model can sit at low while everything else keeps its own rung. That per-model key "Requires Claude Code v2.1.251 or later"; the effortLevel entry records what came before it — "Before v2.1.251, /effort wrote this key" — which meant one shared default across every model rather than a level remembered per model.

Or in one launch, which is the form you want on any model where Claude Code holds the model's own default effort until you change it once:

claude --model opus --effort low

The session header shows the active level next to the model name ("with low effort"), so you can confirm which rung you are actually on instead of assuming.

What is unverified here

Be clear-eyed about how thin the evidence is:

• Nobody in this project has run it. The result comes from one live demo of one toy prompt (a traffic simulation) in a conference talk. It is not a benchmark, and no numbers were published alongside it.
• The source is a community machine transcript of that talk, with speaker labels assigned by transcription software, not by a human.
• The model generation named is already old. The demo compared Opus 4.7 against Haiku 4.5. Effort is calibrated per model, so the gap on today's models could be wider, narrower, or reversed.
• "Time to first token vs time to last token" is his framing, not documented terminology.
• The token-count claim is not a cost claim, and the talk did not make it one.

What would settle it for your workload: run the same prompt both ways non-interactively and compare the reported usage and cost, then judge the two outputs yourself.

#!/usr/bin/env bash
set -euo pipefail
P='Refactor the error handling in src/ to a single result type, and explain the tradeoff.'
for cfg in "opus:low" "haiku:max"; do
  m="${cfg%%:*}"; e="${cfg##*:}"
  start=$(date +%s)
  claude -p "$P" --model "$m" --effort "$e" --output-format json > "/tmp/eff-$m-$e.json"
  echo "$m/$e  $(( $(date +%s) - start ))s"
  jq '{cost: .total_cost_usd, usage: .usage}' "/tmp/eff-$m-$e.json"
done

Run it on a task from your own repo, not a toy one, and read both answers before looking at the numbers. The interesting question is not whether the token counts match — it is whether the cheaper-model answer was one you would have shipped.