Model Tiering Checklist: Matching Task Complexity to Model Cost
Model tiering means routing each request to the cheapest model in the Claude lineup that can still meet your quality bar, rather than defaulting every call to the strongest one.
This checklist gives you concrete signals to walk through when deciding whether a task belongs on Claude Haiku 4.5, Claude Sonnet 5, or Claude Opus 4.8.
How to Use This Checklist
- Walk the signals in order for a given task category, not for every individual request.
- A "yes" to a higher tier's signals pushes you up; a task that clears none of them belongs on the cheapest tier.
- Record the tier decision per task category, not per user or per session, so the routing logic stays maintainable.
- Revisit the decision whenever the task's inputs, stakes, or volume change meaningfully.
- Pair this checklist with an actual evaluation set; a checklist narrows the search, it doesn't replace measuring pass rate at each tier.
Task Complexity Signals (1-6)
- Number of reasoning steps: Does answering require chaining several dependent steps (e.g. multi-part math, multi-hop lookups), or is it a single-step lookup or transformation?
- Single-step: favors Haiku 4.5.
- Multi-step, dependent reasoning: favors Sonnet 5 or Opus 4.8.
- Ambiguity in the input: Is the request phrased precisely, or does it require inferring intent from vague or incomplete information?
- Precise input: lower tier is usually sufficient.
- Ambiguous input needing judgment: favors a stronger tier.
- Domain specificity: Does the task require specialized reasoning (legal nuance, complex code architecture, nuanced medical language) versus general-purpose text handling?
- General text handling: lower tier.
- Specialized domain reasoning: higher tier.
- Output format complexity: Is the output a fixed, simple shape (a label, a short summary, a yes/no) or an open-ended, structured artifact (a full code review, a long report)?
- Fixed, simple shape: favors Haiku 4.5.
- Open-ended, structured artifact: favors Sonnet 5 or above.
- Sensitivity to subtle errors: Would a subtly wrong answer be hard for a downstream system or human to catch?
- Easy to catch and correct: lower tier acceptable.
- Hard to catch, likely to propagate: favors a stronger tier.
- Need for extended reasoning depth: Independent of model tier, does the task also need a higher setting on the effort parameter, or would low effort on a stronger model already suffice?
- Consider sweeping effort before assuming a stronger model tier is required.
Cost and Volume Signals (7-11)
- Call volume: Is this task called thousands of times a day, or a handful of times?
- High volume: even a small per-call savings compounds significantly; worth investing in a careful tiering decision.
- Low volume: the cost difference between tiers may not justify the engineering effort of fine-grained routing.
- Latency sensitivity: Does the task sit in a user-facing, low-latency path, or run asynchronously in the background?
- Low-latency, user-facing: a faster, cheaper tier can also improve responsiveness, not just cost.
- Background/batch: latency matters less, leaving more room to justify a stronger tier if quality demands it.
- Marginal cost of a retry: If the cheaper tier gets it wrong and the task is retried on a stronger tier, what does that retry cost in latency and tokens?
- Cheap, fast retry path available: lower tier is a safer first attempt.
- No retry path, or retries are expensive: consider starting on a stronger tier.
- Existing budget constraints: Is there a hard cost ceiling for this workload that a higher tier would break?
- Budget-constrained: this signal can force a lower tier even when quality would benefit from a higher one; document the tradeoff.
- Batchability: Can this task's inputs be processed together, amortizing fixed overhead, or does each request stand alone?
- Batchable: sometimes makes a stronger tier affordable at scale by processing in bulk.
Risk and Stakes Signals (12-16)
- Financial impact of a wrong answer: Does an incorrect output risk direct financial loss (an incorrect charge, a bad trade, a wrong refund amount)?
- Direct financial impact: favors a stronger tier and, often, human review regardless of tier.
- User-facing versus internal: Is the output shown directly to an external user, or used internally where a human reviews it before it has consequences?
- Internal, reviewed before use: lower tier is more defensible.
- Directly user-facing with no review step: favors a stronger tier.
- Compliance or legal exposure: Does the task touch regulated content (medical, legal, financial advice) where an error carries compliance risk?
- Regulated content: favors a stronger tier, and likely additional guardrails beyond model choice alone.
- Reversibility of the resulting action: If the model's output triggers an action, is that action easy to undo?
- Easily reversible: lower tier is more defensible.
- Hard or impossible to reverse (an email sent, a payment processed): favors a stronger tier and added safeguards.
- Brand or trust impact: Would a visibly wrong answer damage user trust in the product, beyond the immediate task?
- High visibility, trust-sensitive surface: favors a stronger tier even if the underlying task seems simple.
Process and Maintenance Signals (17-20)
- Do you have an evaluation set for this task category? Without one, a tiering decision is a guess.
- No eval set: build one before committing to a tier, even a small one.
- Eval set exists: use it to validate the tier choice, not just intuition.
- Has this task category's difficulty changed recently? New input types or edge cases can shift what tier is actually needed.
- Stable task shape: prior tier decisions likely still hold.
- Recently changed inputs or scope: re-validate the tier choice.
- Is the routing decision documented anywhere? An undocumented, ad hoc tiering choice is hard for a team to maintain or revisit.
- Document the chosen tier and the signals that justified it, ideally alongside the eval results.
- Is there a fallback path if the cheap tier's confidence is low? Some systems can escalate mid-request to a stronger tier when the cheaper one seems uncertain.
- No fallback: a wrong answer on the cheap tier is final.
- Fallback available: this can justify starting more requests on the cheaper tier.
Applying the Checklist in Order
- Start with Task Complexity Signals (1-6). These determine whether the task is a plausible candidate for a cheap tier at all, independent of cost or stakes.
- Layer in Cost and Volume Signals (7-11) next. These tell you how much the tiering decision is actually worth investing effort into.
- Weigh Risk and Stakes Signals (12-16) last, and let them override the earlier signals. A task that looks simple by complexity signals but carries high financial or compliance risk should still be pushed to a stronger tier or paired with human review.
- Treat Process and Maintenance Signals (17-20) as ongoing, not one-time. A tiering decision that was correct at launch can go stale as the task or its inputs evolve.
FAQs
Should I tier at the level of an individual request or a task category?
Task category, in most systems.
Deciding per individual request is usually impractical to maintain; group similar requests into categories and set a tier per category, revisiting as needed.
What's the simplest starting point if I have no tiering logic today?
Pick your highest-volume task category, build a small evaluation set for it, and sweep it across Haiku 4.5, Sonnet 5, and Opus 4.8 to see where pass rate actually plateaus.
Can a task move down a tier over time?
Yes, if later versions of the cheaper model close the quality gap, or if you learn the task didn't need as much reasoning depth as initially assumed.
Revisit tiering decisions periodically rather than treating them as permanent.
How does this checklist relate to the effort parameter?
Model tier and effort are separate levers.
- Model tier picks which model handles the request.
- Effort tunes how much reasoning that chosen model applies.
- A cheaper model at high effort can sometimes match a stronger model at low effort; consider sweeping both together for the best cost/quality point.
What if a task category has mixed difficulty, some easy requests and some hard ones?
Consider splitting it into sub-categories, or adding a cheap upfront classification step that routes each request to the appropriate tier rather than treating the whole category as one decision.
Is it ever correct to default everything to Opus 4.8?
For low-volume, high-stakes, or genuinely complex tasks, yes, that can be the right call.
For high-volume or simple tasks, defaulting to the strongest tier usually means paying for reasoning depth the task never uses.
What's the biggest mistake teams make when tiering models?
Making the decision once from intuition and never validating it against real evaluation data, so the tier choice drifts out of sync with the task's actual needs over time.
Do risk signals really override complexity signals?
Yes, that's intentional.
A task can look simple by reasoning-step count and still carry enough financial, compliance, or reversibility risk that it warrants a stronger tier or added human review regardless of how "easy" the reasoning looks.
How often should I re-run the tiering decision?
Whenever the task's input distribution changes, whenever a new model becomes available in the lineup, or on a regular cadence (quarterly is a reasonable default) for high-volume categories.
Does having a fallback to a stronger tier change the initial tiering decision?
Yes, a reliable escalation path can justify starting more requests on a cheaper tier, since a low-confidence result can be caught and re-routed rather than shipped as-is.
Should latency ever outweigh quality in a tiering decision?
For genuinely low-stakes, user-facing, real-time paths, yes, a faster and cheaper model can be the right tradeoff even at a small quality cost.
For anything touching money, compliance, or hard-to-reverse actions, latency should not be the deciding factor.
Related
- How Context Engineering Reduces Token Spend - where model tiering fits among the other cost levers.
- Tuning the Effort Parameter for Cost vs Reasoning Depth - the companion lever within a single chosen model.
- ADR Template: Setting a Context Window Budget for a Production Agent - documenting a related class of cost/quality tradeoff decisions.
- Prompt & Context Engineering Best Practices - a broader checklist that includes model tiering as one practice among several.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official
anthropicPython SDK (latest 0.x release). Model names, pricing, and SDK versions move quickly - verify current specifics at platform.claude.com/docs before relying on them.