Model Selection Rules: When to Use Opus, Sonnet, or Haiku

These are the enumerated rules this site uses for matching a task to a Claude model tier - Haiku, Sonnet, Opus, or Fable - based on complexity and latency, condensed from the deeper model-family coverage elsewhere on this site into rule form.

How to Use This Checklist

Apply these rules per call site, not once for the whole application - a single app usually spans several tiers.
Start with the "default tier" rule for your task category, then apply the escalation and de-escalation rules to adjust.
Revisit tier assignments whenever Anthropic ships a new model - a rule tuned to Sonnet 4.6's cost profile may no longer hold for Claude Sonnet 5.
Record the reasoning for any non-default tier choice in code review, not just in the code itself.

Default Tier by Task Type

Classification and extraction default to Haiku. Short, well-defined tasks - labeling a support ticket, extracting a field from a form, routing a request - rarely need more than Claude Haiku 4.5's reasoning depth, and it is the fastest, cheapest tier.
General-purpose chat and content generation default to Sonnet. Claude Sonnet 5 is the site's default model tier for a reason - it handles most conversational, drafting, and moderate-reasoning tasks at near-Opus quality without Opus latency or cost.
Multi-step reasoning and hard coding tasks default to Opus. Claude Opus 4.8 is the right default when a task requires holding many constraints simultaneously, planning across several steps, or producing code that must be correct on the first pass.
The most demanding, long-horizon agentic work defaults to Fable. Claude Fable 5 is reserved for tasks that genuinely need its extended reasoning and long-horizon coherence - large autonomous migrations, deep research, or agent loops that run for many minutes unsupervised.
Never pick a tier because it "feels safer." A tier chosen out of caution rather than evidence is a cost and latency decision made without data - require an actual quality gap before escalating.

Escalation Rules (Moving Up a Tier)

Escalate when a lower tier's output fails review on a representative sample. Run 20-50 real examples through the cheaper tier first; escalate only if the failure rate is high enough to matter for the use case.
Escalate when the task requires holding more than a handful of constraints at once. Multi-constraint reasoning - "satisfy these five business rules simultaneously" - is where lower tiers degrade first.
Escalate for autonomous, unsupervised agent loops with real-world side effects. A human reviewing every step tolerates more model error than an agent making payments or filing tickets on its own.
Escalate temporarily during a model transition, not permanently by default. If a new task type is unproven, start at a higher tier to establish a quality baseline, then de-escalate once you have evidence the cheaper tier holds up.
Escalate when the cost of a wrong answer is asymmetric. A misclassified support ticket is cheap to fix; a wrong answer in a financial or medical context is not - let the cost of failure, not just task complexity, drive the tier.

De-escalation Rules (Moving Down a Tier)

De-escalate once a task's output has been stable across enough evaluation runs. If Sonnet has matched Opus's quality on your eval set for a meaningful sample size, move the route down and keep monitoring.
De-escalate any route where output is deterministic or template-driven. Tasks with a narrow, well-specified output shape rarely need the top tier's reasoning depth, regardless of how the task reads in prose.
De-escalate synchronous, latency-sensitive paths first. A user waiting on a response feels Opus's or Fable's added latency directly - if quality holds at Sonnet or Haiku, the latency win alone justifies moving down.
De-escalate before scaling traffic, not after the bill arrives. Running a cost/quality evaluation before a feature goes to full production traffic is cheaper than reacting to a large invoice.

Latency Rules

Treat latency budget and task complexity as independent axes. A task can be complex but latency-tolerant (an overnight batch job) or simple but latency-critical (autocomplete) - decide each axis separately before picking a tier.
Route synchronous, user-facing requests away from the heaviest tier by default. Opus and Fable trade throughput for depth; only put them on a live request path when the task genuinely needs that depth and the UX can tolerate the wait.
Move latency-tolerant heavy reasoning to async or batch processing. If a task needs Opus- or Fable-level reasoning but the user doesn't need the answer synchronously, run it as a background job instead of blocking a request.

Governance Rules

Write down the tier decision for every production route, not just the exceptions. A short comment or config entry naming the model and the reason prevents the next engineer from silently changing it without knowing why.
Review tier assignments on a fixed cadence, not only when something breaks. A quarterly pass through production routes catches routes that should have been de-escalated months ago.
Never let a single engineer's local preference set the tier for a shared route. Model tier is a team-level decision with cost and reliability consequences - route it through the same review any other production config change gets.

FAQs

What's the fastest way to decide a new route's starting tier?

Match the task to its category (classification, general chat, multi-step reasoning, long-horizon agentic work).
Start at that category's default tier.
Only escalate once you have evidence - a failed sample review, not a hunch - that the default tier isn't enough.

