Model Routing

Providers sell models in tiers — for Claude: Haiku (fast, cheap), Sonnet (the everyday workhorse), Opus (deepest reasoning, priciest). The gaps are not subtle: cost per token moves roughly 4–5x per tier boundary, so the top tier can run an order of magnitude above the bottom. Model routing is the practice of matching each piece of work to the cheapest model that does it well — the biggest cost lever most people never touch, because they picked a model in January and pay its rate on everything all year. This lesson: the two-question decision that makes routing rigorous, where routing decisions actually live in your tools, and how to route on evidence instead of vibes.

The two-question decision

Routing collapses into two questions per task, and the mistake is asking only the first:

1. How steep is the capability curve here? Some work is capability-flat — the cheap model's output is indistinguishable from the expensive one's: renaming across files, boilerplate from a clear example, summarizing diffs, mechanical test scaffolding, format conversions. Some work is capability-steep — the tier gap is the difference between an answer and a liability: architectural decisions, subtle concurrency bugs, security review, ambiguous requirements, anything where the hard part is judgement rather than throughput.

2. What does a mistake cost — and when do you find out? This is the question that upgrades routing from penny-pinching to engineering. A wrong variable name costs one re-run, caught instantly by the compiler. A wrong schema migration costs a weekend, caught in production. The rule: route by the price of being wrong times the delay in noticing, not by how impressive the task sounds. Cheap-to-verify, cheap-to-retry work tolerates cheap models even when it's tricky — your safety net (tests, review, evals) catches the misses at low cost. Expensive-to-detect failures justify the expensive model even for "simple" tasks, because no net catches them early.

Put the two questions together and you get a quadrant worth memorizing:

	Cheap to verify	Expensive to detect
Capability-flat	cheap model, always	cheap model + mandatory check
Capability-steep	cheap draft, strong review	strong model, no debate

Where routing lives in practice

Interactively: /model switches mid-session, and plans survive the switch — they're just context (lesson 2). The efficient rhythm on hard problems: design on the strong model (produce an explicit plan: files, approach, risks), downshift for the mechanical middle (applying the plan across forty files is capability-flat by construction — the plan removed the judgement), upshift for the gnarly integration at the end. You'll feel the trick: a good plan is a machine for converting capability-steep work into capability-flat work, which is why planning on the expensive model saves money.

Structurally: sub-agents each specify their own model (lesson 11 — in Claude Code, custom agents declare a model in their definition). This is where routing becomes architecture: an orchestrator on the strong model decomposes and synthesizes; fleets of cheap workers grind the per-item middle (lesson 22 builds this out). Judgement priced at judgement rates, throughput at throughput rates, in one pipeline.

In automation: headless and scheduled runs (lessons 17–18) should pin the cheapest model that passes their eval — automated volume is exactly where per-token price multiplies into real money, and exactly where nobody's watching quality drift (see the failure catalog).

Routing on evidence

Whether the cheap model suffices is an empirical question, and lesson 21 gives it the full treatment: run both tiers against a scored sample, compare numbers, route on the result. Short of a full eval, the blind spot-check works surprisingly well: route ten representative items through each tier, shuffle, review without labels. If you can't tell which came from where, you've found free money — and you'll be surprised how often you can't.

Two development-time heuristics until you've measured:

• Build prompts against the cheap model. A prompt that works on Haiku works on Opus; a prompt tuned on Opus may be leaning on capability to paper over its own vagueness — weakness you'll pay for on every future run, at Opus rates. Develop cheap, then measure whether upgrading buys anything.
• Split generate and verify across tiers. Cheap-draft-strong- review and strong-generate-cheap-check both beat single-model on cost-quality; which wins depends on whether generation or judgement is the hard half of your task. (Adversarial review by a strong model is one of its highest-value uses per token.)

The failure catalog

• Prestige routing. The top model for everything, because it "feels safer." On the 80% of work that's capability-flat it buys slower responses and a 5x line item — the most expensive comfort blanket in your toolchain.
• Silent downgrade drift. Cost pressure pushes tasks down-tier; nobody measures; defects rise weeks later, unattributed to the routing change that caused them. The rule: every deliberate downgrade ships with its check — an eval score, a scheduled spot-review — or it isn't engineering, it's hoping (lesson 21's whole thesis).
• Uniform routing of non-uniform work. "The pipeline uses Sonnet" is a smell when the pipeline contains both classify these 2,000 lines and decide whether this API change breaks consumers. Split the pipeline; route the pieces (lesson 22 makes the split natural).
• Latency blindness. Cost isn't the only axis — the cheap tiers are also fast, and for interactive loops (autocomplete-grade tasks, quick queries mid-session) the strong model's latency is a real tax on your attention. Route hot-path interactivity down for speed even when cost is a rounding error.

The one-sentence version: capability is a spectrum, price is a spectrum, and your work is a spectrum — routing is refusing to collapse three spectrums into one default. The teams that internalize it run their serious volume at a fraction of list price and reserve the expensive tokens for the moments that are actually worth them.