Claude Fable 5.1: What 75% Off Cache Reads Means

By Lazar Milicevic · Published September 2, 2026 · 10 min read

You're running a document pipeline on Claude. Every invoice, contract, or support ticket that hits your agent re-sends the same 40-page policy PDF, the same tool definitions, the same few-shot examples. Your Anthropic bill last month was uncomfortable, and the finance team wants numbers. Anthropic just shipped Claude Fable 5.1 and Mythos 5.1 with a 75% discount on cached input reads, and if you architect for it, the math on your pipeline changes tonight.

This post is for people who already build with Claude — solopreneurs running agents, small teams doing RAG on internal docs, ops folks automating invoice or contract flows. I'm going to walk through what actually changed, how prompt caching works under the hood, where the 75% discount lands in a real bill, and how to refactor a prompt so you stop paying full price for the same 30k tokens every request.

What actually shipped: Fable 5.1 vs Mythos 5.1

Fable 5.1 and Mythos 5.1 are the same underlying model with two different deployment postures. Fable 5.1 is the generally available production variant with Anthropic's standard safety systems in place — it's what you point your API keys at for customer-facing workloads. Mythos 5.1 is the research-oriented variant with looser guardrails intended for red-teaming, evals, and internal exploration. If you're shipping a product, you want Fable.

The headline change for builders isn't a benchmark bump — it's the pricing lever. Cache read tokens on Fable 5.1 dropped to a fraction of standard input pricing (Anthropic is framing it as a 75% cache-read discount versus the base input rate; check the current pricing page for the exact per-million-token numbers by the time you read this, since they iterate on this).

For anything with a large, stable system prompt — RAG pipelines, agentic tool loops, document Q&A over a corpus that doesn't change between turns — this is the biggest cost lever Anthropic has shipped in a long time. Nothing else in your stack moved. You just start paying dramatically less for the exact same tokens if you cache them correctly.

How Anthropic's prompt cache actually works

Prompt caching on Claude is a server-side feature: you mark a prefix of your prompt as cacheable using a cache_control marker, Anthropic stores the intermediate KV state on their infrastructure, and the next request that starts with the exact same prefix hits the cache and skips recomputation. You pay:

• Cache write (first request): slightly more than standard input price for the tokens you cache.
• Cache read (every subsequent hit): the discounted rate. With Fable 5.1, that discount widened to roughly 75% off input.
• Cache TTL: default is a short window (minutes). Longer TTLs are available at a higher write cost.

The critical constraint: the cache matches on exact prefix. Change a single token near the top of your prompt and the cache misses for everything downstream. This is why the order in which you assemble a prompt matters more than most people realize.

Here's the minimal shape of a cached request:

import anthropic

client = anthropic.Anthropic()

SYSTEM_POLICY = open("policies/refund_policy_v7.md").read()  # ~18k tokens
TOOL_DEFS = open("tools/agent_tools.json").read()             # ~4k tokens
FEW_SHOTS = open("examples/refund_examples.md").read()        # ~6k tokens

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": SYSTEM_POLICY + "\n\n" + TOOL_DEFS + "\n\n" + FEW_SHOTS,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        {"role": "user", "content": user_ticket_text},
    ],
)

The cache_control marker tells the server: everything up to and including this block is a cache boundary. First request writes the cache. Every request within the TTL that sends the identical prefix reads it.

Where the 75% discount actually lands on a real bill

Let's do this concretely. Say you're running a support triage agent for a mid-size e-commerce SMB. Every incoming ticket goes to Claude with:

• 22k tokens of policy documents and product catalog context
• 6k tokens of few-shot examples
• 2k tokens of tool definitions
• Average 400 tokens of actual ticket text
• Average 600 tokens of response

You process 8,000 tickets a month.

Without caching, every ticket pays full input price on ~30,400 tokens. With caching set up correctly, the first ticket per TTL window pays the write premium on 30k tokens; every ticket after that within the window pays the discounted read rate on those 30k, plus full input price on the ~400 tokens of unique ticket text.

The math without exact numbers (since pricing shifts): if you were spending roughly $X/month on input tokens, moving to a properly-cached architecture drops that portion of the bill by something in the neighborhood of 65-72% in practice — not the full 75% because you still have write costs, cache-miss traffic from expired TTLs, and the unique per-request tokens that never cache. In pipelines I've refactored, real observed savings have landed between 60% and 74% of the input-token line item after the switch.

The output tokens don't change. If your bill is output-heavy, this lever is smaller. If your bill is input-heavy — which is the case for almost every RAG or agent workload — this is the biggest single optimization available to you right now.

Refactoring a prompt so it actually caches

Most existing prompts don't cache well because they were written before caching mattered. Common anti-patterns I see in client codebases:

Timestamps in the system prompt. Someone added Current time: 2026-09-02T14:32:11Z at the top of the system message "so the model knows." That single dynamic string breaks the cache on every request.

User-specific context mixed with shared context. The customer's name, account tier, and last order are stitched into the top of the system prompt. Every user gets a cache miss.

Tool definitions after user input. Tools change rarely; user input changes every request. If tools live below the message content in your assembly order, they never cache.

Retrieved chunks re-ordered per query. Your RAG layer returns the same 6 chunks in a different order each time. Same content, different prefix, no cache hit.