Should latency-sensitive tasks always use Haiku?

No - latency and complexity are separate axes. A latency-sensitive task that's also genuinely complex may need Sonnet or a background-processed Opus call rather than forcing Haiku onto a task it can't handle well.

How large a sample do I need before de-escalating a route?

Large enough to be representative of production traffic variety, not just the happy path - 20-50 real examples is a reasonable starting point, more for higher-stakes routes. The goal is confidence, not a specific magic number.

Is it ever correct to run the same task through two different tiers?

Yes - a common pattern is a cheap tier doing a first pass (triage, extraction) and a more capable tier only engaged for the subset of cases the first pass flags as uncertain or high-stakes.

Why does this list treat "feeling safer" as a bad reason to escalate?

Because it's not falsifiable - a decision made from caution rather than measured evidence can't be revisited later with data, so it tends to become permanent even after it stops being justified.

When is Claude Fable 5 the right default rather than an escalation?

For tasks that are inherently long-horizon and autonomous from the start - large-scale code migrations, extended research runs, or agent loops expected to run many minutes unsupervised - rather than tasks that merely turned out to need more reasoning than expected.

Does model selection interact with cost control rules?

Directly - tier choice is usually the single largest lever on per-request cost. See Cost Control Rules for how caching and batching compound with tier selection.

Who should own the quarterly tier review?

Typically whoever owns the team's Claude rules generally - see How Opinionated Rules Prevent Claude Production Incidents for why a single accountable owner matters more than the specific title.

What happens if two routes with similar tasks end up on different tiers?

That's a signal decision drift has crept in - revisit both against the same evaluation criteria and reconcile them, rather than assuming the divergence was intentional.

Should tier decisions be hardcoded or configurable?

Configurable is usually safer - a config value or feature flag lets a tier change be reviewed and rolled back without a code deploy, which matters when a new model ships and the right default shifts.

Is a higher tier ever wrong even when the team can afford it?

Yes - beyond cost, an unnecessarily heavy tier adds latency that degrades UX on synchronous paths and can make behavior harder to predict for tasks that a lighter, more constrained model would have handled more predictably.

How does this list relate to the deeper model-family content elsewhere on the site?

This page is the condensed rule form; the token-economics and claude-model-family sections cover the underlying cost, latency, and capability details these rules are derived from.

How Opinionated Rules Prevent Claude Production Incidents - why writing these rules down matters more than any single tier choice.
The Core Claude Rules: A Quick-Reference List - the condensed version of these rules alongside every other category.
Cost Control Rules: Caching, Batching, and Token Budget Discipline - how caching and batching compound with the tier choices made here.
Claude Rules Best Practices - every rule in this section restated as one checklist.

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 anthropic Python 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.

How to Use This Checklist

Apply these rules per call site, not once for the whole application - a single app usually spans several tiers.
Start with the "default tier" rule for your task category, then apply the escalation and de-escalation rules to adjust.
Revisit tier assignments whenever Anthropic ships a new model - a rule tuned to Sonnet 4.6's cost profile may no longer hold for Claude Sonnet 5.
Record the reasoning for any non-default tier choice in code review, not just in the code itself.

Default Tier by Task Type

Classification and extraction default to Haiku. Short, well-defined tasks - labeling a support ticket, extracting a field from a form, routing a request - rarely need more than Claude Haiku 4.5's reasoning depth, and it is the fastest, cheapest tier.
General-purpose chat and content generation default to Sonnet. Claude Sonnet 5 is the site's default model tier for a reason - it handles most conversational, drafting, and moderate-reasoning tasks at near-Opus quality without Opus latency or cost.
Multi-step reasoning and hard coding tasks default to Opus. Claude Opus 4.8 is the right default when a task requires holding many constraints simultaneously, planning across several steps, or producing code that must be correct on the first pass.
The most demanding, long-horizon agentic work defaults to Fable. Claude Fable 5 is reserved for tasks that genuinely need its extended reasoning and long-horizon coherence - large autonomous migrations, deep research, or agent loops that run for many minutes unsupervised.
Never pick a tier because it "feels safer." A tier chosen out of caution rather than evidence is a cost and latency decision made without data - require an actual quality gap before escalating.

Escalation Rules (Moving Up a Tier)

