Fable, Opus, Sonnet, Haiku: Anthropic’s Guide Talks You Out of Its Own Top Tier

On November 9, Anthropic’s developer blog published a long playbook by Addy Osmani on which Claude model to choose, at what effort level, and for which task. On paper, it’s a buyer’s guide. Read with a calculator in hand, it’s something else entirely: a document in which the vendor concedes, with its own numbers, that the top tier and the maximum settings cost a great deal and deliver very little. I’m not the one saying it. It’s right there in their own tables.

What the guide actually recommends

The bottom line fits in a sentence: start almost everything on Opus 5.5 at medium effort, adjust the effort before you change the model, step down to Sonnet or Haiku for high-volume work, move up to Fable only for the heaviest jobs, and measure on your own workload.

Nothing revolutionary. But consider what it implies: the recommended default is not the most expensive model. Fable 5.2, the flagship, is confined to major refactors and migrations, architecture planning, orchestrating large numbers of subagents, and deep research. In other words, to a small minority of use cases.

API pricing explains why:

Fable costs exactly twice as much as Opus per token. Yet all four models share the same one-million-token context window and the same 128K maximum output. The premium buys reasoning capacity, not room. And for most tasks, the vendor itself tells you that you don’t need it.

Maximum effort, or shrinkflation in reverse

The most revealing passage concerns effort levels. On SWE-bench Pro, with Opus 5.5:

• dropping from high to medium costs about 2.5 points, for roughly 70% of the price;
• dropping to low costs about 8 points, for a third of the price;
• going from high to xhigh gains about 1.4 points, for 2.5 times the price.

Read that last line again. Two and a half times the bill for a gain that fits inside a benchmark’s margin of error. The guide says as much in its own way: beyond high, an extra notch of effort can cost as much as a larger model, and effort adds no knowledge or skill the model doesn’t already have.

In The Claude Fable 5 Illusion, I described shrinkflation applied to subscription plans: you’re sold 20x and handed 6.7x. This is the opposite move, and just as profitable for the seller. Dials that go all the way to max exist to be turned up. The marketing talks about power; the table talks about diminishing returns.

Advisor mode: a product whose own manual says it doesn’t pay off

Advisor mode, currently in beta, pairs a fast, inexpensive executor with a more powerful advisor that it can consult mid-task. The idea is appealing: pay for most tokens at the small model’s rate, and call on the big one only when it actually helps.

Except that the platform’s cost guide, cited in the article, is remarkably cautious: none of the four pairings in its own table clearly beats the executor running alone. The example given is brutal: Opus 5.5 at high, backed by a Fable advisor, gains 1.7 points for about 2.1 times the cost. By the article’s own admission, that margin is within the noise between two runs.

The candor deserves credit. But the conclusion has to be drawn too: a feature whose official documentation struggles to prove its economic value is, first and foremost, a feature that consumes.

Delegation only pays when it replaces

The guide’s only clearly favorable result concerns delegation. On an internal bug-finding benchmark covering roughly 22 million tokens of code, an Opus 5.5 orchestrating up to 25 Sonnet 5.5 workers costs about a third less than Opus on its own, for a comparable score.

That’s interesting, and it sharpens what I wrote about dynamic workflows: multiplying subagents is not a saving in itself. The savings come from what you take away from the big model and hand to the small ones. If orchestration is added on top of the work instead of replacing it, the meter simply runs faster.

The rule the guide offers is sound: give the small models the work where mistakes show up immediately (file search, log reading, running tests), and keep code changes and judgment calls on the main model. In practice, in Claude Code, that means setting model: haiku in a subagent’s definition, or using the CLAUDE_CODE_SUBAGENT_MODEL variable. The built-in Explore subagent, however, runs on the session’s model by default: it’s up to you to redefine it if you’d rather not pay Opus rates to run a grep.

The guide also admits that small models handle long agentic loops poorly. So Haiku is no silver bullet: it excels at what can be checked, and struggles with what has to be chained.

The cache, or the short leash

One technical detail deserves attention: the cache belongs to the model that wrote it. Switching models mid-conversation means paying for a full cache write all over again, unless you compact or summarize first.

Technically, that makes sense. Economically, it’s one more source of friction for anyone who wants to move freely between models. In my guide to prompt caching, I showed that caching can cut a bill by a factor of ten. The flip side is that the more your architecture relies on the cache, the more expensive it becomes to leave the track you’re on. Add the lockdown of subscription tokens I described in Why I’m Considering Canceling My Claude Subscription, and the gilded cage gains another bar.

Another telling detail: the haiku alias points to Haiku 5.5 on the Anthropic API, but still to Haiku 4.5 on Bedrock, Google Cloud, and Microsoft Foundry. Depending on which pipe you go through, the same name doesn’t refer to the same model. For anyone trying to compare costs, that’s a silent source of error.

The number everyone should frame

In a research benchmark covering twenty problems, two of them accounted for 43% of total spending.

That may well be the most useful sentence in the entire article. The cost of AI isn’t linear: it concentrates on a handful of hard tasks where the model goes in circles, retries, and explores. Reasoning in terms of average cost per request means discovering the real bill at the end of the month. That’s exactly what I described in The Mirage of Unlimited AI: AI is not software with near-zero marginal cost, it’s an energy service, and its cost distribution has fat tails.

Measure before you pay: the protocol worth stealing

If the guide has one lasting merit, it’s its measurement protocol, which deserves to be adopted as is:

1. Build a sample of real tasks, each with a verifiable success criterion: a passing test, a closed ticket, a correct result.
2. Run each model at two or three effort levels, each in its own session so the cache doesn’t skew the results.
3. Record the actual cost of each completed task from the usage field in the responses.
4. Plot score against spend, and adopt a multi-model setup only if it beats every point achieved by a single model.
5. Run the winner in parallel on a slice of real traffic before switching over.

Step 4 is the most important, and the most often ignored. A sophisticated architecture that can’t beat a single, well-tuned model isn’t engineering: it’s decoration billed by the token. Even Anthropic’s own opusplan alias (Opus to plan, Sonnet to execute) should, according to the article itself, be measured before being adopted as the default.

For a quick test in Claude Code: run the same task on two models using /model and compare what /usage reports. Ten minutes, and you’ll know whether your subscription is burning tokens for nothing.

The takeaway

This guide is a vendor document, with in-house benchmarks that should be taken for what they are. But it has a rare virtue: to anyone who knows how to read it, it says that the value isn’t at the top of the lineup. It lies in tuning, in well-designed delegation, and in measurement.

That’s consistent with what I’ve been observing for months, and what I wrote in Good Enough, Fifty Times Cheaper: the question is no longer which model is best, but which one is enough. Anthropic has just acknowledged it for its own lineup. What remains is to draw the conclusion the vendor won’t draw for you: every notch above what you need is margin handed to the seller, and, as I pointed out in my piece on AI safety, the real variable in this entire industry is still the price of a token.

The best setting isn’t max. It’s the one you’ve measured.