Domain 5 · 15%% of exam

Prompt caching mechanics

One invariant explains every caching question on the exam.

5 min read · Lesson 1 of 9 in this domain

Almost everything about prompt caching follows from one mechanical fact: the cache key is the exact bytes of the prompt up to each breakpoint, so a match is a prefix match. Change one character anywhere in that prefix and everything after it is invalidated, because the cached state was computed against bytes that no longer exist. This is why render order matters — tools, then system, then messages — and why tool definitions are the most destructive thing to change: they sit at position zero, so touching them invalidates the lot. Stable content first, volatile content last, is not a style preference but a direct consequence.

Key points

Caching is a prefix match. Any byte change anywhere in the prefix invalidates everything after it. Everything else follows from this.
Render order is tools → system → messages. Tools sit at position zero, which is why changing one invalidates the whole cache.
A breakpoint on the last system block therefore caches tools and system together.
Maximum 4 cache_control breakpoints per request. They can sit on any content block — system text, tool definitions, message text, images, tool results, documents.
Place breakpoints at stability boundaries: end of the shared prefix, not the end of the whole prompt. Marking the end of a varying prompt writes a distinct entry every time and never reads.
A fork (summarisation, sub-agent) must copy the parent's system, tools and model verbatim and append only fork-specific content. Semantic equivalence is irrelevant — bytes are compared.

Diagram

The prefix and the breakpoint

Worked example

One line that costs you every cache hit. Your system prompt opens with f"Today is {datetime.now()}". Every request now has a unique prefix from its very first line, so nothing after it can ever be reused — you pay the write premium on every call and read nothing back. The tell is cache_read_input_tokens sitting at zero across requests that ought to be identical. Move the timestamp into the user message, after the last breakpoint, and the entire system prompt becomes cacheable again.

Exam trap

"The prompt is basically the same" is not a caching argument. Bytes, not meaning.

Check your understanding

Why does changing one tool definition invalidate the whole cache?

Correct answer: A — Tools render first, at position zero of the prefix
Caching is a prefix match, so a change at position zero invalidates everything after it.

What is the render order for cache purposes?

Correct answer: B — tools → system → messages
This is why a breakpoint on the last system block caches tools and system together.

Practise this domain with 15%%-weighted questions in the study app.

Open in study app

Cache economics and verification

Source: Claude Docs — Prompt caching · Independent study aid, not affiliated with or endorsed by Anthropic.