Escalate when a lower tier's output fails review on a representative sample. Run 20-50 real examples through the cheaper tier first; escalate only if the failure rate is high enough to matter for the use case.
Escalate when the task requires holding more than a handful of constraints at once. Multi-constraint reasoning - "satisfy these five business rules simultaneously" - is where lower tiers degrade first.
Escalate for autonomous, unsupervised agent loops with real-world side effects. A human reviewing every step tolerates more model error than an agent making payments or filing tickets on its own.
Escalate temporarily during a model transition, not permanently by default. If a new task type is unproven, start at a higher tier to establish a quality baseline, then de-escalate once you have evidence the cheaper tier holds up.
Escalate when the cost of a wrong answer is asymmetric. A misclassified support ticket is cheap to fix; a wrong answer in a financial or medical context is not - let the cost of failure, not just task complexity, drive the tier.

De-escalation Rules (Moving Down a Tier)

De-escalate once a task's output has been stable across enough evaluation runs. If Sonnet has matched Opus's quality on your eval set for a meaningful sample size, move the route down and keep monitoring.
De-escalate any route where output is deterministic or template-driven. Tasks with a narrow, well-specified output shape rarely need the top tier's reasoning depth, regardless of how the task reads in prose.
De-escalate synchronous, latency-sensitive paths first. A user waiting on a response feels Opus's or Fable's added latency directly - if quality holds at Sonnet or Haiku, the latency win alone justifies moving down.
De-escalate before scaling traffic, not after the bill arrives. Running a cost/quality evaluation before a feature goes to full production traffic is cheaper than reacting to a large invoice.

Latency Rules

Treat latency budget and task complexity as independent axes. A task can be complex but latency-tolerant (an overnight batch job) or simple but latency-critical (autocomplete) - decide each axis separately before picking a tier.
Route synchronous, user-facing requests away from the heaviest tier by default. Opus and Fable trade throughput for depth; only put them on a live request path when the task genuinely needs that depth and the UX can tolerate the wait.
Move latency-tolerant heavy reasoning to async or batch processing. If a task needs Opus- or Fable-level reasoning but the user doesn't need the answer synchronously, run it as a background job instead of blocking a request.

Governance Rules

Write down the tier decision for every production route, not just the exceptions. A short comment or config entry naming the model and the reason prevents the next engineer from silently changing it without knowing why.
Review tier assignments on a fixed cadence, not only when something breaks. A quarterly pass through production routes catches routes that should have been de-escalated months ago.
Never let a single engineer's local preference set the tier for a shared route. Model tier is a team-level decision with cost and reliability consequences - route it through the same review any other production config change gets.

FAQs

What's the fastest way to decide a new route's starting tier?

Match the task to its category (classification, general chat, multi-step reasoning, long-horizon agentic work).
Start at that category's default tier.
Only escalate once you have evidence - a failed sample review, not a hunch - that the default tier isn't enough.

Should latency-sensitive tasks always use Haiku?

How large a sample do I need before de-escalating a route?

Is it ever correct to run the same task through two different tiers?

Yes - a common pattern is a cheap tier doing a first pass (triage, extraction) and a more capable tier only engaged for the subset of cases the first pass flags as uncertain or high-stakes.

Why does this list treat "feeling safer" as a bad reason to escalate?

Because it's not falsifiable - a decision made from caution rather than measured evidence can't be revisited later with data, so it tends to become permanent even after it stops being justified.

When is Claude Fable 5 the right default rather than an escalation?

Does model selection interact with cost control rules?

Directly - tier choice is usually the single largest lever on per-request cost. See Cost Control Rules for how caching and batching compound with tier selection.

Who should own the quarterly tier review?

Typically whoever owns the team's Claude rules generally - see How Opinionated Rules Prevent Claude Production Incidents for why a single accountable owner matters more than the specific title.

What happens if two routes with similar tasks end up on different tiers?

That's a signal decision drift has crept in - revisit both against the same evaluation criteria and reconcile them, rather than assuming the divergence was intentional.

Should tier decisions be hardcoded or configurable?

Configurable is usually safer - a config value or feature flag lets a tier change be reviewed and rolled back without a code deploy, which matters when a new model ships and the right default shifts.

Is a higher tier ever wrong even when the team can afford it?

How does this list relate to the deeper model-family content elsewhere on the site?

This page is the condensed rule form; the token-economics and claude-model-family sections cover the underlying cost, latency, and capability details these rules are derived from.

How Opinionated Rules Prevent Claude Production Incidents - why writing these rules down matters more than any single tier choice.
The Core Claude Rules: A Quick-Reference List - the condensed version of these rules alongside every other category.
Cost Control Rules: Caching, Batching, and Token Budget Discipline - how caching and batching compound with the tier choices made here.
Claude Rules Best Practices - every rule in this section restated as one checklist.

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 anthropic Python 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.

Model Selection Rules: When to Use Opus, Sonnet, or Haiku

Search Documentation

Model Selection Rules: When to Use Opus, Sonnet, or Haiku