Claude Fable vs Opus vs Sonnet vs Haiku: Pick by Failure Cost

Claude’s four current tiers are easy to arrange and easy to misuse. Haiku is the fast, economical model; Sonnet balances speed and capability; Opus targets complex agentic work; Fable is Anthropic’s highest-capability widely released model. That ordering still does not tell you which model should receive a production request.

The useful decision is narrower: which candidate clears this workload’s acceptance bar with the lowest total cost and an acceptable latency tail? For a million low-risk extraction jobs, that may be Haiku 4.5. For a routine coding agent it may be Sonnet 5. A multihour migration may justify Opus 5, while Fable 5 should usually enter only when the task remains capability-bound after the cheaper route has been tested.

This guide uses direct Claude API specifications checked on August 15, 2026. Claude subscriptions, Claude Code, Bedrock, Google Cloud, and gateways add separate availability, tooling, and billing contracts.

The names describe capability classes, not a universal queue

The Anthropic model overview currently lists four broadly available models:

Those prices are standard direct-API token rates, not monthly plan prices. They also do not include human review, retries, server-side tools, cache writes, route premiums, or the cost of a failed job.

Sonnet 5 has one source-timing trap. An older Anthropic pricing table still says its $2/$10 rate was introductory and would become $3/$15 on September 1. Anthropic updated the Sonnet 5 announcement on August 10 to make $2/$10 permanent, and the newer English model overview now matches that update. Treat the stale future price as superseded, but recheck before committing a large budget.

Give each workload three budgets before choosing a model

A shortlist becomes much easier when the team writes down three constraints first.

Failure budget. What happens when the model is wrong? A mislabeled support ticket can enter a review queue. A flawed database migration can corrupt state. Cheap-to-detect failures favor a lower-cost starting point; expensive or silent failures justify a stronger baseline and stricter review.

Latency budget. Do you need a response in a live UI, a batch by morning, or a correct result after a three-hour agent run? Average latency hides the operational problem. Record P50 and P95, plus time to the first fully accepted outcome.

Intervention budget. How many clarifications, approvals, manual edits, restarts, and context recoveries can the workflow tolerate? A model that saves tokens but requires an operator every ten minutes may be the expensive route.

These budgets prevent a common mistake: choosing Fable because it is strongest, or Haiku because it is cheapest, before defining what “good enough” means.

Where each model earns a place on the shortlist

Haiku 4.5: economical work that can fail visibly

Haiku belongs in high-volume, latency-sensitive systems with clear checks: classification, entity extraction, short summaries, routing, and bounded subagent work. Its $1/$5 rate leaves room for redundancy, and 200k context is ample for many operational requests.

Do not use the label “small” as a quality verdict. Run the actual schema, language, and edge cases. Remove Haiku when errors are hard to detect, when the prompt genuinely needs more than 200k context, or when retries erase the meter advantage.

Sonnet 5: the broad challenger for everyday production

Sonnet 5 deserves a test in coding, data analysis, content processing, visual understanding, and tool-using workflows. It offers a 1M window and 128k maximum output at $2/$10, so it can cover tasks that previously forced a jump to a more expensive class.

Its new tokenizer complicates comparisons with Sonnet 4.6: Anthropic says the same text can produce roughly 30% more tokens, depending on content. Recount real prompts instead of carrying an old spreadsheet forward.

Opus 5: a capability baseline for costly mistakes

Start with Opus when the work involves deep reasoning, large refactors, complex systems engineering, multihour autonomous coding, difficult document or vision tasks, or an expensive failure. The Opus 5 behavior guide says thinking is on by default and the full effort ladder runs from low to max.

That makes effort a routing control inside the model. A lower effort level may preserve acceptance while reducing tokens and latency; xhigh or max needs a generous max_tokens ceiling. Compare effort settings before paying for another model switch.

Fable 5: an escalation, not a prestige default

Fable is the candidate for long-running agents, advanced research, hard vision, and tasks that still miss the acceptance bar on Opus. Its direct rate is exactly twice Opus 5’s $5/$25, so a deployment should be able to name the capability gap that earns the premium.

The Fable 5 launch material also documents stricter safety classifiers. They can occasionally catch benign requests. For affected workloads, refusals and fallback behavior belong in the evaluation; a response generated by a fallback model is not a pure Fable result.

Model switching can change the request contract

Updating model= is not a complete migration. The four models differ in how reasoning is configured:

• Fable 5 has adaptive thinking always on; it cannot be disabled.
• Opus 5 and Sonnet 5 use adaptive thinking by default and expose effort controls.
• Haiku 4.5 supports optional manual extended thinking and rejects adaptive thinking.

The Anthropic migration guide shows why this matters. A Haiku request with thinking: {type: "enabled", budget_tokens: N} can return HTTP 400 after a direct move to Sonnet 5. Sonnet 5 also rejects non-default temperature, top_p, or top_k values.

Before a canary, check model ID, thinking mode, effort, sampling parameters, max_tokens, tool schemas, streaming, refusal handling, token counting, and cache behavior. Anthropic’s versioning documentation is explicit that dateless 4.6-and-later IDs are pinned snapshots, not evergreen “latest” aliases.

Run a two-candidate trial instead of a four-model tournament

Most teams do not need to test all four models on every task. Choose two adjacent candidates based on the budgets above:

• Haiku versus Sonnet for high-volume, automatically checked work;
• Sonnet versus Opus for routine agents and professional workflows;
• Opus versus Fable for the hardest long-horizon subset.

Use 10–20 representative tasks with a real acceptance condition. Feed both candidates the same input, tools, permissions, timebox, and stop rule. If one test uses Claude Code and another uses a bare Messages API call, label it as a product-configuration test; the harness is part of the result.

For every run, retain:

Then calculate:

cost per accepted task = (model cost + human cost + rework cost) / accepted tasks

A $0.02 call that passes half the time can lose to a $0.05 call that passes reliably. A Fable run can justify its meter when it removes hours of expert repair—but only if repeated samples show that effect.

Turn the result into a routing policy

The end product should be a small policy, not a permanent leaderboard. A high-volume service might start on Haiku and escalate after schema failures. A general agent might start on Sonnet, route high-risk repository changes to Opus, and reserve Fable for tasks that exceeded an Opus effort or time budget. Teams with expensive failure modes may reverse the process: establish acceptance on Opus, then test whether Sonnet can take the common path safely.

Keep a canary slice after rollout. Re-evaluate when model IDs, prices, tokenizers, product limits, or your task mix changes. Anthropic’s own model selection guide recommends testing with real prompts and data rather than trusting a generic ranking.

If your actual decision is about Claude Code versus Codex permissions, subscriptions, interfaces, or team handoff, use the workflow-level Claude Code vs Codex comparison. For API deployment, pick the two nearest candidates, run the matched trial, and promote only the route that lowers cost per accepted work without violating the failure or latency budget.