My first enrichment job at any scale sent the same four-thousand-token preamble on every single call: the system prompt, the product one-pager, the scoring rubric, all of it, re-transmitted and re-processed two thousand times for two thousand leads. I was paying, in full, to make Claude re-read the same page two thousand times. The leads were the only thing that changed, and they were the smallest part of each request.
Prompt caching is the fix for exactly that waste. It lets Claude hold onto the stable front of your prompt and reuse it, so you pay full freight for the preamble once and a fraction thereafter. This guide is how it works, what to cache, and the one mistake that silently turns caching off without you noticing.
What prompt caching is
Every API call processes your whole prompt from the top. When many of your calls begin with the same large block, that repeated processing is pure waste, you are paying to handle identical text over and over. Prompt caching lets Claude store that repeated front section and reuse it, so subsequent calls skip re-processing it and are billed at a steep discount for that part.
The mental model is a prepared workspace. Instead of setting up the same background, your docs, your rules, your tools, from scratch for every task, you set it up once, and each new task starts from the ready workspace. The setup cost is paid a single time and amortized across everything that follows.
How prefix caching works
Caching works on the prefix, the run of content at the start of your prompt, up to the point where things start changing. You mark where the stable part ends, and Claude caches everything up to that mark. On the next call, if that prefix is identical, Claude reuses the cached version and only does full work on what comes after.
That prefix-based design is the whole key to using it well, and to breaking it by accident. The cache matches on the exact, in-order content of the prefix. Keep it identical and you get the hit; alter even a little of it, or reorder it, and the match fails and you are back to full price. Everything else about caching follows from that one fact.
What to cache
Cache the big things that do not change between calls. The system prompt is the obvious first candidate, especially a rich one carrying your voice rules and role. Tool definitions are another, they are often large and identical across an agent's calls. And the biggest win is usually reference material: a product doc, a knowledge base, a long transcript that many questions run against.
The pattern to aim for is heavy-and-stable in front, light-and-changing at the back. Put everything that stays the same at the top of the prompt so it can all sit inside one cached prefix, and keep the per-call variable, the specific lead, the specific question, at the end. The more you can pull into the stable front, the more each call saves.
- The system prompt, especially a detailed one with your rules and voice.
- Tool definitions, which are often large and identical across an agent's calls.
- Long reference material: product docs, a knowledge base, a big transcript.
- Anything that repeats unchanged across many calls in the same job.
How to turn it on
You enable caching by marking a cache breakpoint at the end of the stable section, telling the API cache everything up to here. Structure the prompt so that mark falls after all your unchanging content and before the part that varies. The how-to below shows the shape; the SDK exposes it as a small addition to the blocks you already send.
The discipline is in the ordering, not the syntax. Enabling caching is a one-line change; getting a hit is about making sure the content before your breakpoint is genuinely identical from call to call. Build the prompt so the stable part is assembled the same way every time, and the caching takes care of itself.
The cache is fragile on purpose
Because it matches on an exact prefix, caching is easy to break without realizing it. Slip a timestamp into the system prompt, reorder your tool definitions, personalize a line at the top with the recipient's name, and the prefix differs on every call, so it never matches and you cache nothing while thinking you do. The bill looks the same as no caching, which is why this hides.
The habit that avoids it: keep everything dynamic strictly after the cache breakpoint. If a value changes per call, it belongs in the variable tail, not the stable head, no matter how small it is. One personalized word at the top of a four-thousand-token prefix throws away the entire cache for that call.
TipCheck the usage on your calls for cache-read tokens. If they are zero when you expected hits, something in your prefix is changing every call, hunt for the dynamic value that slipped above the breakpoint.
The cost and latency math
The savings scale with two things: how big your stable prefix is, and how many calls share it. A small preamble on a handful of calls is not worth caching. A four-thousand-token preamble across two thousand calls is enormous, because you go from paying full input price two thousand times to paying it roughly once and a fraction after. That is the shape of my enrichment job, and it is where caching turns a real bill into a small one.
Latency drops for the same reason. Skipping the re-processing of a large prefix means responses start sooner, which matters when the preamble is heavy. So caching is not only cheaper, it is faster, and both effects grow with the size of what you cache and the number of times you reuse it.
One more number worth internalizing: the discount applies to the cached portion, so the win is proportional to how much of your prompt is stable. If ninety percent of every request is a fixed preamble, caching addresses ninety percent of your input cost. If only a tenth is stable, the ceiling on savings is smaller. Look at your prompt and ask what fraction never changes, because that fraction is your opportunity.
Caching across an agent loop
Agents are a natural home for caching, because an agentic loop makes many calls that all share the same front matter: the same system prompt, the same tool definitions, turn after turn. Cache that stable head once and every iteration reads it cheaply instead of re-paying for the tool definitions on every step. On a long loop, that is a large share of the cost simply gone.
The catch is the usual one: the growing conversation is the changing part, so it sits after the cached prefix while the system prompt and tools stay pinned at the front. Structure the loop's requests that way and caching quietly turns an expensive multi-step agent into an affordable one, which for GTM research agents running over many accounts is the difference between shipping it and shelving it.
Where it goes wrong
The headline mistake is the silently-changing prefix, covered above, and it is worth stating twice because it is invisible: you pay for caching setup and get no hits, which is the worst of both. The second is expecting the cache to last. A cached prefix lives for a limited time, so caching helps within a run or a burst of activity, not across a quiet afternoon between jobs.
The third is caching when there is nothing to gain, tiny prompts, or calls that share nothing. Caching has a small overhead to set up the stored prefix, so on prompts that are already small or never repeat, it is not worth the bother. Reach for it when the preamble is heavy and reused, and skip it otherwise.
- A prefix that changes every call, so you pay setup and get zero hits.
- Assuming the cache persists for hours; it has a limited lifetime, best within a run or burst.
- Caching tiny or non-repeating prompts, where the setup overhead outweighs the gain.
- Not checking cache-read usage, so a broken cache goes unnoticed on the bill.
The GTM version
Prompt caching is the difference between a scaled GTM automation that is affordable and one that is not. Any job where the same heavy context rides along on every call is a caching candidate: enrichment that sends your product docs each time, scoring that carries a long rubric, a support assistant grounded in the same knowledge base across thousands of chats. Cache the shared context once and each call pays for only the part that is actually new.
The reframe that stuck with me: stop paying to re-read the same page. If your automation sends the same preamble on every call, you are re-buying knowledge Claude just had a moment ago. Which of your jobs re-sends the same big block of context on every single call?
How to set it up
Put the stable content first
Assemble the prompt so everything unchanging, system prompt, tool definitions, reference docs, sits at the top, and the per-call variable sits at the bottom. Caching only helps if the front is identical across calls.
Mark a cache breakpoint
Tell the API to cache everything up to the end of the stable section:
TipKeep every dynamic value, names, dates, the specific lead, strictly after the breakpoint. One personalized word above it loses the whole cache for that call.
Reuse it across the run
Make the rest of your calls in the same job with the identical prefix. The first pays to build the cache; the rest read from it at a fraction of the price and start faster.
Verify you are getting hits
Read the usage block for cache-read tokens. If they are zero when you expected reuse, something in the prefix is changing every call, and the cache is silently doing nothing.
Frequently asked questions
What is prompt caching?
A feature that lets Claude reuse the stable front of your prompt across calls instead of re-processing it each time. Repeated calls that share the cached prefix are much cheaper and faster on that part.
What should I cache?
The big, unchanging content: your system prompt, tool definitions, and long reference documents. Put all of it at the front so it fits in one cached prefix, and keep per-call content at the end.
Why is my cache not working?
Almost always because something in the prefix changes every call, a timestamp, a name, reordered tools. The cache matches an exact prefix, so any variation before your breakpoint means no hit. Move dynamic values after it.
How long does a cached prefix last?
A limited time, so caching helps within a run or a burst of activity rather than across idle hours. Check the docs for the current lifetime and any extended options.
How do I know caching is actually happening?
Read the usage block for cache-read token counts. If they are above zero on calls that share a prefix, you are getting hits; if they are zero, the cache is broken.
When is caching not worth it?
On small prompts or calls that share nothing, where the setup overhead outweighs the gain. Reach for it when a heavy preamble is reused across many calls, and skip it otherwise.
How much does it save?
It scales with the size of the cached prefix and how many calls reuse it. A large preamble across thousands of calls turns full-price re-processing into paying once plus a fraction, which is a major cut.
What GTM jobs benefit most?
Anything that sends the same heavy context on every call: enrichment carrying product docs, scoring with a long rubric, a grounded assistant across thousands of chats. Cache the shared context once and pay only for the new part.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.