Claude models compared: Fable 5.1, Opus 5, Sonnet 5, Haiku 4.5

I run demand gen at Docket, and my team automates a lot of GTM work with Claude: lead research, list enrichment, content drafts, classification, internal tooling. At that volume the model you pick is not a detail. It is a line item. And the most expensive mistake I see, over and over, is teams defaulting to the biggest model for everything because it feels safe.

I call it the model tax: paying for reasoning depth before checking whether the job needs it. A lead-routing label and a territory plan deserve different tests. The cheaper model earns its place by passing those tests, and the expensive one earns its place by fixing failures that matter.

The previous version of this guide still carried a June availability claim after the lineup had changed. That is an editorial mistake worth making visible. I have checked the model guidance against Anthropic's documentation on September 22, 2026. Before changing a production model, repeat that check and rerun your own examples. A polished comparison table can age like milk (including ours).

The lineup at a glance

The main lineup below uses standard direct API prices checked on September 22, 2026. Treat model capability, access through your chosen platform and app subscription limits as separate checks.

Read the price columns as a pair, not a single number. Output tokens cost five times what input tokens cost on every model. That ratio matters more than the headline price, and I will come back to it in the cost math section.

• Fable 5.1: claude-fable-5-1. $10 input / $50 output per million tokens; 1M context, 128K maximum output.
• Opus 5: claude-opus-5. $5 / $25; 1M context, 128K maximum output.
• Sonnet 5: claude-sonnet-5. $2 / $10; 1M context, 128K maximum output.
• Haiku 4.5: claude-haiku-4-5-20251001. $1 / $5; 200K context, 64K maximum output.

Claude Fable 5.1: evaluate it on the hard cases

Fable 5.1 is available, with adaptive thinking always enabled. The old withdrawal warning in this guide should not drive your buying decision. I would put Fable on the shortlist for jobs where the model has to carry a difficult argument across many steps: reconciling a forecast, checking a territory plan, or finding a contradiction across several account histories.

The useful comparison is a failed task with a known answer. Take a forecast narrative where the CRM says one thing and the latest call notes say another. Give Opus and Fable the same dated evidence and require each disputed claim to point back to its source. Judge whether the reasoning resolved the conflict. Eloquence is a terrible substitute for that check.

Migration has practical edges. Fable 5.1 does not support forcing a tool through tool_choice any or a named tool; use supported selection modes and validate tool arguments. Its retention terms also need a separate review for workflows with a Zero Data Retention requirement. A model upgrade changes more than the name in a request.

Claude Opus 5: a strong baseline for complex work

Anthropic recommends Opus 5 as the starting point for most workloads. It costs $5 input and $25 output per million tokens. My reason to evaluate it for GTM is the cost of a mistaken decision: a plausible but unsupported account narrative can waste much more than a few extra tokens.

The agentic coding angle is the clearest case. When Claude is driving a tool loop, reading files, running commands, and editing code across many steps, the quality of each decision compounds. A model that picks the right next action saves you the tokens and time of recovering from a wrong one. That is where Opus 5 pays for itself: long-horizon work where coherence across steps matters more than the cost of a single call.

Opus 5 supports adaptive thinking and effort levels through max. I would compare a moderate-effort run and a higher-effort run on the same account packet before deciding that every request needs the most expensive settings. Keep the evidence, prompt and output format fixed so the comparison tells you something.

Claude Sonnet 5: my cost-conscious GTM starting point

Sonnet 5 is the first model I would evaluate for repeatable briefs, drafts and extraction where spend matters. Its standard rate is $2 input and $10 output per million tokens. That is a budget recommendation to test, not a claim that I have benchmarked every GTM workflow or that Anthropic recommends the same default.

Start with a packet containing a dated CRM export, the current ICP and a few call notes. Ask for a short account brief with citations and a separate list of unknowns. Score unsupported claims, missing facts and editing time. If Sonnet clears that bar, test a cheaper option on the simpler steps. If it fails, inspect the missing evidence before assuming more model will fix it.

When you do hit a ceiling, the answer is often not a bigger model. Raise the effort setting, add better examples to the prompt, or split the task. I move to Opus only after Sonnet has demonstrably failed on a representative sample, not on a hunch that the task feels important.

Sonnet 5 changes the tokenizer as well as the price. Anthropic reports roughly 30 percent more tokens for the same text compared with the previous tokenizer, so replay real requests instead of applying the new rate to an old usage report. Adaptive thinking replaces manual thinking budgets; migration also requires checking unsupported sampling controls. Treat the first bill as a measurement, not a surprise.

Claude Haiku 4.5: scale and low latency

