Home › Claude Ecosystem Guides

Prompt Caching with Claude: Reuse a Stable Prefix to Cut Cost and Latency

Prompt caching stores a large, stable prefix of your prompt — a long system prompt, a big document, a fixed tool list — so repeated Claude requests reuse it instead of paying to reprocess the same tokens.

Last reviewed: 2026-09-04 · Українською

What prompt caching actually caches

Every request you send to Claude is processed from the first byte: the model reads your whole prompt before it writes a single token of the reply. When a large chunk of that prompt is identical across many requests — a detailed system prompt, a reference document, a fixed set of examples — you pay to process the same text over and over. Prompt caching lets the API store that already-processed prefix and reuse it, so repeated requests skip the work.

You mark a point in the prompt as a cache breakpoint. The API keeps a snapshot of everything up to that point. The next request that begins with the exact same bytes reads the stored state instead of recomputing it. Cached input tokens are billed at a small fraction of normal input tokens — roughly an order of magnitude cheaper — and they return faster because the expensive prefill step is largely avoided.

Stable content first, volatile content last

Caching is a prefix match, not a fuzzy one. The API reuses the cache only for the longest run of bytes that is byte-for-byte identical to what it stored, starting from the very beginning of the prompt. A single changed character anywhere in that region invalidates everything after it.

This dictates prompt layout. Put the parts that never change at the top; put the parts that change every call — a timestamp, the user's current question, retrieved snippets that differ per query — at the bottom, after the breakpoint. Order your prompt from most-stable to most-volatile and the cache stays warm. Good candidates for the cached prefix:

• A long, reused system prompt or role definition
• A big document or knowledge base the model answers over
• A fixed set of few-shot examples
• A long list of tool definitions

When caching pays off — and when it does not

Caching saves money on repeated context, not on one-off calls. Writing to the cache the first time costs slightly more than a normal request; you recover that on the second and every later hit. So the pattern that wins is many requests sharing one large, stable prefix: a chatbot that carries the same long system prompt on every turn, a document-QA tool answering dozens of questions about the same file, an agent whose tool list and instructions stay fixed across a session.

If each request has a different prefix, or you send a prompt only once, caching adds cost instead of removing it. The break-even point depends on how large the shared prefix is and how often you reuse it — a bigger, more-reused prefix pays back faster.

Short lifetime, and how to confirm a hit

A cache entry is short-lived. By default it survives only a few minutes of inactivity before it expires, though the lifetime can be extended. In practice this means caching helps bursts of related traffic — a live conversation, a batch of queries against one document — rather than requests spread hours apart.

Never assume a cache is working; measure it. The response reports token usage that separates cache reads from freshly processed input. Watch the cache-read counter: if it is climbing on your repeated requests, the prefix is matching. If it stays at zero, something in your prefix is changing between calls — a moving timestamp, a reordered field, a whitespace difference — and you are paying full price every time.

Common pitfalls

The most frequent mistake is placing volatile content inside the cached prefix. Injecting the current date, a per-user id, or the retrieved passage before the breakpoint quietly busts the cache on every call. Keep everything above the breakpoint deterministic.

Caching also does not change what the model knows or how it reasons — it is purely a cost-and-latency optimisation for text the model would have read anyway. It sits underneath retrieval, tool use, and extended thinking rather than competing with them. And because entries expire quickly, a low-traffic endpoint may never get a second hit before the cache is gone, so verify with real traffic rather than a single test call.

Frequently asked

Does prompt caching change Claude's answers?

No. It only stores and reuses the already-processed prefix to save cost and time; the model sees the same tokens and produces the same kind of output it would without caching.

How do I know prompt caching is working?

Check the token usage in the response — it reports cache-read tokens separately. A rising cache-read count on repeated requests means your prefix matched; a count stuck at zero means something in the prefix changed between calls.

Why does my cache keep missing?

Almost always because volatile content sits inside the cached prefix. A moving timestamp, a per-user id, or a reordered field before the breakpoint invalidates the match — keep everything above the breakpoint byte-identical.

Continue in this track