Español

Match the Model Tier to the Scope

You're paying top-tier reasoning prices for a one-line fix. Every major provider ships a ladder of models — a fast, cheap tier and a slow, deep-reasoning flagship — yet most developers pin one model and route everything through it. The fix costs one extra second of thought: classify the task's scope first, then pick the tier.

The scope ladder

Before you type the prompt, put the task on a five-rung ladder:

The payoff is asymmetric. Anthropic's own model-selection guide prices its most capable widely released model at $10 per million input tokens and $50 per million output tokens, while its fast tier (Haiku-class) is positioned as "the most economical price point" for high-volume, straightforward tasks. On a trivial edit, the flagship isn't just more expensive — it's usually slower, because deep-reasoning modes spend tokens thinking about a problem that has nothing to think about.

Why the fast tier wins on small scope

A one-line change has a small context, an obvious success criterion, and a cheap failure mode: if the fast model gets it wrong, you see it instantly and retry. That's exactly the profile where provider docs point you at the small model — Anthropic recommends starting with Claude Haiku 4.5 for "high-volume, straightforward tasks" and upgrading only for specific capability gaps. Google's Gemini lineup makes the same split explicit: Flash-Lite is billed as "fastest, most cost-effective," Pro as the deep-reasoning tier for complex tasks.

The reverse also holds. Architecture decisions, migration plans, and epic-scoped agentic work have huge context, fuzzy success criteria, and expensive failure modes — a wrong design costs days, not a retry. That's where the flagship's extra reasoning is worth every token.

The two starting strategies

1. Start cheap, escalate on failure — for trivial/low scope. Run the fast tier; if the output misses, escalate one rung. Most small tasks never escalate.
2. Start smart, optimize down — for high/epic scope. OpenAI's model-selection guide is blunt about the order: optimize for accuracy first with a capable model, and only then "aim to maintain accuracy with the cheapest, fastest model possible." Their worked example distilled a task down to a small model at roughly 2% of the original cost — after the frontier model proved the approach.

Both strategies agree on the core move: the tier is a per-task decision, not a per-project default.

Power-user moves

• Make classification a habit, not a ceremony. One second: "is this trivial, low, medium, high, or epic?" Say it before the prompt. In agent workflows, encode it — many coding tools let you set the model per session or per subtask, so route trivial subtasks to the fast tier automatically.
• Use effort/reasoning knobs before switching models. Recent flagship models expose an effort or thinking-budget parameter that trades intelligence for latency and cost within a single model — Anthropic's guide notes tuning effort "is often a better lever than switching models." Low effort on a flagship can beat a mid-tier model for medium-scope work.
• Escalate on evidence, not vibes. If the fast tier fails the same class of task twice, that class moves up one rung permanently. Keep the ladder honest with a few benchmark prompts from your real workload.
• Watch the output side. Output tokens are typically ~5x input price. Verbose flagship reasoning on a trivial task multiplies the waste twice: higher rate and more tokens.

Resources

• Choosing the right model — Anthropic
• Model selection guide — OpenAI
• Gemini models — Google AI for Developers
• Claude models overview (specs and pricing) — Anthropic