- In short
- Prompt caching matches on a stable prefix: the leading portion of a request that is identical across calls. A cache breakpoint marks where the stable, cacheable portion of a prompt ends. Caching reduces cost and latency only on the portion of the prompt that is byte-identical to a previously cached prefix, so a small change anywhere in the supposed stable prefix prevents the hit.
Caching is a prefix match, not a content match
Prompt caching can cut both cost and latency, but only if you understand precisely what it matches on. The Claude Certified Architect - Professional (CCAR-P) exam sets this up at the understand level: caching matches on a stable prefix, meaning the leading portion of a request that is identical across calls. It does not scan the whole request for repeated content and cache whatever recurs. It looks at the front of the request and reuses the leading portion that is byte-identical to something it cached before. That distinction, prefix match versus content match, is the entire mechanism, and getting it wrong is why so many caches quietly fail to save anything.
- Prompt caching prefix matching
- A cost and latency optimisation that reuses the leading portion of a request, the stable prefix, when it is byte-identical to a previously cached prefix. A cache breakpoint marks where the stable, cacheable portion ends; content after it is variable. Only the identical leading portion is served from cache, so any change within the supposed stable prefix prevents the hit.
The stable prefix
The stable prefix is the leading portion of a request that stays the same from call to call: typically a large fixed instruction block, a system prompt, or reference material that every request shares. Caching works by recognising that this leading portion has been seen before and reusing it rather than reprocessing it. The key word is leading. Caching operates from the front of the request forward, matching as far as the content stays identical, and stopping the moment it diverges. It is not enough for content to be repeated somewhere; it has to be at the front and byte-identical to earn a hit.
The cache breakpoint
A cache breakpoint marks where the stable, cacheable portion of a prompt ends. Everything up to the breakpoint is the prefix you are declaring as cacheable; everything after it is treated as the variable, per-request content. Placing the breakpoint correctly is how you tell the system which leading portion to cache. It belongs at the boundary between the fixed content that repeats across calls and the dynamic content that changes each time. Get the breakpoint placement right and the large fixed block is cached; get it wrong, or let dynamic content creep in ahead of it, and the prefix stops being stable. The ordering discipline that keeps the prefix intact is the subject of content ordering for cache hit rate.
Byte-identical or nothing
Caching reduces cost and latency only on the portion of the prompt that is byte-identical to a previously cached prefix. This is strict. If even a small part of the supposed stable prefix changes between calls, the prefix is no longer identical from that point on, and the cache cannot hit past the change. There is no partial credit for "almost the same." A stray timestamp, a reordered line, or a per-request value that sneaked into the prefix all break the match. This strictness is why the mechanism rewards deliberate design: you have to keep the leading portion genuinely constant for the cache to do anything at all.
What the exam trips candidates on
The two traps target the content-match misunderstanding. The first is assuming any repeated content anywhere in a request will be cached regardless of its position. A scenario will repeat a block in the middle or end of requests and expect a hit; the credited reading notes caching matches the leading prefix, so position matters. The second is expecting a cache hit when even a small part of the supposed stable prefix changes between calls. A scenario will introduce a minor early variation and still expect caching to save; the credited reading knows byte-identical means the change breaks the hit.
Worked example
A team caches a large reference document that appears in every request, but they place a per-request request ID at the very top of the prompt, above the document, and they see no cache savings. They also occasionally reword one line of the document. Explain both problems.
Both problems come from misunderstanding that caching matches a leading, byte-identical prefix.
The request ID at the very top is fatal on its own. Caching matches from the front of the request forward, and the first thing it encounters is a value that changes on every call. Because the leading content diverges immediately, the stable prefix effectively has zero length; there is nothing byte-identical at the front to match, so the large reference document below it is never cached even though it is repeated in every request. This is the first trap exactly: the content is repeated, but its position is wrong. The fix is to move the per-request ID after the fixed document, so the document becomes the leading stable prefix and the breakpoint sits between it and the ID.
Occasionally rewording one line of the document is the second problem. Even with the ID moved, if the document itself is not byte-identical across calls, the prefix diverges at the reworded line, and caching cannot hit past that point. A single changed line breaks the match from that line onward. To cache reliably, the fixed block has to stay genuinely constant; edits to it should be treated as prefix-invalidating changes, not casual tweaks.
Together the fixes restore a real stable prefix: a constant document at the front, a correctly placed breakpoint, and the variable request ID after it, so caching actually reuses the leading portion it is designed to.
Common misreadings to avoid
Misconception
Any content repeated across requests will be cached wherever it appears.
What's actually true
Misconception
A cache will still hit if only a small part of the stable prefix changes.
What's actually true
How this shows up on the exam
Understand-level questions describe a caching setup and ask why it does or does not hit. The reliable answer applies prefix matching: caching reuses the leading, byte-identical portion up to the breakpoint, so repeated content in the wrong position or any change within the prefix prevents the saving.
This knowledge point is the mechanism behind content ordering for cache hit rate, which turns it into a design rule, and behind modeling cache economics and TTL tradeoffs, which decides when caching is worth doing at all. It rests on the token-measured context window, since the cached prefix is measured in the same tokens.
A team caches a large reference document present in every request but places a per-request request ID at the very top of the prompt, above the document. They see no cache savings. Why?
People also ask
How does prompt caching decide what to cache?
What is a cache breakpoint?
Why did my prompt cache not hit?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.