Prompt caching lets you mark a point in your request — via a cache_control field of type ephemeral on a content block — after which everything before it can be reused on a later call instead of reprocessed from scratch. The response's usage object reports cache_creation_input_tokens (written to the cache this call, billed at a premium over a normal input token) and cache_read_input_tokens (served from cache on a later call, billed at a steep discount versus a fresh read — roughly a tenth of the normal input-token price). You can place up to four cache breakpoints in a single request, which matters when a request has more than one genuinely independent stable segment — for example a large tool-definitions block and a large reference document that both repeat, but not in lockstep with each other.
Where to put the breakpoint
The win only materialises if the cached prefix is large and genuinely repeated across calls — a long system prompt, a big document the user is asking multiple questions about, a large tool definitions block. Put the breakpoint after that stable content and before the part that changes every turn (the latest user message). A cache breakpoint placed after content that changes every call caches nothing useful and just adds the overhead of writing a cache entry that will never be read. Anthropic also imposes a minimum token count for a segment to be cacheable at all — a very short stable prefix isn't worth a breakpoint even if it's technically stable.
Cache lifetime and exact-prefix matching
A cache entry has a short default TTL (around five minutes from last use, refreshed on each cache hit), with a longer-lived option available for workloads with a bigger gap between calls. Caching works on an exact-prefix match: everything up to and including the cache-controlled block must be byte-identical to what was cached, or the cache misses entirely and that segment is reprocessed as a normal (uncached) read — it doesn't partially hit. This is why caching pairs naturally with stable ordering: tool definitions and system prompt first (rarely changing), then any large shared document, then the per-turn conversation, with the breakpoint placed right after the last block you want covered.
Common exam distractor
An answer suggesting caching speeds up token generation is wrong. Caching only cuts the cost and latency of re-processing input the model has already seen; it has no effect on how fast output tokens are produced once generation starts. A cached request can still take just as long to generate a long answer as an uncached one.
Caching inside an agentic loop
In a multi-turn tool-use loop, each new call resends the growing conversation, and that growing prefix is exactly what benefits most from caching as the loop goes on — the first several turns of a long agentic session are the ones repeated, unmodified, on every subsequent call. A common pattern is to move the breakpoint forward as the conversation grows, so the cached prefix always covers everything except the most recent one or two turns. Getting this wrong — leaving the breakpoint at its original position from turn one as the conversation grows past it — still caches something, just a shrinking fraction of an ever-larger request, which quietly erodes the savings the technique is supposed to provide.
Caching interacts with tools and system content too
A cache breakpoint isn't limited to the system block — it can sit on the last block of a tools array, on a document block, or on any content block in the message history. Because caching matches an exact prefix, the entire preceding structure of the request counts, including tool definitions: if your application sometimes sends a request with three tools and sometimes with four (say, a feature flag toggling one tool on or off), those are two different prefixes as far as the cache is concerned, and traffic split between them halves the effective cache hit rate for each variant. Keeping tool definitions stable and ordered identically across calls is part of getting real caching benefit in practice, not just an implementation detail.
The premium-to-discount trade
Writing to the cache costs more per token than an ordinary input token would — the first call that establishes a cache entry is more expensive than the same call without caching at all. The economics only work out because a cache write is meant to be read many times afterward at the steep discount; a cache breakpoint on content that will realistically only be sent once (a one-off request with no expected repeat) is a net loss, not a savings. The technique pays off specifically under repetition — the same stable prefix reused across several calls in quick succession — which is the scenario worth checking for before adding a breakpoint at all.