What invalidates the Claude prompt cache

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. Your support application keeps its tool definitions in the request for prompt-cache stability, but during a maintenance window the backing services are offline and Claude must answer from context alone without calling anything. Which approach should you take?

   Right. In the game that’s Renown for your Tool Design, MCP and Server Tools building.

   Not that one: D is right. In the game your Tool Design, MCP and Server Tools building would lose a little Renown, and this question would come back later.

   Your answerA.Set disable_parallel_tool_use to true inside the tool_choice object.disable_parallel_tool_use: true limits Claude to one tool_use block per turn. One call is still a call, which the maintenance window rules out.Your answerB.Remove the tools array from the request for the duration of the window.Removing tools does stop tool calls, but the tools block is the first element of the cached prefix. Changing it invalidates the whole cache, and restoring it afterwards invalidates it again.Your answerC.Set defer_loading to true on every tool declared in the request.defer_loading keeps definitions out of the prompt until the tool search tool surfaces them. Setting it on every tool leaves nothing loaded and returns 400 with "All tools have defer_loading set".The answerD.Set tool_choice to {"type": "none"} and leave the tools array unchanged.tool_choice: {"type": "none"} prevents Claude from calling any declared tool while the definitions stay in the request. Because tools is unchanged, the cached prefix survives; only the messages portion is affected by the tool_choice change.

   Written from platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools

2. Your team relies on prompt caching to keep a large shared system prompt affordable and wants an alert that fires when the cache silently stops being hit — for example after an unnoticed change inside the cached prefix. The alert must key on a field the API already returns on every response. Which approach should you take?

   Right. In the game that’s Renown for your Context Management and Reliability building.

   Not that one: B is right. In the game your Context Management and Reliability building would lose a little Renown, and this question would come back later.

   Your answerA.Alert on input_tokens, which reports the full prompt size and therefore falls whenever a cached prefix is being used on a request.input_tokens reports only the tokens after the last cache breakpoint, not the whole prompt. It stays roughly constant whether the prefix hits or misses, which makes it useless as a cache-health signal.The answerB.Alert when cache_read_input_tokens drops to zero on every request, the sign that the cached prefix is being invalidated.cache_read_input_tokens is the direct measure of a cache hit.Your answerC.Alert when cache_creation_input_tokens falls to zero, which happens once the cache is being served correctly.Cache creation is the write side. A prefix that is invalidated on every request is rewritten on every request, so cache_creation_input_tokens stays high in exactly the failure mode being alerted on — the opposite of the stated behaviour.Your answerD.Alert on usage.speed, which reports fast for as long as a cached prefix is serving the request.usage.speed reports which speed setting the request ran under, distinguishing standard from fast mode on the models where fast mode is available. It is unrelated to prompt caching.

   Show the full explanation and doc quotes

   A prefix that is silently invalidated — by a timestamp, a per-request id or a reordered tool list — produces repeated writes and no reads, so the field sitting at zero across successive requests is the canonical diagnostic.

   Written from platform.claude.com/docs/en/build-with-claude/prompt-caching

3. Your platform team runs a retrieval-augmented assistant on Claude Opus 5 (claude-opus-5). Every request assembles the retrieved chunks for the current question first, then a 40,000-token frozen policy prompt, and places a single cache_control breakpoint at the end of the policy text. The corpus rarely changes, yet usage.cache_read_input_tokens is zero on every request. What is the most likely cause?

   Right. In the game that’s Renown for your Prompt Engineering, Structured Output and Retrieval building.

   Not that one: A is right. In the game your Prompt Engineering, Structured Output and Retrieval building would lose a little Renown, and this question would come back later.

   The answerA.The volatile retrieved chunks sit inside the cached prefix, so the prefix differs on every request and never matches.Prompt caching is an exact prefix match over the rendered request in the order tools → system → messages. Everything before the breakpoint must be byte-identical across requests.Your answerB.The 40,000-token prefix exceeds the maximum cacheable prefix, so the breakpoint is dropped and nothing is written.Prompt caching enforces a minimum, not a maximum: on Claude Opus 5 a prefix shorter than 512 tokens silently fails to cache. A 40,000-token prefix is comfortably cacheable, and large prefixes are exactly the case caching exists for.Your answerC.The default 5-minute TTL expires between requests, so each request writes a new entry rather than reading one.An expired 5-minute entry causes a miss on the next request, after which that request writes a fresh entry that subsequent requests read. Continuous traffic would therefore show non-zero cache_read_input_tokens some of the time. A permanent zero points at a prefix that never repeats.Your answerD.Cache reads are not reported for content in the system field, so the counter stays at zero despite real hits.The usage counters do not distinguish levels. Cached blocks in tools, system, or messages all report through cache_read_input_tokens and cache_creation_input_tokens, so a zero read count means no cache hit occurred.

   Show the full explanation and doc quotes

   Putting per-question retrieved chunks ahead of the frozen policy text places volatile content inside the cached prefix, so no two requests share a prefix and the cache never hits. The fix is to order stable content first and let volatile content fall after the last breakpoint.

   Written from platform.claude.com/docs/en/build-with-claude/prompt-caching