Skip to content
← All notes

Sonnet, Opus and Fable: which Claude model should you actually use?

The three tiers are a price curve, not a quality ranking, and the useful question is not which is best. It is how expensive it is when the answer is wrong.

Tools8 min read

Almost everyone picks a model the same way. They read that one is the most capable, use it for everything, and then get surprised by a bill. Or they pick the cheapest, get a run of poor answers, and conclude the whole category is overrated.

Both come from treating this as a ranking question. It is a cost question with a judgement attached, and once you see the actual numbers the decision gets much easier to make.

What the three tiers cost, and the ratio that matters

Prices below are per million tokens, from Anthropic's published pricing page and correct on 29 August 2026. Check the page rather than this post before making a budget: these move.

  • Claude Sonnet 5: 2 dollars in, 10 dollars out.
  • Claude Opus 5: 5 dollars in, 25 dollars out.
  • Claude Fable 5: 10 dollars in, 50 dollars out.

The absolute numbers matter less than the shape. Opus costs two and a half times Sonnet, Fable costs twice Opus, and Fable costs five times Sonnet, on both input and output, all the way up.

Five times is the number to hold on to. It is small enough that it should never stop you using the strongest model on something that genuinely matters, and large enough that it will hurt if you use it for everything by default.

One recent change worth knowing if you priced this earlier in the year: Sonnet 5's two-and-ten pricing was announced as introductory and scheduled to rise on 1 September 2026. Anthropic has since confirmed that increase will not happen and the introductory rate is now the standard price.

What actually changes as you move up the tiers

The unhelpful description is that the expensive ones are smarter. The useful one is that the failure mode moves.

On a straightforward task with a clear answer, the tiers converge. Summarise this, classify that, extract these fields, rewrite this paragraph. A cheaper model does those about as well, and paying five times more buys you very little.

The gap opens on work where the difficulty is not in the answer but in getting there. Long chains of reasoning where an early wrong turn is unrecoverable. Problems that need holding a lot of context at once. Agentic work that runs for many steps, where a small misjudgement compounds instead of showing up immediately.

That is the real distinction. The stronger model is not producing better sentences. It is going wrong less often on the kind of problem where going wrong is expensive.

On a task with a clear answer the tiers converge and the extra cost buys very little. The gap opens on long chains of reasoning, where an early wrong turn is unrecoverable and compounds across every step that follows.
You are not buying better sentences. You are buying fewer wrong turns where a wrong turn is expensive.

A cost trap that catches people comparing prices

Per-token prices are only comparable when the tokens are the same size, and across model generations they are not.

Anthropic notes that Claude 4.7 and later models use a newer tokenizer which produces roughly thirty percent more tokens for the same text than the one used by Sonnet 4.6 and earlier. The exact increase depends on the content.

So a per-token price cut between generations can be smaller in practice than it looks, because the same document now costs more tokens. Comparing Sonnet 5, Opus 5 and Fable 5 against each other is fair, since they share a tokenizer. Comparing any of them against an older model on price alone is not.

This is the sort of thing that turns a projected saving into an unexpected invoice, and it is invisible unless somebody tells you.

How to choose, in practice

Anthropic's own guidance is a reasonable default: the smallest model for simple tasks, the middle tier for most production work, and the top of the range for the most complex reasoning. In practice one question does most of the work.

Ask what it costs when this answer is wrong and nobody notices. If a bad output gets caught immediately by a person or a test, use the cheap model, because you are paying for a mistake that gets found. If a bad output flows into a decision, a customer, or a long chain of further steps, buy the better model, because the five times difference is trivial next to the cost of the failure.

  • Start on the middle tier for anything real, and move in whichever direction the results push you.
  • Move down when you cannot tell the difference on your actual work. Test that with your own tasks rather than assuming it.
  • Move up for long agentic runs, hard reasoning, and anything where an early mistake is not recoverable.
  • Route rather than standardise. Cheap model for the bulk classification, strong model for the twenty decisions a week that matter.

Two cheaper levers than downgrading

People reach for a smaller model when the bill arrives, and it is usually the third-best option. Two others cut cost without giving up capability.

Prompt caching charges a cache read at a tenth of the standard input price, so anything you resend on every request, a long system prompt, a document, a conversation history, is repeatedly billed at full price until you cache it.

The Batch API takes fifty percent off both input and output for work that does not need an answer immediately. Overnight jobs, bulk classification and backfills are all a straightforward halving.

Cache and batch first. A tenth on repeated input beats moving down a tier, and it costs you nothing in quality.

Two cheaper levers than downgrading: caching the content resent on every request so it is billed at a fraction of the input price, and batching work that does not need an answer immediately.
Reach for these before you reach for a weaker model.

The part that is still yours

None of this tells you which model is right for your work, because that depends on what your work punishes. The tiers give you a dial between cost and the chance of a confident mistake, and where to set it is a judgement about consequences rather than a fact about the models.

Which is the same thing this blog keeps arriving at. The tooling made producing cheap. Deciding what a wrong answer costs you is the part that did not move.

Common questions

What is the difference between Claude Sonnet, Opus and Fable?
They are three tiers of a price and capability curve. As of 29 August 2026, Sonnet 5 costs 2 dollars in and 10 out per million tokens, Opus 5 costs 5 and 25, and Fable 5 costs 10 and 50. Going up the range does not mainly buy better writing, it buys a lower chance of going wrong on long reasoning, large context and multi-step agentic work.
Which Claude model should I use for most tasks?
The middle of the range for most production work, moving down when you genuinely cannot tell the difference on your own tasks, and up for hard reasoning or long agentic runs. The deciding question is what a wrong answer costs: if a mistake is caught immediately, use the cheap model, and if it flows into a decision or a long chain of steps, pay for the better one.
Is the most expensive Claude model always better?
No. On tasks with a clear answer the tiers converge and the extra cost buys very little. The gap opens where an early mistake is unrecoverable or compounds across many steps, which is a property of your task rather than of the model.
How can I reduce Claude API costs without using a weaker model?
Prompt caching and the Batch API, in that order. A cache read is billed at a tenth of the standard input price, so any content you resend on every request is worth caching. The Batch API takes fifty percent off input and output for work that does not need an immediate answer.
Why did my costs go up after switching to a newer Claude model?
Probably the tokenizer. Claude 4.7 and later use a newer one that produces roughly thirty percent more tokens for the same text than Sonnet 4.6 and earlier, so an apparent per-token price cut can be smaller in practice. Per-token prices are only comparable within the same tokenizer generation.

PDP Quest exists because of the problem underneath all of these: when output stops indicating capability, you need another way to know who can actually do the work.

See how verification works →