The fix is a discipline: assemble prompts as a strict hierarchy from most stable to least stable, and put the cache_control marker at the boundary between stable and volatile.

def build_prompt(user_query: str, user_ctx: dict, retrieved: list[dict]):
    # LAYER 1: Never changes (weeks)
    stable = SYSTEM_INSTRUCTIONS + TOOL_DEFS + FEW_SHOTS

    # LAYER 2: Changes daily (policy updates, catalog refresh)
    semi_stable = load_policy_bundle()  # cached separately if large

    # LAYER 3: Per-request
    # Sort retrieved chunks deterministically so identical retrievals
    # produce identical prefixes
    retrieved_sorted = sorted(retrieved, key=lambda c: c["doc_id"])
    dynamic = format_chunks(retrieved_sorted) + format_user_ctx(user_ctx)

    return {
        "system": [
            {"type": "text", "text": stable,
             "cache_control": {"type": "ephemeral"}},
            {"type": "text", "text": semi_stable,
             "cache_control": {"type": "ephemeral"}},
        ],
        "messages": [
            {"role": "user", "content": dynamic + "\n\n" + user_query}
        ],
    }

Two cache breakpoints, two layers of savings. The rare policy update invalidates only Layer 2. Everything above it keeps hitting the cache.

For agent loops — where you're calling the model repeatedly with a growing message history — mark the system block as cached and let the conversation history extend below it. Each turn re-reads the cached prefix at the discounted rate and only pays full price on the incremental turn.

Where this changes architecture decisions

The cheaper cache reads don't just lower a bill — they change which designs are worth building at all.

Bigger context, cheaper. Workflows I would have chunked and stitched together to stay under a smaller effective context budget are now viable as single-shot calls. Feeding a 40-page contract plus a 20-page playbook into one Fable 5.1 call becomes routine rather than expensive.

Longer few-shot examples. If you were previously trimming few-shots to save tokens, extending them to 15-20 grounded examples is now cheap on repeat use. Quality on structured extraction goes up noticeably when the examples cover more edge cases.

Multi-tenant pipelines can share prefixes. If ten of your SMB clients use the same core policy bundle with per-tenant overrides at the bottom, you can architect the shared prefix as the cached layer and only pay full price on the per-tenant delta. This was possible before, but the economics didn't always justify the engineering. They do now.

Agent tool loops are dramatically cheaper. An agent that takes 6 turns to complete a task was previously paying full input price on the growing conversation each turn. With aggressive caching of the system+tool prefix, only the growing tail costs full price. Multi-turn agent economics stop being a blocker for a lot of small-team use cases.

Cache misses: the traps that eat your savings

I've watched teams announce "we turned on caching" and then see almost no bill change. Here's what breaks it:

The last one is worth calling out: prompt version discipline matters more now. Treat the system prompt like a shipped artifact with a version, not something you tweak in a hot patch at 3pm. A one-word edit at the top of a 30k-token system prompt invalidates the cache for every user until traffic warms it back up.

Instrumentation: don't fly blind

The API response includes cache usage on every call. Log it. Every request should record:

usage = response.usage
metrics = {
    "input_tokens": usage.input_tokens,
    "cache_creation_tokens": usage.cache_creation_input_tokens,
    "cache_read_tokens": usage.cache_read_input_tokens,
    "output_tokens": usage.output_tokens,
}
# Ship to your metrics backend

The number you actually care about is your cache hit rate on input tokens: cache_read / (cache_read + cache_creation + input). Healthy pipelines land above 90% once tuned. If you're below 60%, your prefix is unstable and you're leaving most of the discount on the table.

I put this behind a simple daily digest for clients — a Slack message every morning with cache hit rate, total input tokens by layer, and top 3 requests that missed the cache. That's usually enough to catch a bad prompt deploy within a day instead of at end-of-month billing.

How BizFlowAI approaches this

We build document pipelines and agent workflows for solopreneurs and small teams — invoice extraction, support triage, contract review, RAG over internal knowledge bases. Prompt-cache architecture has been part of how we assemble prompts since caching shipped; the Fable 5.1 discount doesn't change the technique, but it changes how aggressively it's worth pushing. On several existing client pipelines we're re-running the numbers this week to see whether we can restructure prefixes and extend TTLs to capture more of the new discount.

If you're running a Claude-backed workflow and your input-token line item is meaningful, it's worth a discovery call to look at your current prompt assembly, cache hit rate, and whether a Fable 5.1 refactor pays for itself. Most of the time it does — and often within the first month.

What to do this week

If you already build on Claude:

1. Pull last month's usage report. Separate input, cache-write, cache-read, and output tokens. If cache-read is under 60% of input tokens, you have room.
2. Point one non-critical workload at claude-fable-5-1 and confirm parity on your evals before migrating production.
3. Audit your prompt assembly for the six traps in the table above. Fixing chunk ordering alone typically recovers 10-20 points of hit rate.
4. Add cache metrics to your logging pipeline before you refactor, so you can measure the delta honestly.
5. Set a prompt version discipline: treat the stable prefix as a shipped artifact, deploy changes off-peak, and communicate them.

The 75% cache read discount isn't a free lunch — you still have to architect for it. But for the class of workloads most small teams are actually running on Claude, this is the biggest cost lever available right now, and it's available on the first day of Fable 5.1 being on the API.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.