# Fable 5.1 vs Fable 5: same price, different bill Anthropic released Claude Fable 5.1 and the first thing you see on the pricing page is that nothing has changed: $10 per million input tokens, $50 per million output tokens, exactly like Fable 5. The second thing, which you only see if you read the migration guide all the way through, is that everything has changed in how you get to that bill. What you're buying with 5.1 isn't "a better model at the same price" but a model that behaves differently at every effort level, reads the cache four times cheaper, and forces a particular way of building the harness around it. We wrote this article for those who have to decide in the coming weeks whether to migrate. We put Opus 5 in the comparison too, because without it the discussion is incomplete: Opus 5 costs half, works under zero data retention and, at high effort, solves a large part of what Fable solves. All the figures below come from the official API documentation from August 2026, not from marketing benchmarks. Where we don't have figures, we say so. ## The three models, in one table | | Fable 5.1 | Fable 5 | Opus 5 | |---|---|---|---| | Context / max output | 1M / 128K | 1M / 128K | 1M / 128K | | Input / output ($ per MTok) | 10 / 50 | 10 / 50 | 5 / 25 | | Cache read ($ per MTok) | **0.25** | 1.00 | 0.50 | | Cache write, 5 min ($ per MTok) | 12.50 | 12.50 | 6.25 | | Batch ($ per MTok) | 5 / 25 | 5 / 25 | 2.50 / 12.50 | | Thinking | always on | always on | on by default, can be turned off up to `high` | | Effort levels | low → max | low → max | low → max | | Fast mode | no | no | yes, at 10 / 50 | | Zero data retention | no | no | yes | | Priority Tier | no | yes | no | | Safety classifiers | cyber, bio, reasoning extraction | the same | cyber only | One row worth reading twice: Opus 5 in fast mode costs exactly as much as Fable 5.1. For the same money you get either the most capable model, or a model one step down but with output up to 2.5 times faster. They're two different products at the same price, and the choice depends on what hurts: latency or quality on the hard tasks. ## Reasoning: what actually changed On both Fable models, thinking is always on. You can't send `thinking: disabled` without getting a 400, and the old `budget_tokens` is gone entirely. The only knob you have is `output_config.effort`, with five levels: low, medium, high, xhigh, max. Opus 5 is more permissive, it accepts turning thinking off, but only up to `high` effort, and the documentation tells you fairly bluntly not to do it, because the model starts writing tool calls as text instead of structured blocks. The important part for budgets is that **effort levels don't mean the same amount of thinking from one model to the next**. The migration guide says explicitly that you need to redo the effort sweep on 5.1 even if you did it on Fable 5. And it gives two reference points, which we've plotted below: at `medium`, Fable 5.1 roughly reaches Fable 5's results at a lower cost; and at `low`, Fable 5.1 often exceeds the `xhigh` or even `max` level of previous-generation models.
Same effort names, different amount of thinking effort → more thinking, more output tokens Fable 5 low medium high xhigh max Fable 5.1 low medium high xhigh max Opus 5 low medium high xhigh max medium on 5.1 ≈ high on Fable 5, at lower cost low on 5.1 ≈ xhigh or max on the previous generation Indicative reference points from the official migration guide. Not benchmark scores; redo the effort sweep on your own evals.
The practical consequence: if you run Fable 5 at `high` (the default setting), the first experiment on 5.1 is to drop to `medium` and see whether your evals still pass. If they do, you've got the same quality with fewer output tokens, which are the expensive part. The real capability gain over Fable 5 shows up, the documentation says, mostly at `high` and above, so the top level stays reserved for the tasks where you've measured that it's worth it. Something that hasn't changed and is good to know: the tokenizer is the same on Fable 5, Fable 5.1 and on the Opus family from 4.7 onward, so the token count for the same prompt is comparable. The cost difference between models comes from price and from how much they think, not from how they split the text. ## Where 5.1 is better than 5 Anthropic lists six areas, with the note that the difference is largest at high effort levels: 1. **Agentic coding over long sessions**: multi-file features, large refactors and migrations, debugging and code review in sessions lasting hours. 2. **Documents, spreadsheets and presentations** built from scratch, with live formulas, not just text. 3. **Multi-step research**, meaning web search where it follows up on what it found, not just a single query. 4. **Vision** on dense charts, tables in PDFs and degraded images. It works best with crop and zoom tools available, not with more thinking. 5. **Long-context retrieval**, deep into the 1M window. 6. **Computer use**: operating a browser or desktop applications, with recovery from failed steps. Multilingual performance is at parity with Fable 5. We don't have benchmark figures from Anthropic for the 5.1 versus 5 comparison, so we're not making them up. What we do have are the three behavior changes observed in harnesses, without any code change: 5.1 batches implicit tool calls less, narrates less between calls and, at `low` effort, more often answers from memory instead of checking. All three are fixed with a prompt, and the documentation provides the exact text. ## The real cost: cache at a quarter This is where the money story is, and it's hidden in a single row of the pricing table. A cache read on Fable 5.1 costs $0.25 per million, versus 1.00 on Fable 5 and 0.50 on Opus 5. It looks like a detail, until you look at what an agentic session actually does: it re-reads the same prefix on every turn. A system prompt with tools, then the entire conversation history, forty times in a single session. In a scenario like that, cache reads are by far the largest volume of tokens, even if not the largest cost. We worked out a typical scenario so you can see the proportions. An agent with a 20,000-token prefix (system prompt plus tool definitions), 40 turns, each turn roughly 3,500 new input tokens from tool results and 3,000 output tokens, thinking included. All with caching active, with the breakpoint moved on every turn.
Anatomy of the cost of a 40-turn agentic session $0 $4 $8 $12 ≈ $8.90 Fable 5.1 $0.88 ≈ $11.50 Fable 5 $3.53 ≈ $5.80 Opus 5 $1.77 output, thinking included (120K tokens) cache read (3.53M tokens) cache write (160K tokens)
Two things come out of the chart. First: for the same number of tokens, Fable 5.1 is roughly a quarter cheaper than Fable 5 on an agentic session, purely from the cache read price. If you add that at `medium` you do the same job with less thinking, the real saving is bigger. Second: Opus 5 remains the cheapest by a clear margin, about 35% below 5.1 in this scenario, and the difference comes almost entirely from output tokens, which cost half. There's also a less pleasant side to cheap cache. When a read costs 0.25 and a write 12.50, a cache miss is 50 times more expensive than a hit. On Fable 5 the ratio was 12.5. In other words, on 5.1 **keeping the cache warm matters much more**: a system prompt change between requests, a timestamp in the prompt or a pause beyond the five-minute TTL costs you relatively more than before. For pauses between 5 and 60 minutes, the documentation recommends a re-send with `max_tokens: 0`, which is usually cheaper than the one-hour TTL. ## Three changes that break code on migration The price is the same, but the API isn't a drop-in. Three things that worked on Fable 5 return a 400 on 5.1. **Forcing a tool no longer exists.** `tool_choice` with `any` or with a tool name is rejected. If you were using forcing to get guaranteed JSON, replace it with structured outputs. If you were using it to make sure the model calls the tool, you use `auto` plus an explicit instruction and `strict: true` on the tool schema. **Thinking blocks are tied to the model that produced them.** If you send the history of a conversation from Fable 5.1 to Opus 5 (for example as a fallback on a refusal), Opus 5 ignores the thinking blocks, without billing them. In the other direction, Fable 5.1 reads those of older models. In practice you can no longer move a session freely between models without losing the reasoning context. **History is append-only.** This is the one that hurts the most and it's called "preserved thinking" in the documentation. If you edit an earlier turn of the conversation (delete a message, rewrite the system prompt, trim the history), all thinking blocks after the edited point become invalid. Accounts created from 31 August 2026 get a 400 straight away on edited history, and the next models will enforce the rule for everyone. Many harnesses written for Opus 4.8 or older truncate old turns or inject and then delete reminder messages. All of them need to be rewritten.
Preserved thinking: why the harness has to be append-only A. HARNESS THAT EDITS HISTORY user assistantthinking + tool_use tool_resultedited / deleted assistantthinking invalidated tool_result assistantinvalidated Result: cache reset from the edited point, thinking lost, 400 on new accounts. B. APPEND-ONLY HARNESS user assistantthinking + tool_use tool_result systemclear_at: next_user assistantthinking valid systemeffort: low Result: the prefix doesn't change, the cache stays warm, expired messages cost no input tokens. The simple rule: nothing you've sent once ever gets modified; anything you want to change, you append at the end.
## Five API additions, all in service of the cache It's no coincidence that four of the five additions in 5.1 solve exactly the problem above: how you change something in the middle of a conversation without editing the history. - **Per-message effort.** An empty system message with `output_config.effort` changes the effort level from that point on, with no cache reset. You raise to `xhigh` for the hard step, drop to `low` for the routine steps, in the same conversation. It works on Opus 5 too, but not on Fable 5. - **System messages with an expiry.** `clear_at: "next_user_message"` makes a reminder visible for a single turn, after which it stays in the history but is no longer rendered and no longer costs anything. That's how you inject "check the inbox before running code" without deleting anything afterwards. - **Progress updates between tool calls.** With `display: "updates"`, the model returns the short progress notes it writes between calls, while the actual reasoning stays hidden. Without this, a 10-minute agentic turn looks like a 10-minute pause in the UI. - **Cache read at 0.25.** Discussed above. - **Content provenance.** All text generated by 5.1 carries a statistical watermark, with no hidden characters and no extra tokens. Images and media files produced in the code execution sandbox get signed C2PA Content Credentials. It's the first time an Anthropic model ships with this by default, and it can't be turned off. One more piece of context: Claude Mythos 5.1 is the same model as Fable 5.1, with the same prices and API, offered only to Project Glasswing participants. We wrote in April about [what Mythos is and how much of it is marketing](/en/blog/claude-mythos-dangerous-or-marketing); the difference from back then is that Mythos 5.1 now runs its own safety classifiers, depending on the organization's access program. ## Data retention: the decision point for enterprise One row in the table changes the discussion for an entire category of customers. Fable 5 and 5.1 are "Covered Models": Anthropic requires the organization or workspace calling them to have 30-day data retention active. If you have zero data retention in your contract, the request gets a 400 with an explicit message, and the only way around it is an express authorization negotiated with the account team. For most companies nothing changes, because 30-day retention is the default setting. For banks, healthcare, law firms or the public sector, where ZDR is often a condition from the GDPR impact assessment, the choice between Opus 5 and Fable 5.1 is no longer one of cost and capability. It becomes a conversation with the DPO: Opus 5 works under ZDR without any change, Fable 5.1 means either a separate workspace with retention, or an authorization, or giving up the model. ## When to choose what The official positioning is clear and worth taking seriously because it's not what you'd expect from a vendor: start with Opus 5, move to Fable 5.1 only for intense reasoning and long-running agentic tasks, or when the evals on Opus 5 at high effort don't hit the threshold.
Opus 5, Fable 5 or Fable 5.1: the decision tree Zero data retention in your contract? yes no Do the evals on Opus 5 at high / xhigh hit your quality target? yes Opus 5 half the price, ZDR, fast mode no Do you depend on Priority Tier? yes Fable 5 still served, cache at 1.00 no Fable 5.1 start at high, drop to where the evals hold
There's only one reason left to stay on Fable 5: Priority Tier, which doesn't exist on 5.1. Otherwise, 5.1 does the same job for the same money per token, with the cache four times cheaper. For those coming from Opus 5, the jump is a doubling of the per-token price, on top of which come the loss of ZDR and a broader set of classifiers. It's worth it only if you've measured that Opus 5 at `xhigh` doesn't get where you need it to, or if you have a use case in one of the six areas above where the difference is visible. What we've observed in practice, in our [day-to-day work with Claude Code](/en/blog/one-month-of-claude-code-measured), is that the biggest win doesn't come from choosing the model, but from choosing the effort. A Fable 5.1 at `medium` on routine tasks and at `xhigh` on the hard ones, in the same session, beats both a Fable 5 run uniformly at `high` and an Opus 5 that needs two attempts on the hard tasks. And per-message effort is exactly what makes this setup possible without paying for the cache reset. If you're already running agents on Fable 5 or Opus and want to know what the migration would cost you, including rewriting the harness for append-only, [let's talk](/contact).