How Much Anthropic Prompt Caching Actually Saved Me (Real Numbers)

Straight answer: reading a cached token costs one-tenth of the normal input price. If half your prompt is a fat, static system prompt plus tool schema that never changes, and you send it a few hundred times an hour, you're now paying 10 cents on the dollar for that half. In my own agent loops — where a long system prompt and a set of tool definitions ride along on every step — turning caching on cut my input-token spend by roughly 65%. Not the whole bill; the input half of it, which for context-heavy agents is most of the bill.

The reason it's not a flat 90% off your invoice is that only the repeated prefix gets the discount, and only on reads. Output tokens are never cached, and the volatile part of your prompt — the actual user question, the fresh data — still costs full price. So the real-world number depends entirely on one ratio: how much of your prompt is static and reused versus fresh every call.

Caching isn't free to turn on. The firsttime Claude sees a prefix it has to write it to the cache, and that write costs a premium over the base input price. The reads afterward are the cheap part. Here's the whole pricing model in one table, expressed as a multiple of the normal input price:

Run the numbers on two calls that share a prefix. Without caching: 1.0 + 1.0 = 2.0. With the 5-minute cache: 1.25 (write) + 0.1 (read) = 1.35. You're already ahead after the second call. With the 1-hour cache you pay 2.0 to write and break even on the second hit. After that, every additional reuse is basically free — 0.1x forever until the window expires.

The only way caching loses money is if you cache a prefix and then never reuse it before it expires. You paid the write premium for nothing. So the rule is simple: cache what actually repeats inside the window, and don't cache one-shot prompts.

When I first switched caching on, my savings were pathetic. The cache was writing constantly and almost never reading. The problem wasn't the feature — it was my prompt order. Caching matches on an exact prefix. If a single character changes before your cache breakpoint, the whole thing misses and Claude re-reads it at full price.

My prompt had a timestamp and a session ID up near the top, “for context.” That meant every request had a different prefix, so nothing was ever reused. The fix was to physically reorder the prompt so everything stable comes first:

# order that caches well
[ system prompt        ]   # static  -> cache
[ tool definitions     ]   # static  -> cache
[ long reference docs  ]   # static  -> cache
--- cache_control breakpoint here ---
[ this request's question / fresh data ]  # volatile

Everything above the breakpoint is byte-for-byte identical call after call, so it's written once and read cheap forever. Everything volatile lives below it and pays full price — but that part is small. That single reordering is what moved my hit rate from around 20% to consistently over 80%, and it's the same “stable stuff first” discipline I lean on when I'm trimming the token tax MCP servers add to every call.

Every one of these has bitten me or a client's codebase at least once. They don't error — they just silently cost you full price while you think caching is on.

• Volatile content before the breakpoint. A timestamp, a UUID, a per-user greeting, or a request counter near the top invalidates the whole prefix every call.
• Reordering tool definitions between calls. If your framework serializes tools in a non-deterministic order, the prefix changes even though the content is the same. Pin the order.
• Letting the window expire. The 5-minute cache is gone 5 minutes after the last hit. Low-traffic endpoints keep paying the write premium and never bank the reads — use the 1-hour cache there instead.
• Caching a prefix that's too small. There's a minimum cacheable length; a tiny system prompt may not be worth caching at all. Cache the big, boring blocks.
• Not measuring. If you're not reading cache_read_input_tokens vs cache_creation_input_tokens in the response, you have no idea whether it's working.

That last one is the whole game. Every response tells you how many tokens were written versus read. Log the ratio, watch it over a day, and you'll see instantly whether your prefix is stable. When reads dwarf writes, you've won. This is the same measure-before-you-optimize approach I used when I cut my Claude API bill by 73%.

Caching is worth the wiring when there's a big, repeated prefix. In practice that's three shapes I see constantly:

• Agents with tool schemas. Every step re-sends the same tool definitions and system prompt. That's a large static prefix riding on every single call — the ideal caching target.
• RAG and document Q&A. When several follow-up questions run against the same retrieved documents, cache the documents once and answer each question cheap.
• Chatbots with a fixed persona. The system prompt and early conversation turns repeat on every message; cache the stable head of the conversation.

It stacks with everything else, too. Prompt caching handles the repeated context; model routing handles sending easy steps to a cheaper model. I use both together on the same loop, which is the exact pattern behind running agents on autopilot without torching the budget. If you're still deciding how much agent scaffolding to build yourself versus lean on the SDK, that trade-off is in Claude Agent SDK vs the raw API. The official mechanics and current multipliers live in Anthropic's prompt caching docs.

• Cached reads cost 0.1x base input — a 90% discount on the repeated part of every prompt.
• Writes cost 1.25x (5-min) or 2x (1-hour), so caching breaks even after one hit on the short window, two on the long one.
• Only the exact static prefix is cached; put system prompt, tools, and docs first, volatile content last.
• A stray timestamp or reordered tool list before the breakpoint kills the whole cache — that was my 20% hit rate.
• Measure cache reads vs writes in every response. When reads dominate, you're saving; if writes dominate, your prefix isn't stable.
• Best targets: agents with tool schemas, RAG over shared docs, and fixed-persona chatbots.