Haiku 4.5 is the fastest and cheapest model: 200K context, 64K output, $1 input / $5 output. It is the only model with a smaller context window, but 200K is still enormous for the jobs Haiku is right for.

Haiku earns its place on volume and latency. Its standard input and output rates are half Sonnet 5's and one-fifth Opus 5's. That makes it worth testing for routing, tagging and short structured extraction. The word testing does a lot of work here: the price table cannot tell you whether it handles your ambiguous leads correctly.

The trap with Haiku is using it for work that needs more reasoning than it has. It will give you an answer either way. For nuanced judgment, multi-step logic, or anything where a subtle mistake is costly, Haiku is false economy. The fix is to test it on a sample and look at the error rate, not to assume cheap means good enough.

How to choose: a decision framework

The framework I actually use runs top to bottom: stop at the first model that clears the bar.

Start with three questions about the task: How hard is the reasoning? How much does a wrong answer cost? Is a human waiting on it? Those three answers point you at a model far more reliably than gut feel.

• Simple, high-volume, or latency-sensitive (classification, tagging, scoring, extraction at scale): use Haiku 4.5. Test the error rate on a sample first.
• Repeatable GTM briefs and drafts: evaluate Sonnet 5 first when cost matters, then compare quality and review time with Opus 5.
• Complex reasoning and long agent runs: start with Opus 5, then evaluate Fable 5.1 on failures that remain at higher effort.
• Default to the cheapest model that passes your quality bar on a representative sample, not the smartest model you can afford.

The cost math, worked through

Let me put numbers on why this matters. Say you classify 100,000 support tickets a month. Each ticket is about 500 input tokens and the model returns about 20 output tokens (a short label). That is 50M input tokens and 2M output tokens monthly.

For that illustrative fixed-token workload, Haiku costs $60, Sonnet 5 costs $120, Opus 5 costs $300 and Fable 5.1 costs $600. These are arithmetic examples, not measured runs or a claim of equal quality. They exclude additional thinking tokens, retries, tools, caching and batch discounts. Different tokenizers can also change the number of tokens for the same ticket text.

Now take an illustrative 10,000 drafts with 2,000 input and 4,000 billed output tokens each: 20M input and 40M output. Sonnet 5 would cost $40 plus $400, or $440 before other charges and discounts. Output dominates. Ask for a compact account brief when that is the deliverable; a ten-page essay you immediately shorten is paid waste.

Caching and batches are separate levers. Cache pricing depends on the model and cache duration; Fable 5.1 has a different read discount from the other models. Batch processing offers a discount for asynchronous work. Model the full request, including cache writes and any tool charges, before promising a percentage saving to finance.

How to actually select a model

In the apps at claude.ai, you pick a model from a menu. The Free tier has the most limited access; paid tiers open up the frontier models. In Claude Code, you switch with the /model command. In the API you set the model field on the request, and the controls below ride alongside it.

Adaptive thinking and effort change how a model spends its reasoning budget. Support varies: Haiku 4.5 does not expose the effort control, and Fable 5.1 keeps adaptive thinking on. For a migration, check the destination model's documentation rather than carrying every old request parameter across. Lower effort is an experiment to score, not a promise of identical answers.

The request below is an illustrative API example, not a recorded production run. It uses a concrete, fictional lead and keeps the key in an environment variable. Inspect the returned content blocks and usage before estimating cost; thinking can produce blocks beyond the visible answer.

Common mistakes that cost you money

The expensive mistakes happen before the invoice: promoting a model without an eval, keeping an obsolete API parameter, or comparing token rates while ignoring retries. I would audit the request and the accepted result together.

Run the same held-out cases after a model change. Keep yesterday's working configuration available until the new one clears your quality bar. Which step in your GTM workflow actually needs more reasoning, and which one simply needs better source material?

• Buying the biggest model for every step before defining an acceptance test.
• Never running an eval. Picking a model by feel instead of by measured error rate on real inputs means you overpay or under-deliver indefinitely.
• Ignoring the effort setting. Teams upgrade the whole model when raising effort on a cheaper one would have closed the gap for far less.
• Assuming every model has the same cache discount, or forgetting cache writes have a price.
• Running latency-tolerant jobs at full price. Anything that does not need a fast answer should go through the Batch API at about half cost.
• Optimizing input when output drives the bill. If you generate a lot of text, a tighter prompt or a more concise model beats squeezing input tokens.

How to set it up

Frequently asked questions

Sources & further reading

• Current model comparison
• Fable 5.1 capabilities and constraints
• Opus 5 capabilities
• Sonnet 5 capabilities and migration
• API release notes
• Pricing

Claude ships fast. This page was last reviewed Sep 22, 2026; verify time-sensitive details against the official docs above before relying on them.