How Prompt Caching Saves 90% on Your Claude Bills

Okay here is a story. You build an AI app. It has a big system prompt, like 10,000 tokens. Maybe it has tool descriptions, documentation, examples, some rules about how the bot should behave. All useful stuff.

Every time a user sends a message, you send that whole 10,000 tokens again, plus the user’s new message. The model has to read those same 10,000 tokens every single time, even though they never change.

And you pay for every token. Every call.

This is exactly what prompt caching fixes. Let me show you.

1. Why this even exists

A call to Claude Sonnet costs around $3 per million input tokens (current pricing here). Sounds cheap. But it adds up fast.

Say your system prompt is 10,000 tokens. 1000 users each send 5 messages. That’s 50 million tokens of system prompt, re-read over and over. That is $150 just to keep telling the model the same stuff you already told it.

And the model actually has to process those tokens too. So latency goes up. Users wait longer. Bad.

Analogy: imagine you are a barista. Every customer walks up and before taking their order you explain “what is coffee, what sizes do we have, what flavors are possible”. Every single customer. That’s a waste of time. You already know it. They already know it. Just take the order.

2. What caching actually does

Anthropic lets you mark a chunk of your prompt with a “cache this” flag. The first time the model sees that chunk, it processes it normally and saves a snapshot of what it figured out. The next time (within 5 minutes), it loads the snapshot instead of re-reading the whole thing.

Reading from the cache costs about 10 percent of the normal input price. So that $3 per million becomes $0.30 per million for cached stuff. That is a 90 percent discount.

On the FIRST call with caching:

• Cache WRITE (a tiny bit more expensive than regular input, about 1.25x)
• The model processes your full prompt

On the NEXT calls (within 5 minutes):

• Cache READ (cheap, 0.1x of input price)
• Model skips ahead from the saved snapshot

Step through the demo. First call writes the cache. All the next calls just read from it. See how little work happens on cached calls.

3. How you actually turn it on

In the Anthropic API you just add a cache_control marker to the message block you want cached. Usually your system prompt.

system = [
  {
    "type": "text",
    "text": "... your huge system prompt with tool descriptions, docs, examples ...",
    "cache_control": {"type": "ephemeral"}
  }
]

The ephemeral type means the cache lives for 5 minutes by default. You can extend to 1 hour if you pay a bit more on the write.

Important: the cache key is the EXACT bytes of your prompt. If you change even one character, it becomes a cache miss and you pay the full write price again. So do not inject timestamps or random IDs into your cached section.

4. Let’s look at the money

Here is a real world example you can play with.

Say you have a 20,000 token system prompt. A user sends 10 messages in a chat session. Each user message is around 200 tokens. Each model response is around 500 tokens.

Play with the sliders. You will see most of the savings come from NOT re-sending that big system prompt over and over. The bigger your system prompt and the more calls you make, the bigger the win.

5. When it helps (and when it does not)

It helps a LOT when:

• You have a big system prompt that never changes
• You have long documentation or example outputs in the prompt
• You have a long chat history that gets resent every turn
• You have a RAG system where you cache the same retrieved docs across calls

It does NOT help when:

• Every call has totally different context
• Your prompts are small anyway (under 1024 tokens does not even qualify for caching)
• The time between calls is more than your TTL (5 minutes by default, the cache expires and you lose it)

6. Some gotchas to remember

Cache breakpoints. You can have up to 4 cache_control markers in one request. The cache matches by longest prefix, so usually you put the marker on your biggest stable block first.

Order matters. Cache hits work on PREFIX. If you change something in the middle of the cached block, everything after that is a miss. Stable stuff first, dynamic stuff last.

TTL. Default 5 minutes. You can extend to 1 hour with a longer TTL flag but it costs more to write. For active chat apps, the 5 minute default is usually fine because users keep the conversation going.

Minimum size. Cache only kicks in if the cached content is at least 1024 tokens for Sonnet and Opus, and 2048 tokens for Haiku. Below that, caching does nothing even if you ask for it.

Cache invalidates on model change. If you switch from Sonnet to Opus, that is a fresh cache.

Wrap up

Prompt caching is one of those features that sounds boring but saves you serious money once your app has real traffic. If you are building anything with Claude that reuses context across calls, turn it on. Today.

The basic idea is simple. Don’t pay to re-read the same tokens over and over. The model already figured them out once. Just cache the snapshot.

Sources

• Prompt caching docs (Anthropic). The official reference. Covers cache_control, TTL options, minimum sizes, and the exact pricing multipliers.
• Messages API reference. The full API surface, with examples of where cache_control goes in a request.
• Anthropic pricing. Current per-model token rates for input, output, cache write, and cache read.