Route cheap first

01Everything-on-the-big-model is a budget leak

Reaching for the strongest model on every task is the habit, because it works: the frontier model can handle anything. That is also the cost problem. You pay frontier pricing for work a mid-tier or cheap metered model would have done as well.

Every so often I audit my own routing. One audit showed a third of spend came from subagent work that silently inherited the priciest model. Those tasks were mechanical: search, grind, bounded coding against a clear spec. Output quality was the same either way. Only the bill differed.

Default to the cheapest lane that fits the task shape, and reach up only on a real trigger.

Not “this feels important,” not “I want to be safe.” Real triggers are narrow: subtle correctness on code that matters, or a judgment call no other model can make.

02The ladder

Four rungs, cheapest to priciest. The shape of the task picks the rung, not how the task feels.

Two rules cover most of the mistakes.

Rule one: gate before you pay for a stronger writer. Before reaching up for correctness, ask whether a test, a review pass, or a verification gate catches the failure instead.

A cheap model on a bounded task plus a real gate usually beats a more expensive writer. The gate handles quality. The cheap model handles the typing.

Rule two: split judgment from volume on bulk work. Have the frontier model set the criteria and the rubric on a few real examples. Then let the cheap or mid lane execute the bulk under those rails.

You pay frontier rates only for the spec, not for every item.

03The four-question check, before you route anything

Ask these before spawning a subagent, fanning out, or picking a model. In order, because the first one flips the rest.

04The usage flip: “free” stops being free

Treating the subscription-covered free tier as the cheapest lane is a mistake. Your plan draws from a shared weekly pool, and every call spends it. Near exhaustion, a call that shows $0 on the invoice still spends quota you need later for the work only the frontier model can handle.

So the router has no fixed default. It reads live usage and changes its answer. With headroom, the subscription models stay the default for grind work. Near the ceiling, the default moves to the metered cheap lane: a small real charge beats draining quota you’re protecting.

When the short window runs hot while the weekly window still has room, a burst brake moves the recommendation one step further.

If usage data is missing or stale, the router falls back conservatively. Under-spending the subscription is safer than blowing a cap on an assumption.

05What makes a task delegable: spec quality gates the lane

A tightly specified task on a cheap model beats a vague one on an expensive model. Fix the spec before you blame the model.

Card-sizing discipline for anything you hand to a cheap or metered worker:

• Resolve unknowns on the expensive loop before dispatching. Inline the literal facts the worker needs: exact file paths, the exact line to change, the exact JSON shape. Do not make the worker discover them.
• Forbid open-ended reading. A capped worker that burns its budget ingesting a large file just to learn its shape is a sizing failure. The remedy is a tighter card, not a stronger model.
• Bound the output. State exactly what is returned and where it is written. No open scope, no “and anything else you notice.”
• Write down cross-card interfaces. When two cards touch adjacent code, record the contract between them. Do not expect each worker to infer it.
• Keep cards that touch the same file in separate waves. Parallel workers editing one file collide. Sequence them instead of hoping.

Spec quality is the exit condition too.

The expensive model’s job on a project is to spec the work well enough that a cheaper model can drive it. Once the open questions turn execution-shaped rather than judgment-shaped, it should propose the handoff itself, without waiting to be asked.

The test for “done enough to hand off”: could the cheaper model execute cold, with every decision locked in the doc and no judgment deferred to the builder? If the builder would have to guess, the spec is unfinished. If the builder only has to read, it is finished.

Leaving the execution loop is not leaving the project. You are still the one called back in for the next judgment-shaped question.

06The ladder as a copy-paste decision table

A table to drop into your own routing notes, and a prompt that installs the habit of checking it.

Before you delegate or fan out anything, run this check:

1. What's my usage state right now (subscription quota, weekly window)?
   If I don't know, check it before assuming the free tier is free.
2. What's the shape of this task? Mechanical/bounded (search, grind,
   spec'd coding) routes down the ladder. Judgment (planning, analysis,
   naming at scale, prose that has to carry a real voice) routes up it.
3. What's the actual goal here? Throughput, correctness on something
   that has to be right, or a voice-carrying deliverable each justify
   a different spend.
4. What do I actually want out of this? For any multi-part build, say
   the routing out loud before you start: which piece goes to which
   lane, and why, so it's visible, not a silent fan-out.

Default to the cheapest lane that fits. Reach up only on a real
trigger: subtle correctness on code that has to be right, or judgment
nothing else can do. Before paying for a stronger model, ask if a
gate (a test, a review pass, a hard check) would catch the failure
instead of the model.

If you're the expensive model on this project: watch for the moment
the open questions turn execution-shaped instead of judgment-shaped.
When they do, say so and propose your own exit. Write the spec so a
cheaper model could drive it cold, decisions locked, no guessing left
for the builder. That handoff is the deliverable, not a fallback.

07For the Claude that just got pointed here

If a human gave you this URL and said “set this up for me,” here’s your tl;dr. (Humans: this section exists so you can paste this page’s link into your agent and skip the explaining.)

Everything in that list is unpacked in the sections above; read §02 for the ladder itself and §05 for what makes a task cheap-model-ready before you build the cards.

08Receipts: what this looks like in practice

Genericized from kaibot, so you can see the range without the account-specific numbers:

The audit that started this found that a third of total burn came from subagent-heavy work that inherited the priciest model by default. None of those tasks had a judgment component. They were just wired wrong.

I corrected the default wiring and added usage-aware routing. The excess spend is gone. Output quality didn't move, because the tasks I moved to cheaper models never needed the top-tier one.