# Opus 5.5 vs Fable 5.1: what you get for 60% less per token
On 22 September 2026 Anthropic released Claude Opus 5.5 with a sentence that is going to end up in a lot of budget meetings: Opus 5.5 "performs at the level of Claude Fable 5.1 on most work and costs 40% less to run than Opus 5". Per token it is $4 for input and $20 for output. Fable 5.1, the most capable model Anthropic sells widely, is $10 and $50. That is 60% less per token for, on most work, comparable results.
A month ago we wrote about [Fable 5.1 vs Fable 5](/en/blog/claude-fable-5-1-vs-fable-5) and ended by saying that Opus 5 at high effort covered a large part of what Fable does. With Opus 5.5 that argument gets stronger, but "most work" is not "all work", the 40% has a footnote, and the migration from Opus 5 has four breaking changes. This article goes through all three. The prices and API behaviour come from Anthropic's official documentation. The cost scenarios are ours, with the assumptions written out.
## The three models, in one table
| | Opus 5.5 | Fable 5.1 | Opus 5 |
|---|---|---|---|
| Context / max output | 1M / 128K | 1M / 128K | 1M / 128K |
| Input / output ($ per MTok) | **4 / 20** | 10 / 50 | 5 / 25 |
| Cache read ($ per MTok) | **0.20** | 0.25 | 0.50 |
| Cache write, 5 min ($ per MTok) | 5.00 | 12.50 | 6.25 |
| Batch ($ per MTok) | 2 / 10 | 5 / 25 | 2.50 / 12.50 |
| Thinking | always on | always on | on by default, can be turned off up to `high` |
| Default effort | **medium** | high | high |
| Forced `tool_choice` (`any` / `tool`) | 400 | 400 | allowed |
| Fast mode | yes, 8 / 40 | no | yes, 10 / 50 |
| Data retention | no extra requirement listed | 30 days required, no ZDR without approval | ZDR available |
| Tokenizer | same across all three | | |
Two rows are easy to miss. First, the tokenizer is the same on all three models, so the same prompt costs the same number of tokens everywhere and the comparison really is about price and behaviour. Second, Opus 5.5 in fast mode, at $8 / $40, is still cheaper per token than standard Fable 5.1. If what hurts on a route is latency, not quality, that's now a real option.
## Where the "40% cheaper" comes from
Per token, Opus 5.5 is 20% cheaper than Opus 5: $4 against $5 and $20 against $25. The cache read price dropped more, from $0.50 to $0.20. So where does 40% come from?
We priced a typical agentic coding session: 40 turns, each turn reading about 60K tokens of history from the cache, writing 3K new tokens to the cache and producing 2.5K output tokens including thinking. With the same number of tokens on every model, the session costs $3.08 on Opus 5.5, $4.45 on Opus 5 and $7.10 on Fable 5.1.
With identical token counts, Opus 5.5 comes out 31% cheaper than Opus 5, not 40%. The rest has to come from Opus 5.5 using fewer tokens for the same task, and a large part of that is a setting: **the default effort on Opus 5.5 is `medium`, one level below Opus 5's `high`**. If you change the model ID and nothing else, you're running at lower effort, so with less thinking and fewer output tokens. Sometimes that's exactly right. Sometimes it's a quiet quality drop on hard routes that you'll only notice weeks later. The documentation is explicit: set effort yourself, and redo the effort sweep on your own evals.
The second thing the chart shows is that output is the largest cost on every model, and the gap with Fable 5.1 is widest exactly there: $20 against $50 per million. In this profile, Fable 5.1 only comes out cheaper if Opus 5.5 needs about 2.3 times as many tokens to finish the same task. That happens on the hardest tasks, where the weaker model goes in circles, retries and still fails. On ordinary work it doesn't.
## Breaking changes if you're on Opus 5
Opus 5.5 keeps Opus 5's context, output limit, tokenizer and feature set. Four things change, and three of them return errors:
1. **Thinking can't be turned off.** `thinking: {type: "disabled"}` and `budget_tokens` both return a 400 at every effort level. Effort is the only control. If you had a route on Opus 5 with thinking off for latency, lower the effort to `low` instead.
2. **Forced tool use returns a 400.** `tool_choice` with `any` or a named tool is rejected, on `count_tokens` and Batches too. Use `auto`, say in the prompt which tool to call, and add `strict: true` on the tool if you need schema-valid arguments. If the forced call only existed to get JSON back, use structured outputs.
3. **Thinking blocks are tied to the model and the conversation.** Editing earlier turns invalidates the thinking blocks after them, and accounts created on or after 31 August 2026 get a 400 on edited history. The harness has to be append-only. If yours trims, rewrites or reorders history, that's the real migration work.
4. **Computer use goes through `computer_toolset_20260801`** on the Claude API and Google Cloud. The older `computer_20251124` returns a 400 there.
There are also changes that don't fail requests. Text the model writes between tool calls now comes back as progress-update `thinking` blocks, empty unless you set `display: "updates"`. And the safety classifiers are broader: `bio` joins `cyber` and `reasoning_extraction`. We recommend turning on server-side fallbacks so that a refusal on a legitimate request is retried on another model instead of stopping.
```typescript
const response = await client.beta.messages.create({
model: "claude-opus-5-5",
max_tokens: 64000,
output_config: { effort: "high" }, // set it; the default is medium
betas: ["server-side-fallback-2026-07-01"],
fallbacks: "default", // routes by refusal category
messages,
tools,
});
```
## When Fable 5.1 is still worth it
"Most work" leaves room. In the Fable article we listed the areas where Anthropic says the top model gains the most: long agentic coding sessions over hours, documents and spreadsheets built from scratch, multi-step research, vision on dense charts and scanned PDFs, retrieval deep into the 1M window, and computer use with recovery from failed steps. That's where we'd keep Fable 5.1 in the test set, and where we'd expect the 2.3× break-even above to be crossed.
There are also reasons not to use Fable 5.1 that have nothing to do with capability. **Fable 5.1 requires 30-day data retention** and isn't available under zero data retention unless Anthropic expressly approves it. For a client in banking or healthcare with a contractual ZDR requirement, that ends the discussion before anyone looks at a benchmark. It has no fast mode either, and neither model is on the Priority Tier.
One detail makes the two models work well together. Opus 5.5's thinking blocks can be read by Fable 5.1 on the Claude API. So you can run a conversation on Opus 5.5 and escalate the hard turn to Fable 5.1 without the stronger model losing the reasoning that came before. Going the other way, from Opus 5.5 down to Opus 5, the earlier thinking is dropped. If you build an escalation path, build it upwards.
## How we'd decide, route by route
The point of the flow is that the model is a per-route decision. Most companies we work with have a handful of AI routes: one that writes code, one that answers customers, one that extracts data, one that summarises. They don't all need the same model. The extraction route probably belongs on [Haiku 5.5](/en/blog/claude-haiku-5-5-in-production), the customer route on Sonnet or Opus at low effort, and maybe one route, the one that does long autonomous work, earns Fable 5.1.
## Our recommendation
Make Opus 5.5 the default for new work and for everything currently on Opus 5. The migration is a day of work if your harness is already append-only and doesn't force tool calls, and more if it isn't. Set effort explicitly on every route, because the new default of `medium` will otherwise make the decision for you. Keep Fable 5.1 for the routes where your own evals show that Opus 5.5 at `xhigh` still isn't enough. On the price side, that's the bar it has to clear: 2.5 times the cost per token.
If you're on a Claude Max subscription rather than the API, the arithmetic is different, and we covered it in [Claude Max vs API](/en/blog/claude-max-vs-api-what-200-dollars-really-buys). If you want help measuring which of your routes needs which model, that's exactly the kind of work [we do for clients](/contact).