Why doesn't Anthropic just give a single unified savings percentage instead of vague categories like "typical workload" and "highly agentic workload"?
Because the percentage saved isn't fundamentally a fixed property of the model — it's the result of multiplying "your usage pattern" by "the size of the discount." The discount itself (75%) is the same for everyone, fixed. But cache reads' share of any individual's bill depends entirely on their own usage pattern, and that can vary enormously between different accounts and different kinds of tasks. If Anthropic gave a single number, it would be inaccurate information for anyone whose cache share is particularly high or particularly low.
Using the two categories "typical workload" and "highly agentic workload" is essentially describing two representative endpoints of cache share, not a precise technical definition — which is also why this piece recommends going back and calculating your own actual share directly, rather than first deciding which category you "seem more like." The categories exist as a communication shorthand, not a precise formula meant to be applied literally.
If the percentage I actually calculate is quite different from the official 25% or 45%, did I calculate it wrong?
Not necessarily. This formula (cache share times 75%) produces a theoretical expected value, and the actual bill can diverge from that expectation for a few reasons. The first factor is effort level — Fable 5.1 defaults to High effort in Claude Code, and Medium effort in Claude Cowork and Claude.ai. Different effort levels affect how many output tokens get generated, which in turn shifts the relative proportion of input, output, and cache reads on the bill.
The second factor is a behavioral change in the task itself — if Fable 5.1's improved reasoning lets the same task complete in fewer back-and-forth turns, or produces more concise output, the composition of your bill will differ from the pattern you were used to under Fable 5. Applying the formula directly to old usage records will naturally produce an expected value that diverges from the new model's actual bill. A more prudent approach is to recalculate once you have actual usage data from running the new model for a while, rather than doing a one-time estimate based solely on pre-upgrade data.
What data do I need to actually calculate my own cache share, and how exactly do I do the math?
At minimum, you need usage details over some period of time (ideally at least a few days to a week of normal usage, to avoid any single day's anomalous spike skewing things), broken down into three categories: freshly-input Token usage, model output token usage, and cache-read token usage. If you also use cache writes, you can note that too, but write pricing itself hasn't changed and doesn't factor into this particular calculation.
The math itself is straightforward: divide your cache-read token count by the sum of "fresh input tokens + output tokens + cache-read tokens," and the result is cache reads' share of your bill. Multiply that share by 75%, and you get the overall percentage your workload can theoretically expect to save. For example, if over some period your cache-read tokens were 6 million, fresh input was 3 million, and output was 1 million, the total is 10 million, giving a cache-read share of 60%. Multiplied by 75%, that's roughly 45% — meaning your usage pattern already sits close to what Anthropic calls a "highly agentic workload."
If the percentage I calculated is low, is there a way to actively increase my cache-read share to get closer to the high-savings end Anthropic describes?
Yes, but only if doing so genuinely fits your task's actual needs, rather than deliberately distorting your workflow just to save money. In practice, increasing cache share usually means keeping highly repetitive content — system instructions, tool definitions, frequently-referenced documents, project background — stable and unchanged, placed in a consistent position within the conversation or request, giving it a real chance to hit the cache, rather than rephrasing it slightly differently each time. Even when the meaning is identical, small wording differences can cause a cache miss, falling back to full price.
The other direction is evaluating whether your tasks can be consolidated into longer, more continuous sessions rather than split into many independent short requests with no shared context between them — since a cache hit requires that this content has already been processed before, and if every request starts entirely fresh, there's naturally nothing to hit. But both adjustments should be prioritized against whether they genuinely make sense for the task itself. If your usage pattern is inherently made up of many independent, unrelated short queries, forcing them into a long conversation could actually sacrifice response quality — not a worthwhile tradeoff.
Claude Fable 5.1 cut prompt cache read pricing from $1 per million tokens to $0.25, a 75% reduction. Anthropic's official estimate is "25% savings for typical workloads, 45% for highly agentic ones," but those two numbers aren't arbitrary — there's a formula behind them you can apply yourself. Understanding it lets you roughly estimate what your own bill will actually save, rather than just picking whichever of the two broad ranges sounds closer to your situation.
Fable 5.1's base input price stays at $10 per million tokens, output stays at $50, five-minute cache writes stay at $12.50, and one-hour cache writes stay at $20 — none of these moved. The only thing that changed is cache reads: down from $1 to $0.25. That means on your bill, only the unit price of "cache reads" got cheaper — the unit prices of everything else (freshly-input tokens, model output tokens, cache writes) stayed exactly the same.
Because only one unit price changed, your actual percentage savings roughly equals "the share of your bill that cache reads used to represent" multiplied by 75%. If cache reads used to make up a third of your bill, your actual savings come to 33% times 75%, roughly 25% — exactly matching Anthropic's "typical workload" figure. If cache reads made up 60% of your bill, your savings come to 60% times 75%, roughly 45% — matching the "highly agentic workload" figure. This is also why Anthropic gives a range instead of a single number: everyone's actual share of cache reads in their bill is different, so applying the same 75% discount naturally produces a different overall savings percentage for each person.
The typical scenario with a high cache-read share is one where the same large context gets reread many times — an agent repeatedly rereading the same codebase, the same system instructions, the same set of tool definitions, or a conversation history that keeps accumulating and getting longer. Every step of a task like this usually needs to reread context that's already been processed, and that repeated rereading is exactly what the caching mechanism is designed to optimize for. Conversely, if your usage pattern sends fresh, largely unrelated content each time — independent short Q&A exchanges with no accumulated context, for example — cache reads inherently make up a small share of your bill to begin with, and this price cut's actual impact on you will be correspondingly smaller.
If you want to know exactly where you fall rather than picking one of the two broad official figures, the most direct approach is to go back through your actual usage records over some period, divide cache-read Token usage by total token usage (input plus output plus cache reads), and calculate cache reads' actual share of your overall bill. Multiply that by 75%, and you get roughly the percentage your own workload can expect to save. If you don't have this usage data on hand yet, it's worth taking the time to pull it — it produces a far more accurate estimate than simply assuming you fall into either the "typical" or "highly agentic" bucket.