Which model for which job: a routing rule that cuts the bill

Most teams send every task to whichever model they last opened in chat, which means routine work quietly pays frontier-tier prices. Anthropic's published API rates put a real number on that waste: as of this writing, Claude's cheap tier (Haiku-class) runs $1 input / $5 output per million tokens, the daily tier (Sonnet-class) runs $2 input / $10 output, and the frontier tier (Opus-class) runs $5 input / $25 output (Claude API pricing) — output costs scale roughly 1x, 2x, 5x across the three tiers.

Route by task shape, not by task importance

The instinct is to reach for the frontier model whenever a task feels important. The better signal is task shape: how much judgment does this step actually require, independent of how much you care about the outcome. A mechanical task — extract fields from this log line, format this JSON, summarize this diff in one sentence — doesn't get better with a frontier model, it just gets more expensive. A task with real ambiguity — should this retry logic live in the client or the server, why does this race condition only happen under load — is where the extra reasoning of a frontier-tier model earns its 5x price.

A ten-line router

def route(task_type: str) -> str:
    cheap = {"extract", "format", "classify", "triage", "summarize"}
    frontier = {"architecture", "ambiguous_bug", "security_review"}
    if task_type in cheap:
        return "haiku-class"
    if task_type in frontier:
        return "opus-class"
    return "sonnet-class"  # default: most coding work

The point isn't this exact function — it's that the default branch, not the frontier branch, should be where most tasks land. If your router's else clause returns the frontier tier, you've built a router that routes everything to the most expensive option by default, which defeats the purpose.

Measure quality before you trust the cheap tier

Don't drop a task to a cheaper tier on faith. Run the same 10–20 real examples through both tiers, diff the outputs, and check whether the cheaper model's mistakes are the kind you'd catch in review anyway (a slightly worse variable name) versus the kind that slip through (a subtly wrong extraction). Mechanical, well-specified tasks tend to hold up fine on the cheap tier; anything where "good" is a judgment call degrades faster than it looks like it should from a handful of examples.

Keep the comparison itself cheap: you don't need a formal eval harness for this, just a spreadsheet with the input, both outputs side by side, and a pass/fail column you fill in by eye. The goal isn't statistical rigor, it's catching the difference between "stylistically worse" and "factually wrong" before it reaches production. Re-run the same comparison whenever you change providers or model versions — a routing rule tuned for one model generation doesn't automatically transfer to the next.

What this looks like in an agent, not just an API call

The same logic applies inside a single agentic session, not only across separate API calls. A coding agent doing a multi-step task can use a cheap-tier subagent for the mechanical parts of the loop — summarizing a long log file, extracting the failing test names from a build output — while the main loop stays on the daily tier for the actual editing and reasoning. That split is where most of the token savings actually show up in practice, because mechanical sub-steps are often the bulk of the volume even when they're not the reason the task felt hard.

Try it today

1. List the last 10 tasks you sent to an agent and tag each by shape: mechanical, typical coding, or high-ambiguity.
2. Check which model tier actually handled each one.
3. For every mechanical task on the daily or frontier tier, re-run it on the cheap tier and diff the result.
4. Write the three-way split as an explicit rule in your CLAUDE.md or router config, not as a habit you rely on remembering.
5. Track token spend by tier for a week and see where the ratio actually lands versus what you assumed.

Where this breaks

• Task type alone isn't a perfect proxy for difficulty — an "extraction" task on a badly formatted document can need more reasoning than a "typical coding" task on a clean codebase.
• Routing rules rot as models change; what counted as "needs frontier" six months ago may not now. Re-test the boundary periodically, not once.
• Cheap-tier mistakes are often silent rather than loud — budget for spot-checking output quality, not just tracking cost.

Next: how to read an agentic benchmark, so "quality" claims from a model card mean something concrete.