Claude Prompt Caching: Cut Cost and Latency
Founder of Goodspeed
Prompt caching is one of those features that sounds like a minor optimisation and turns out to change the economics of an entire product. If your application sends Claude the same large chunk of context over and over, caching lets you pay to process it once and then read it back cheaply on every call after that. For the right workload the saving is enormous and the latency drop is a welcome bonus.
At Goodspeed we build production AI on Claude, and prompt caching is one of the first things we reach for when a system starts to scale. It is not exotic and it is not risky. It is a well understood lever that most teams simply have not switched on yet.
This guide explains what caching is, how it works, what to cache, how to structure prompts to exploit it, and how to measure the savings so you know it is actually paying off.
What prompt caching actually is
Prompt caching lets you tell Claude that a portion of your prompt is stable and worth remembering. Normally the model processes every token of your input from scratch on every request. With caching, you mark a prefix of the prompt as cacheable, Claude processes it once and stores the internal representation, and subsequent requests that share that exact prefix reuse the stored work instead of redoing it.
The effect is that repeated context becomes both cheaper and faster. You are no longer paying full price to re read the same system prompt or the same document on every single call. Think of it as memoisation for prompts. The expensive computation happens once, and everyone who sends the same opening context afterwards rides on that first investment.
How it works under the bonnet
You mark cache breakpoints in your request at the end of the content you want to reuse. The first time Claude sees that content it performs a cache write, which costs slightly more than a normal input token because it is doing the extra work of storing the representation. Every later request that begins with the identical content performs a cache read instead, billed at a small fraction of the normal input rate.
Cached content lives for a short window, refreshed each time it is used, so an active system keeps its cache warm continuously. If the window lapses, the next call simply writes it again. The mechanics are forgiving. You do not manage keys or eviction yourself. You just declare what is stable and Claude handles the rest.
Write once, read many times
The economics only make sense when reads heavily outnumber writes. A single cache write followed by one read is not worth it, because the write carries a premium. But a write followed by hundreds or thousands of reads is transformational, because each of those reads costs a sliver of the full rate.
This is why caching suits high traffic production systems rather than one off scripts. A customer support assistant answering thousands of questions against the same knowledge base, an agent working through a large codebase, or a document tool that repeatedly references the same policy set all fit the pattern perfectly. The more you reuse the cached prefix, the closer your effective input cost drifts towards almost nothing.
What you should cache
The best caching candidates are large and stable. System prompts that carry detailed instructions, tone guidance and formatting rules are ideal because they rarely change and go out on every call. Reference documents such as policies, product catalogues, legal terms and style guides are next. So are codebases and schemas when you are building developer tools that reason over the same files repeatedly.
Few shot examples are another strong candidate. If you steer the model with a set of worked examples, those examples are constant across requests and often run to thousands of tokens. Cache them and you keep the quality benefit of rich prompting without paying for it on every call. The test is always the same. Is this content large, is it stable, and do you send it more than once.
What you should not cache
Caching only helps content that repeats byte for byte. The user's actual question, the retrieved passages that change per query, timestamps, session identifiers and anything else that varies from call to call should never sit inside the cached region. If variable content creeps into the cached prefix, the prefix stops matching and you lose the benefit entirely.
There is also a size floor. Very small blocks are not worth caching because the write premium outweighs the saving. Caching a two line instruction gains you nothing. Reserve it for substantial blocks where the reuse clearly pays back the write cost, and leave the small, fast changing pieces to be processed normally.
Structure your prompts for caching
Caching rewards a specific prompt layout. Put your stable content first and your variable content last. The cache works on a shared prefix, so everything up to the breakpoint must be identical across requests. Lead with the system prompt, then the reference documents, then the examples, and only then append the retrieved context and the user's message.
This is a small discipline with a large payoff. Many teams build prompts in whatever order feels natural and unknowingly interleave stable and variable content, which makes caching useless. Reordering so the constant material sits at the top, behind a single breakpoint, is often the only change needed to unlock the whole benefit. We design client prompts this way from the outset so the cache is effective by construction.
Handling multiple cache breakpoints
You can place more than one cache breakpoint, which is useful when different parts of your context change at different rates. A system prompt almost never changes, a product catalogue might update daily, and a user profile changes per session. By nesting breakpoints from most stable to least stable, you let the model reuse as much as possible even when the outer layers shift.
The principle is to order content by how often it changes, most stable first. When the catalogue updates, only the portion after that breakpoint needs rewriting, and the system prompt above it stays cached. This layered approach squeezes the most value out of caching in systems where context is not uniformly static, which describes most real applications.
The latency benefit
Cost is the headline, but caching also makes responses faster. Processing a large prefix from scratch takes time, and that time is added to every request. When the prefix is cached, the model skips that work and starts generating sooner, which cuts time to first token noticeably on prompts with heavy static context.
For interactive products this matters as much as the money. A support chat that references a big knowledge base feels sluggish if it re reads that base every time. With caching it feels snappy, because the expensive part is already done. You get a cheaper and faster system from the same change, which is a rare combination and one worth taking whenever it is on offer.
Measuring your savings
Every Claude response reports how many tokens were cache writes, cache reads and ordinary input. Log those figures and you can see exactly how well caching is working. A healthy production system shows cache reads dominating, with writes as a small fraction, which tells you the cache is being reused as intended.
Turn those counts into money by applying the respective rates, and compare against what the same traffic would have cost with no caching. The gap is your saving. If reads are not dominating, something is wrong, usually variable content leaking into the cached prefix or a prompt order that breaks the shared prefix. Measurement is how you confirm the theory is holding in practice rather than assuming it is.
Common caching mistakes
The most frequent error is putting variable content ahead of stable content, which prevents the prefix from ever matching. The second is caching blocks too small to justify the write premium. The third is expecting a benefit from content that is genuinely sent only once, where caching adds cost rather than removing it.
Another subtle trap is letting the cached content drift. If your system prompt is regenerated with a timestamp or a slightly different whitespace layout each time, the cache never matches even though the meaning is identical. Keep the cached region byte stable. When we review a client system that is not seeing the savings it should, the cause is almost always one of these, and each is a quick fix once you know to look.
When caching changes the architecture
Once caching is on the table, it influences how you design the whole system. It makes rich system prompts and generous few shot examples affordable, because you only pay for them once. It pairs naturally with retrieval, where you cache the stable instructions and schema and retrieve only the variable passages. It also shapes how you batch traffic, since keeping a cache warm rewards steady throughput over sporadic bursts.
In other words caching is not a switch you flip at the end. It is a design assumption that lets you build a more capable and more affordable product at the same time. Teams that treat it as a first class concern end up with systems that are both smarter and cheaper than they would otherwise dare to build.
Cache the context, cut the bill
Prompt caching turns repeated context from a recurring tax into a one off cost. Cache the stable material, keep the variable material out of the cached region, order your prompt so the constant content sits first, and measure the read to write ratio to confirm it is working. Do that and you get a system that is cheaper to run and faster to respond, from a single well understood change.
The workloads that benefit most are exactly the ones worth building well, high traffic assistants, document tools and coding agents that lean on the same context again and again. If you want a team that builds production AI on Claude, see our AI work, or book a free call with our Claude team.
Written By
Founder of Goodspeed