Claude Fable 5.1: The 75 Percent Cache Read Cut and What Else Changed (2026)
Anthropic released Claude Fable 5.1 on September 1, 2026, keeping the headline rates at 10 dollars per million input tokens and 50 per million output but cutting the cache read price from 1.00 to 0.25 dollars per million, a 75 percent drop. That single line is more consequential for anyone running agents than the benchmark gains, because agentic workloads re-send a large, stable context on every turn, and cache reads are how you avoid paying full input price for it over and over. At 0.25 per million, a cache read is 2.5 percent of the normal 10 dollar input rate, which changes what a long context agent actually costs to operate. This post explains what cache reads are, why the cut lands hardest on agent loops, what else changed in 5.1, and how the restricted access Mythos 5.1 sibling fits.
Claude Fable 5.1: The 75 Percent Cache Read Cut and What Else Changed (2026)
Anthropic shipped Claude Fable 5.1 on September 1, 2026, and most coverage led with the model being smarter. The line that actually changes how you budget is quieter: cache reads dropped from 1.00 to 0.25 dollars per million tokens, a 75 percent cut, while input stayed at 10 and output at 50. For anyone running agents, that is the most important number in the release, because agents live and die on how cheaply they can re-read a large, stable context on every turn.
| Item | Claude Fable 5 | Claude Fable 5.1 |
|---|---|---|
| Input price | 10 dollars per million tokens | 10 dollars per million tokens |
| Output price | 50 dollars per million tokens | 50 dollars per million tokens |
| Cache read | 1.00 dollars per million tokens | 0.25 dollars per million tokens |
| Context window | 1,000,000 tokens | 1,000,000 tokens |
| Max output | 128,000 tokens | 128,000 tokens |
| Release date | prior | September 1, 2026 |
What a cache read is, and why it is the number that matters
When you call a model, you pay the input rate for every token in the prompt. Prompt caching lets the provider store the tokens it has already processed so that on the next call, the unchanged prefix is billed at a much lower cache read rate instead of the full input rate. On Fable 5.1, that cache read rate is now 0.25 dollars per million tokens, which is 2.5 percent of the 10 dollar input price. In other words, re-reading cached context is roughly 40 times cheaper than sending it fresh.
This matters because of how agents are shaped. An agent loop typically carries a large, stable payload: a system prompt, tool definitions, retrieved documents, and a running transcript. Most of that does not change between turns. Without caching, you pay full input price for the whole thing on every single step, and a multi step agent re-sending a big context can spend most of its budget re-reading the same tokens. With cache reads at 0.25, that repeated context becomes almost free, and the meaningful cost shifts to the new tokens and the output. Anthropic's own framing puts the effective savings at roughly 25 percent on typical workloads and up to 45 percent on agentic ones, and the agentic number is the one to plan around.
How to design an agent to actually capture the savings
The cut only helps if your context is cacheable, which means it has to be stable and ordered so the cacheable prefix stays identical between calls. The practical rules are simple. Put the parts that never change first: system prompt, tool schemas, and any fixed instructions. Put the volatile parts last: the newest user message and the latest tool results. If you interleave changing content into the middle of an otherwise stable prompt, you break the cacheable prefix and pay full price for everything after the first change.
That is a design constraint, not an afterthought. Teams that treat prompt caching as something the provider does automatically leave most of the savings on the table, because they scramble the prompt order every turn. Teams that treat the prompt as a layered document, stable base then volatile top, capture the full cache read discount. We went deep on how caching interacts with throughput and cost across providers in Opus 4.8 versus GPT-5.5 versus Gemini 3.5 Pro on prompt caching, cost, and throughput, and the structural lesson there is the same: caching is a property of how you build the prompt, not a switch you flip.
Read the cut as a market signal too
A 75 percent cut to cache reads with input and output held flat is a targeted move. Anthropic did not lower the sticker price; it lowered the specific cost that dominates agent operation. That tells you where the competition is: the fight in 2026 is over agentic workloads, and the cost of running a long context loop is the battleground. When one lab holds its headline rates and slashes the number that agent builders actually feel, it is competing for agent traffic without a broad price war. We read a similar signal in Anthropic's decision to hold the line on Sonnet 5 pricing in Claude Sonnet 5 stays at 2 and 10 dollars, and the two moves together sketch a strategy: keep flagship and mid tier sticker prices stable, compete hard on the operational costs that decide whether an agent is affordable to run.
What else changed in 5.1
Beyond pricing, Fable 5.1 is a multimodal model with a 1 million token context and a 128K maximum output, adjustable thinking effort so you can trade latency for depth per call, and stronger long running agent behavior. Anthropic positions it against the most advanced models for coding and knowledge work, and it posts 52.6 on Terminal-Bench-Science, a benchmark aimed at scientific tool use in a terminal environment. If your interest is how it stacks up head to head on agentic coding rather than on cost, we put it against OpenAI's newest flagship in GPT-6 Astra versus Claude Fable 5.1 on agentic coding benchmarks.
The Mythos 5.1 sibling
Fable 5.1 ships alongside Mythos 5.1, which is the same underlying model exposed through a restricted access program for vetted cybersecurity and life sciences organizations. Fable 5.1 is the generally available version with Anthropic's production safeguards in place; Mythos 5.1 is the gated build for organizations that have been cleared for work where those safeguards would otherwise block legitimate research. For almost every team, Fable 5.1 is the model you will use. The Mythos split matters mainly as a signal that Anthropic is drawing a formal line between general availability and vetted access rather than trying to serve both from one endpoint.
FAQ
How much does the cache read cut save in practice? Anthropic frames it as roughly 25 percent lower cost on typical workloads and up to 45 percent on agentic ones. The savings are largest when a stable context is re-read many times, which is exactly the shape of an agent loop.
Do I get the discount automatically? No. You get it only on the cacheable prefix of your prompt, which must stay identical between calls. Order your prompt so the stable parts come first and the volatile parts last, or you break the cache and pay full input price.
Did the input and output prices change? No. Input stayed at 10 dollars per million tokens and output at 50. Only the cache read rate dropped, from 1.00 to 0.25.
What is Mythos 5.1? The same model as Fable 5.1, offered through a restricted access program for vetted cybersecurity and life sciences organizations. Fable 5.1 is the generally available version with standard production safeguards.
When this applies to your stack
If you run agents on Claude, the Fable 5.1 cache read cut is a reason to audit how your prompts are structured, because the savings are real but only if your context is cacheable. Reorder your prompts so the stable base comes first, measure your cache hit rate, and re-model your per run cost with cache reads at 0.25 rather than the full input rate. Contra Collective builds and cost engineers agent systems on Claude and other providers, and prompt cache structure is one of the highest leverage places to cut spend without touching quality. If your agent bills are climbing with usage, we can find where the cache is being wasted and fix the prompt architecture that is causing it.
External references: the VentureBeat report on Fable 5.1 and Mythos 5.1, the MarkTechPost writeup on the release, and the Claude Fable 5.1 model card on llm-stats.
More from the lab.
vLLM vs SGLang: Choosing a Production LLM Inference Engine in Late 2026
vLLM and SGLang are both open source, both built to serve LLMs at production scale, and both frequently recommended for the exact same job, which is exactly why teams keep picking the wrong one. The real difference is not a benchmark number. It is which attention and caching architecture matches your actual traffic pattern, and most teams never check that before they commit infrastructure budget to one or the other.
Ollama's MLX Backend Beats Metal by 93 Percent: Apple Silicon Local Inference Tested (October 2026)
Ollama's 0.19 release notes say it plainly: on Apple Silicon, Ollama is now built on top of Apple's MLX framework to take advantage of its unified memory architecture, rather than the Metal backed llama.cpp path it shipped for years. On an M4 Max running Qwen3.5, that swap took decode speed from 57.8 tokens per second to 111.4, a 93 percent improvement, and prefill from 1,154 to 1,810 tokens per second. The catch is in the fine print: the MLX runner is in preview, it needs 32GB or more of unified memory to activate at all, and as of this release it only accelerates one model family. Here is what actually changed, what it costs to turn on, and where it still falls back silently to the slower path.
DGX Spark vs Mac Studio M5 Ultra: Local LLM Inference Benchmarked (October 2026)
The M5 Ultra Mac Studio shipping in September 2026 is a quad die chip with 1.2 terabytes per second of memory bandwidth and up to 256GB of unified memory, with a 512GB configuration arriving in late October. Against a single NVIDIA DGX Spark, it is not close: on a 27B dense model, the Mac decodes at roughly four times the speed. Cluster two DGX Spark units together over NVIDIA's GX10 networking instead, and the comparison flips for a different workload entirely, concurrent multi user serving. Neither machine is the right answer for every workload, and the decision comes down to whether you are serving one user or several at once.