The Model Router: Three Models, One Job, One Real Winner

# The Model Router: I Gave Three Models the Same Job. The Winner Was a Rule.

I gave my smartest model, my mid model, and my cheapest model the exact same job. Watch that
fight and you'll want to know which one won — but the real answer isn't a model at all. It's a
rule: send every task to the cheapest model that can still do it. Get it wrong in either
direction and you lose — either you're burning your most expensive model on mechanical work, or
you're starving a judgment call with your cheapest one. This page hands you **The Model
Router** — the exact tier table, the one decision question, and a worked example routed start
to finish.

## Why picking one favorite model always leaks money or quality

Most people default to one model for everything. It feels simpler — one habit, no deciding. But
your smartest model's real cost isn't the price per token, it's that its output is the scarcest,
most load-bearing thing you have. Spend its turns typing routine code and it never gets to spend
them on the plan or the verdict only it should make. Run the reverse — mechanical grading or
sorting through your cheapest tier — and you save nothing, because that work was already cheap
to do right. The router fixes both leaks at once.

1. Read the tier table once. ROUTING-RULES.md maps three task classes — judgment,
building, mechanical — onto your smartest, mid, and cheapest model. Building is the default;
when in doubt, that's where a task goes.

2. Ask the one question before you start a task. "Is this judgment, building, or
mechanical?" Judgment (plans, red-teaming, verdicts, architecture calls) → smartest tier.
Mechanical (grading against a rubric, classifying, read-only passes) → cheapest tier.
Everything else → mid tier.

3. Pin it per task CLASS, not per task. If your tool supports per-task model pinning
(subagents, custom modes), set the default tier for a task TYPE once. You stop re-deciding
from scratch every single time — that's where the compounding actually happens.

4. Keep verification separate from building. A model grading its own work is a weak
check — a fresh, cheap pass with no memory of "how it was built" catches things a
self-check talks itself out of. Route grading to your cheapest tier whenever the rubric is
objective; only escalate to the smartest tier when the grading itself needs judgment.

5. Write the two-line rule down, once. "Read-only, classification, and mechanical passes
always go to the cheapest tier that can still do the job. Judgment, planning, and verdicts
stay on the smartest tier — never the reverse." Put it in whatever file your AI tool reads at
the start of every session. That's the whole install.

- ROUTING-RULES.md — the full tier table, the one decision question, and the structural
reason it works
- CHEATSHEET.md — one printable page: task class → tier, nothing else
- EXAMPLE.md — a real research → build → verify job, routed end to end, with the reasoning
at each step

Comment ROUTER on today's video and the kit lands in your DMs — or grab it right here with
the button above. The comment word resets at 4pm today when tomorrow's drop lands.