Prompt caching matches a prefix. Everything static must sit ahead of everything variable, and a single early change invalidates the rest. Build it, verify with usage numbers, then break it on purpose.
What to build
- Assemble a large stable prefix: system prompt, tool schemas, reference material.
- Place a cache breakpoint after the stable region and before the variable input.
- Run twice and read the cache creation and cache read token counts in the usage field.
- Now change one character near the start of the prefix and re-run.
- Observe the full invalidation and confirm you can explain it from prefix matching.
- Reorder so a genuinely variable element (a timestamp) is no longer inside the cached region.
Done when
- You can show cache read tokens greater than zero on the second call.
- You have measured, not assumed, the cost difference.
- You caused a full invalidation deliberately and can explain the mechanism.
- Nothing that changes per request sits inside the cached prefix.
If you want to go further
- Use several breakpoints for a prompt with layers that change at different rates.
The trap this exercise teaches
Putting a timestamp, session id or user name at the top of the system prompt. It invalidates the entire cache on every call and the cost looks inexplicably high.
Before you start
The theory behind this build is covered in Prompt caching mechanics. If any step below is unfamiliar, read that first — the exercise assumes it. Primary source: Claude Docs — Prompt caching.
Check yourself against the exam
This exercise sits in Domain 5, which is 15% of the CCAR‑F exam. Once you have built it, run a domain drill in the study app and see whether the questions read differently.