Claude API Models Compared: Choose Fable 5, Opus 5, Sonnet 5, or Haiku 4.5

Start with Sonnet 5—unless one constraint clearly points elsewhere

For most new Claude API applications, start with Claude Sonnet 5. Anthropic describes it as the fast, balanced model in its current model overview, with a 1-million-token context window. Treat that as a candidate-selection shortcut, not an independent benchmark or a universal winner.

Move down to Claude Haiku 4.5 when latency, volume, and unit cost dominate—and its 200k-token context window and 64k maximum output are sufficient. Move up to Claude Opus 5 when long-horizon agents or difficult coding tasks fail often enough on Sonnet that retries and human repair cost more than the higher rate. Test Claude Fable 5 only for the hardest work, where a measurable quality gain can justify its price and operational constraints.

All model facts and first-party Anthropic API prices on this page were checked on August 10, 2026. Anthropic's capability and relative-latency descriptions are vendor positioning, not results from an independent benchmark and not a latency service-level agreement.

The practical split is:

• Latency plus volume: begin with Haiku 4.5 and verify that it clears your accuracy threshold.
• Balanced production work: begin with Sonnet 5, then compare one adjacent model if quality or speed misses its target.
• Hard, long-horizon agents: try Opus 5 when fewer failed steps and less repair may repay the rate difference.
• Highest-capability work with extra controls: evaluate Fable 5 only after checking retention, zero data retention, refusal handling, and full cost.

The rest of this guide turns that split into a model ID you can copy, a bill you can estimate, and a migration you can make without assuming that an ID change is the whole job.

Know what the ID and the token limits actually control

A display name such as “Claude Sonnet 5” is for people. The model field in an API request needs a model ID. Every Claude model ID is a pinned snapshot: it identifies fixed model weights and behavior. Anthropic explicitly says that the dateless IDs introduced with the 4.6 generation are not evergreen aliases that silently advance to future models. See Model IDs and versioning before building update logic around the spelling of an ID.

These are the current IDs to copy:

text
Claude Fable 5:   claude-fable-5
Claude Opus 5:    claude-opus-5
Claude Sonnet 5:  claude-sonnet-5
Claude Haiku 4.5: claude-haiku-4-5-20251001
Haiku short alias: claude-haiku-4-5

For a production configuration, prefer the exact ID that your lifecycle policy expects. Do not assume that a dateless 5-series ID means “latest forever.”

Three other terms determine whether a model fits:

• Input tokens represent the content sent to the API, including applicable prompt and context. Output tokens are generated by the model. They are billed at separate rates.
• MTok means one million API tokens. A price of $3 per MTok means 100,000 billed input tokens cost $0.30 before modifiers.
• The context window limits the total working context a request can use; max output caps the synchronous response. A 1M context window is not unlimited, and a larger window does not guarantee a better answer.

Those concepts matter more than a label such as “budget” or “premium”: they determine whether the request fits and how its actual token shape affects the bill.

Compare the current model contract, not a permanent ranking

The following baseline comes from Anthropic's Models overview. Standard rates come from Anthropic's first-party Claude API pricing. Prices are per million input/output tokens and exclude prompt caching, Batch, tools, data residency, taxes, retries, and partner platforms.

“

Temporary Sonnet 5 rate: Anthropic's pricing page lists an introductory rate of $2 input / $10 output per MTok through August 31, 2026. The standard $3 / $15 rate begins September 1, 2026. Do not use the introductory rate as a permanent forecast.

The relative latency column is useful for choosing candidates, but it does not predict your time to first token or end-to-end request duration. Prompt length, output length, thinking, tools, load, network path, and retries all affect observed latency. Measure it in your own request path.

Understand thinking controls before you compare or migrate

Adaptive thinking lets the model decide when and how much internal reasoning to use under the supported controls. Fable 5, Opus 5, and Sonnet 5 use adaptive thinking. Haiku 4.5 instead supports manual extended thinking. Anthropic's model overview lists those differences and notes that Opus 5 and Sonnet 5 default to high effort on the Claude API and Claude Code.

This is part of the API contract, not an invisible account setting. A request built around manual thinking parameters for Haiku or an older model should not be copied unchanged to Sonnet 5. Thinking can also change output behavior, token use, and latency, so record the model ID and supported effort setting with every evaluation result.

