Model picks latency, the spec picks quality: choosing effort in Claude Code

TL;DR: The instinct when an agent produces something wrong is to reach for a bigger model or a higher reasoning effort. After months of daily agent work the rule I actually operate by is nearly the opposite: on well-specified work, the model is a latency lever, not a quality lever. Quality is carried by the spec. The heavy thinking, done once in a plan, gets transcribed into code by a faster setting without much loss. Most of the errors people try to fix by cranking effort come from oversized chunks, gaps in the spec, or the model not knowing the codebase conventions - and none of those get fixed by more effort. This is how I decide what to spend where.

The truth the rest hangs on

On a task that is genuinely well specified, moving from a faster setting to the slowest, most expensive one mostly buys you latency, not correctness. The reasoning that determines whether the result is good already happened in the plan. If the plan is tight and the conventions are written down, a quicker setting will transcribe it into working code just fine. The errors that do show up trace back to something the plan left ambiguous, a chunk too big to hold, or a convention the model was never told - and turning the effort dial up does not supply a missing spec.

This matters because it inverts the default reaction. When output is wrong, the productive move is usually to tighten the spec or shrink the chunk, not to escalate the model. Escalation is for a specific, narrower case.

Two buckets

The mental switch I make on every task is a single question: does this need thinking, or does it need transcribing a plan into code?

Thinking goes to the top of the range; transcription goes to the fast part of it. The rule of thumb is exactly that question, asked honestly, before the work starts.

Split inside a complex feature, too

The mistake is treating the implementation of a hard feature as one uniform block. It is not. Inside a single feature the buckets still apply:

• Plan and architecture - how the algorithm works, which approach, the shape of the system - gets the top of the range. This is where thinking lives.
• Core logic - the heart of the algorithm, the actual differentiator - stays on the strongest model. This is the one place I do not gamble on a downgrade, because the gap between models is widest exactly on hard, novel logic, and if cost is not the constraint there is nothing to save by cutting it.
• Scaffolding - schema, endpoints, wiring, admin UI, glue - goes to the fast setting. It is mechanical and it should be quick.

"Much faster overall" comes from running the core on the strong model at a lower effort and the scaffolding on a fast one - not from downgrading the core. The crown jewel keeps its setting; everything around it gets quick.

The bigger lever: not spiraling

The real productivity killer is not the model choice, it is the ten-rounds-of-fixes spiral, and the way out of it has almost nothing to do with which model you picked. Work in small chunks with a review at each milestone, so you catch a mistake on a fragment instead of after five hundred lines. Keep plans tight and conventions written, because the model reads them. Aim for fast cycles, not a perfect first shot. And for anything algorithmic, measure, do not eyeball - you cannot judge whether a matching result is good by looking at one example, so you build a small evaluation harness alongside it and let the metrics tell you better or worse. Without that, you spin in circles no matter which model is running.

Escalation has its place inside this loop, but as a reaction, not a default: start at a middle setting, and only bump to the top when two honest attempts have not landed. The switch takes seconds, so there is no penalty for guessing low first - which means there is no reason to pay the latency of the maximum setting on work that never needed it.

Context is signal-to-noise, not a percentage

A related habit that pays off: the old "compact the conversation at half full" rule is outdated when context windows are enormous. But the principle underneath it survives, and it was never about the percentage. A cluttered context degrades quality well before it hits any limit - a long, meandering conversation is worse than a focused short one holding the same facts. So the better practice is one session per focused task, a fresh session when the topic changes, and manual compaction only when you feel the quality slipping - the model losing the thread, repeating itself, dropping earlier detail - rather than at any particular number. Writing durable knowledge into project docs is what makes fresh sessions cheap, which is what lets every session stay focused, which is where the models are at their best.

What carries over

• Spec carries quality; model carries latency. On well-specified work, a bigger model mostly buys speed, not correctness.
• Ask "think or transcribe?" per task. Thinking goes to the top of the range, transcription to the fast part.
• Do not downgrade the crown jewel. The model gap is widest on hard, novel logic; keep the core strong and speed up the scaffolding.
• Small chunks beat model choice. Review per milestone is the real defense against the endless-fixes spiral.
• Measure algorithms, do not eyeball them. An evaluation harness tells you better or worse; intuition just spins.
• Escalate as a reaction, not a default. Start middle, bump only after two attempts miss; the switch is free.