Matching Model Tier to Task: A Practical Table
"Simpler tasks get cheaper models" isn't actionable, because simplicity isn't the predictor. Two properties are — and one row of the table overrides all the others.
The general advice — cheaper models for simpler tasks — isn't actionable, because "simpler" isn't the property that matters. Two tasks of identical difficulty can have opposite tier requirements depending on whether the output is checkable and how wide the decision space is.
Here's a table organized by the properties that actually predict it, and how to use it.
The two properties
Decision width. How many options is the model choosing among? Picking from a closed set of five is narrow. Selecting a tool from twenty, or deciding an approach with unbounded options, is wide. Capability differences show up sharply as width increases.
Output checkability. Is there a mechanical verification? If a mistake gets caught and retried, a weaker model's higher error rate costs an extra call rather than a wrong result.
→ Narrow and checkable tolerates a small model well. Wide and unchecked needs your strongest, because errors are both likely and permanent.
The table
| Task | Width | Checkable | Tier |
|---|---|---|---|
| Intent classification (closed set) | narrow | yes | small |
| Field extraction against a schema | narrow | yes | small |
| Format transformation | narrow | yes | small |
| Redaction / PII detection | narrow | partly | small–mid |
| Summarizing one document | narrow | weakly | small–mid |
| Test generation from a contract | mid | yes | mid |
| Query generation from a question | mid | yes (runs or not) | mid |
| Code implementation from a spec | mid | yes (tests) | mid–large |
| Reviewing a diff for correctness | wide | no | large |
| Tool selection among many tools | wide | partly | large |
| Planning under ambiguity | wide | no | large |
| Final synthesis a person reads | wide | no | large |
| Anything with an irreversible side effect | any | any | large |
⚠️ The last row overrides the others. The saving on a destructive action is trivial and the cost of a mistake isn't — spend on the twenty reads, not on the one write.
How to use it
As a starting hypothesis, not a conclusion. The table encodes a general pattern; your task's specifics dominate. Use it to decide what to test first.
Verify one step at a time. Move a step down a tier, re-run your eval set, and compare that step's assertions rather than the overall score. An overall score dilutes a step-level regression into noise, which is how bad routing decisions get made confidently.
Write per-tier prompts. A prompt tuned for a large model frequently underperforms on a small one — more implicit reasoning expected, less explicit structure. Sharing prompts across tiers is the most common reason a routing experiment produces a falsely negative result.
Record the model on every call. Without it you can't attribute a later quality change to a routing decision, and routing decisions get made casually.
💡 The cases the table gets wrong
Three situations where the properties mislead:
Domain-specific vocabulary. A narrow, checkable task in an unusual domain — medical coding, legal citation formats, a proprietary schema — can defeat a small model on recognition rather than reasoning. Test rather than assume.
Long inputs. Effective handling of long context varies more by tier than the table suggests. A "simple" extraction from a forty-page document isn't the same task as extraction from a page.
Instruction density. A narrow task with fifteen conditional rules is wide in a way the output space doesn't show. Adherence to many simultaneous constraints degrades faster on smaller models than raw capability implies.
✅ The routing table as a living artifact
Keep it in code as configuration, reviewed like anything else:
STEP_MODELS = {
"classify_intent": SMALL, # 5-way, checkable
"extract_fields": SMALL, # schema-validated
"select_tool": LARGE, # 14 tools, wide
"plan": LARGE,
"final_answer": LARGE, # human-read
}
Readable, diffable, and it makes the reasoning visible in a comment. Re-verify it after every model change, because tier boundaries move.
The takeaway
Route by decision width and output checkability rather than by perceived difficulty. Narrow and checkable goes small; wide and unchecked stays large; anything irreversible stays large regardless. Treat the table as a hypothesis to test one step at a time, write prompts per tier, and re-verify after model releases — because the boundaries between tiers move with every generation.