Before switching models, inventory:

• model ID and API surface;
• thinking mode and effort;
• temperature, top_p, and top_k values;
• context and expected maximum output;
• prompt-cache behavior;
• tools and permissions;
• retry and refusal handling;
• retention and ZDR requirements.

That inventory identifies fields that can invalidate a request or change production risk before you interpret any quality result.

Let four workload gates narrow the choice

Haiku 4.5 for short, high-volume decisions

Consider a classification or routing service that reads a support message and returns a short label plus a confidence explanation. Haiku 4.5 has the lowest standard token rates in this group and Anthropic labels it the fastest. Its 200k context and 64k max output are usually more than this request shape requires.

But low unit price does not decide the deployment. Define the acceptable classification error rate, especially for rare or costly classes, then compare accepted results. If errors trigger manual review or misroute expensive work, a higher-rate model may have a lower cost per accepted output.

Haiku 4.5 is also the outlier in thinking controls: it supports manual extended thinking, while the three 5-series models use adaptive thinking. That affects how requests migrate and how token use should be compared.

Sonnet 5 for balanced production work

Sonnet 5 is the sensible first candidate for a repository-scale coding agent, a tool-using assistant, or a general production workflow that benefits from fast relative latency and a 1M context window. It also offers 128k maximum synchronous output.

For example, give the same repository task, tool permissions, and token budget to Sonnet 5 and Opus 5. Start with Sonnet. Move to Opus only if it reduces failed tool steps, retries, or human repair enough to outweigh the higher token rate. Context capacity alone is not evidence that the agent will finish more reliably.

Be careful when carrying forward request controls. Sonnet 5 uses adaptive thinking, enabled by default, and its effort defaults to high on the Claude API and Claude Code. A Sonnet 4.6 integration can use Sonnet 5 as a model-ID upgrade, but Sonnet 5 rejects manual extended thinking and non-default temperature, top_p, or top_k. Anthropic's What's new in Sonnet 5 documents those compatibility conditions. Treat “drop-in” as scoped to a clean Sonnet 4.6 request, not as a promise for every older integration.

Opus 5 for failures that cost more than tokens

Opus 5 is the candidate for difficult agentic coding, deep reasoning, and long-horizon enterprise workflows. Anthropic positions it for those tasks and lists a 1M context window, 128k max synchronous output, and thinking on by default. On the Claude API and Claude Code, effort defaults to high.

The right question is not whether Opus is “smarter.” Ask whether it changes the economics of your workflow. If Sonnet frequently loses state in a long tool trace, chooses an unrecoverable action, or produces work that needs extensive repair, Opus may be cheaper per accepted outcome even at $5 input and $25 output per MTok. If both clear the quality bar with similar repair time, Sonnet's lower rate and faster relative latency make Opus hard to justify.

Fable 5 when capability gain can clear operational gates

Fable 5 is Anthropic's most capable widely released model, but adopting it is not just a price decision. Anthropic's Fable 5 introduction and Claude migration guide document a standard rate of $10 input and $50 output per MTok—double the Opus 4.8 rates during that migration—a 30-day data-retention requirement, possible HTTP 400 responses for an incompatible zero data retention (ZDR) configuration, and safety-classifier refusals that the integration must handle. Enterprise retention terms may need confirmation with your account team.

A high-stakes research or enterprise workflow should test more than answer quality. Include refusal handling, the retention policy, incompatible ZDR behavior, and the complete token bill in the acceptance gate. Choose Fable only when the hardest representative work shows enough measurable benefit to cover both the higher rate and the operational changes.

Claude Mythos 5 is outside this four-model self-serve decision. Anthropic limits it to approved Project Glasswing customers, so it is not a normal API option to place beside Fable, Opus, Sonnet, and Haiku.

Calculate a fixed request before forecasting monthly spend

Use counted tokens, not an assumption that identical source text will always tokenize identically across models. For a simple arithmetic example, suppose an evaluation run bills exactly 100,000 input tokens and 5,000 output tokens.

At standard rates:

This is a fixed-token comparison, not a prediction that the same prompt will produce the same token counts or quality on all four models. It also excludes caching, Batch, tools, data residency, taxes, and retries.

