Anthropic shipped Claude Fable 5.1 and Claude Mythos 5.1 with a benchmark headline — 52.6% on Terminal-Bench-Science, more than double the previous generation — but the number that shows up on your invoice is buried further down the release notes: cache reads now cost 75% less. That is a pricing change, not a model change, and it lands the same week Glean publicly claimed Anthropic customers overpay by roughly 80% on token spend. Those two facts collide usefully. If the biggest source of waste in production Claude apps is re-sending the same context over and over, a 75% discount on the cheap path makes the gap between a well-structured prompt and a lazy one enormous. If you run anything on Claude at volume, the Claude Fable 5.1 release is worth an afternoon of prompt refactoring this week, not next quarter.
What’s actually new in Claude Fable 5.1
The model side is a point release and behaves like one. Claude Fable 5.1 is the frontier reasoning model in the family; Claude Mythos 5.1 is the companion release tuned for longer-horizon agentic work. The flagship claim is Terminal-Bench-Science, a benchmark that drops a model into a real terminal and asks it to complete scientific computing tasks — install dependencies, wrangle data files, run analyses, debug when the environment fights back. Scoring 52.6% means the model completed roughly half of tasks that require chaining many correct shell decisions with no human in the loop. The prior generation sat in the low twenties. Doubling on a benchmark that punishes compounding errors is a real signal about agent reliability, which is what most teams are actually blocked on.
Read the pricing side twice. Anthropic’s prompt caching has always worked on a three-part economy: you pay a premium to write a cache entry, a normal rate for uncached input tokens, and a steep discount to read from a warm cache. The Anthropic cache read discount just got much steeper — cache reads drop 75% versus the previous rate, pushing the read price down toward a rounding error relative to base input tokens. Cache write pricing and the TTL structure (a short default window, with a longer-lived option) are unchanged. Nothing about your existing integration breaks; you simply pay less for tokens you were already caching, and you have a much stronger incentive to cache tokens you weren’t.
That reframes Glean’s 80% overpayment claim. Read uncharitably, it is competitive marketing from a company that sells enterprise search. Read charitably, it describes a real and extremely common failure mode: teams build a RAG or agent system, stuff a 30,000-token system prompt and document set into every request, never mark a cache breakpoint, then conclude that Claude is expensive. The model isn’t expensive — re-billing full price for identical bytes on every turn is. Claude Fable 5.1 pricing makes the fix cheaper than it has ever been, which also makes the penalty for ignoring it proportionally larger.
Why Claude Fable 5.1 pricing matters
- Long system prompts stop being a cost problem. The instinct to keep prompts short to save money was always a tax on quality. With cache reads at a quarter of their former price, a detailed 20k-token system prompt that stays stable across a session costs almost nothing to re-read every turn.
- Multi-turn agents get dramatically cheaper per step. Agent loops re-send the entire conversation each iteration. That is the workload prompt caching was designed for, and the one that benefits most from the discount — a 30-step agent run can bill the majority of its input tokens at the read rate.
- RAG economics shift toward bigger, stabler context. If your retrieved chunks change on every query, you get no cache benefit. Restructure so a stable corpus sits in the cached prefix and only the query varies, and most of your input bills at the discount. That argues for fewer, larger, more static context blocks.
- The Terminal-Bench-Science result lowers the babysitting cost. Cheaper tokens matter less if a human reviews every agent action. A model that completes half of hard terminal tasks unattended changes which workflows you will automate at all.
- Prompt ordering becomes a first-class engineering concern. Caching is prefix-based. Put anything variable — a timestamp, a user ID, a random session token — near the top and you invalidate everything after it. Cost now depends on prompt layout, not just prompt length.
- Migration is close to free. This is a point release in the same family. In most codebases the change is one string, so the savings need no large engineering budget to justify them.
How to use Claude Fable 5.1 today
-
Update the SDK and switch the model ID. The family’s base identifier is
claude-fable-5; the point release follows the same convention with the version suffix. Confirm the exact current string in Anthropic’s model documentation before you deploy — model IDs are the one thing worth verifying rather than copying from an article.pip install -U anthropic # or npm install @anthropic-ai/sdk@latest -
Make one call and confirm it works before touching anything else.
import anthropic client = anthropic.Anthropic() resp = client.messages.create( model="claude-fable-5-1", max_tokens=1024, messages=[{"role": "user", "content": "Summarize what changed in this release."}], ) print(resp.content[0].text) print(resp.usage) -
Add a cache breakpoint to your stable prefix. This is where the prompt caching savings come from. Mark the end of the content that does not change between requests — system instructions, tool definitions, reference documents, few-shot examples.
resp = client.messages.create( model="claude-fable-5-1", max_tokens=2048, system=[ { "type": "text", "text": LONG_STABLE_INSTRUCTIONS + REFERENCE_DOCS, "cache_control": {"type": "ephemeral"}, } ], messages=[{"role": "user", "content": user_question}], ) -
Verify you are actually hitting the cache. Teams skip this step, and it is the difference between a real discount and a placebo. Read the usage block on every response during testing.
u = resp.usage print("cache writes:", u.cache_creation_input_tokens) print("cache reads: ", u.cache_read_input_tokens) print("uncached in: ", u.input_tokens)On the first call, writes should be large and reads zero. On the second identical-prefix call, reads should be large and writes zero. If reads stay at zero, your prefix isn’t byte-identical — hunt for a timestamp, a shuffled dict, or a re-ordered tool list.
-
Reorder your prompt so nothing volatile sits above the breakpoint. Static content first, then the cache breakpoint, then everything that varies.
[ system instructions ] <- static [ tool definitions ] <- static [ reference corpus ] <- static [ ---- cache_control ----- ] [ conversation history ] <- grows [ current user message ] <- varies every call -
Choose your TTL deliberately. The default cache window is short — fine for an active chat session or an agent loop firing every few seconds. For a batch job that processes documents against the same instructions over an hour, request the extended TTL; you pay a higher write premium once and read cheaply for far longer.
-
Measure before and after on a real workload. Run a representative day of traffic through the old configuration and the new one, then compare billed input tokens rather than request counts. If you cannot show the delta in a dashboard, you cannot defend the refactor later.
How it compares
| Dimension | Claude Fable 5.1 | Claude Mythos 5.1 | Prior generation |
|---|---|---|---|
| Positioning | Frontier reasoning and hard analysis | Long-horizon agentic and tool-use work | General frontier |
| Terminal-Bench-Science | 52.6% | Competitive, tuned for sustained runs | Roughly half the 5.1 score |
| Cache read cost | 75% lower than prior rate | 75% lower than prior rate | Baseline |
| Best fit | Deep single-shot reasoning, code review, research synthesis | Multi-step agents, terminal automation, background jobs | Legacy integrations |
| Migration effort | Model ID swap | Model ID swap | — |
Against the broader field, raw benchmark leads trade back and forth every few months and rarely survive a quarter. Structural pricing changes are stickier. A competitor can match a benchmark number; matching a 75% cut on the most-used discount tier is a margin decision, not an engineering one.
What’s next
Watch whether the cache read discount pulls competitors along. Prompt caching is now standard across major providers, but the read multiplier varies meaningfully. If Anthropic’s new rate becomes the reference point, expect matching announcements within a couple of release cycles — and expect differentiation to move to cache write pricing and TTL flexibility, the remaining levers.
Watch Terminal-Bench-Science as a category too. Benchmarks that run real environments are harder to game than static Q&A sets, but they are also noisier: task selection, container images, and time limits all move the number. Treat 52.6% as directionally meaningful, then build your own eval on tasks you care about. The teams getting the most out of agentic models spent a week writing twenty representative tasks with pass/fail criteria, and can now re-run them against any new model release in an afternoon.
Finally, watch what Glean’s overpayment claim does to procurement conversations. Whether or not 80% is the right figure, the underlying point — that most Claude spend is structurally avoidable — is now on the table in enterprise budget meetings. The defensible position is not arguing about the number. It is having the cache-hit metrics from step four on a dashboard, showing exactly what fraction of your input tokens bills at the read rate, and what you did to get there.
Frequently Asked Questions
What is the model ID for Claude Fable 5.1?
It follows the family convention built on claude-fable-5 with the point-release suffix. Because Anthropic occasionally adjusts naming and date stamps, pull the current identifier from the official models endpoint or documentation rather than hardcoding one from a blog post — including this one.
Do I need to change my code to get the cache read discount?
Not if you already use cache_control breakpoints — the lower rate applies automatically. If you have never set a breakpoint, you get nothing from the change. That is the whole point: the discount rewards prompt structure, and unstructured prompts are unaffected.
Why are my cache reads showing zero?
Almost always a prefix that isn’t byte-identical. Common culprits: injecting the current time into the system prompt, serializing tool definitions from an unordered structure, or interpolating a user or session ID above the breakpoint. Also check that your cached prefix exceeds the minimum token threshold — short prefixes aren’t eligible.
Should I use Claude Fable 5.1 or Claude Mythos 5.1?
Fable 5.1 for deep reasoning on a bounded problem — code review, analysis, synthesis. Mythos 5.1 for long agentic runs where the model executes many tool calls over an extended horizon. If you’re unsure, run both against your own eval set; testing costs little and the routing decision compounds.
Does prompt caching hurt output quality?
No. Caching changes how input tokens are billed and processed, not what the model sees. A cached prefix produces the same context as an uncached one. The only quality risk is indirect: cramming stale reference material into a cached block just because it’s cheap now.
Is the Glean 80% overpayment claim credible?
Treat the specific number as marketing and the mechanism as real. Teams that send full context uncached on every request genuinely pay several times what a cache-aware implementation costs. The productive response is to instrument your own usage and find out where you land.
Go deeper than this article
This article covers the essentials. Our premium eguide library gives you the full step-by-step playbooks — prompts, workflows, and copy-paste recipes you can put to work today.