Anthropic's pricing documentation lists a 50% discount on both input and output for eligible Batch API work. A prompt-cache hit costs 10% of standard input, while cache writes use higher multipliers. Those features can lower total cost, but only when the workload is eligible and the cache is implemented effectively; generated output, tools, misses, and retries still count.

Posted per-token rates are not enough for a cross-generation forecast. Anthropic says Claude 4.7 and later use a newer tokenizer that produces approximately 30% more tokens for the same text than the earlier tokenizer, with the actual change depending on the content. That is not a fixed 30% surcharge. Remeasure token counts with representative inputs, then apply the current rate and your observed output length.

For monthly planning, track at least:

text
token cost
+ cache write and miss effects
+ tool-specific charges
+ retries and failed runs
+ human repair cost
= cost of accepted work

The least expensive model on a price table can be the expensive choice if it needs substantially more attempts or intervention.

Use migration gates instead of changing only the model ID

Sonnet 4.6 to Sonnet 5

For the specific Sonnet 4.6 path, Anthropic's Sonnet 5 model notes say to remove manual extended thinking and non-default temperature, top_p, or top_k. Then change the ID to claude-sonnet-5, verify adaptive thinking and effort behavior, and remeasure tokens under the newer tokenizer. Older starting models may require additional changes.

Opus 4.8 to Fable 5

Do not approve this migration from a capability label alone. Model the doubled token rates, confirm 30-day retention is acceptable, check ZDR compatibility, and implement both HTTP 400 and safety-classifier refusal handling. Follow the current migration guide and confirm enterprise-specific terms when applicable.

Any older production ID

Keep a model-ID inventory with an owner and a review date. Anthropic's model deprecations page listed the four main models in this guide as active on Anthropic-operated API surfaces when checked August 10, 2026. It also listed Opus 4.1 as retired on August 5, 2026, and Opus 4 and Sonnet 4 as retired on June 15, 2026.

Those dates do not establish lifecycle status on Amazon Bedrock, Google Cloud, Microsoft Foundry, or another partner. This guide is deliberately limited to Anthropic-operated API surfaces.

Run a small evaluation that measures accepted output

No official spec table can tell you which model will clear your private workload's quality bar. Use a small, representative prompt set that covers routine cases, difficult cases, and failures that are expensive in production. Define explicit pass/fail criteria before looking at the results.

Run the lowest plausible model and one adjacent candidate with:

• the same prompts and input data;
• the same tool permissions;
• the same supported thinking or effort policy;
• the same maximum token budget;
• the same retry and timeout rules;
• the same human review standard.

For every run, record p50 and p95 latency—the median and 95th-percentile observed request latency—plus input tokens, output tokens, cache usage, retries, tool calls, human repair time, and whether the output was accepted. Also log refusals and invalid requests as outcomes; hiding them understates production cost.

Then calculate:

text
accepted-output rate = accepted runs / total attempted runs

accepted-output cost =
  (API charges + retry charges + valued repair time) / accepted runs

This is an evaluation plan, not a claim that this article independently benchmarked the models. Its decision rule is straightforward: use the least expensive and fastest model that clears the workload's quality and risk thresholds. Upgrade only when the measured reduction in failures or repair cost pays for the difference.

For the classification service, that may leave Haiku 4.5 as the winner if it clears the rare-class threshold. For the repository agent, Sonnet 5 is the starting point and Opus 5 earns its place only by reducing broken steps or repair. For the high-stakes workflow, Fable 5 must clear both the output test and the retention, ZDR, refusal, and total-cost gates.

Turn the choice into a reversible rollout

Use this sequence to move from reading to production:

1. Choose the lowest plausible model based on latency, volume, task difficulty, context, and output needs.
2. Copy its exact pinned model ID into a reversible configuration, not scattered application code.
3. Run the same representative prompt set against that model and one adjacent candidate.
4. Compare accepted-output cost, p50/p95 latency, token counts, retries, and repair effort—not raw token price alone.
5. Verify request parameters, thinking behavior, retention requirements, refusal handling, and current lifecycle status.
6. Roll out gradually with the ability to switch back without a code release.

If you are upgrading an existing integration, finish with Anthropic's Claude migration guide and verify the path for your actual starting model before changing production traffic.