Claude prompt caching: cache_control, TTL and pricing

Try 3 questions on this

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

1. Your team logs usage.input_tokens from every response and treats it as the total input size of the request. Against a 200,000-token cached document plus a short question, the logged figure is about 50 tokens, and your team's context-growth dashboard reads near zero. Which approach should you take to compute total input tokens from the usage object?

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

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

   The answerA.Sum input_tokens, cache_creation_input_tokens and cache_read_input_tokens.input_tokens reports only the tokens that appear after the last cache breakpoint, so with a large cached prefix it is much smaller than the request. Total input is cache_read_input_tokens + cache_creation_input_tokens + input_tokens.Your answerB.Multiply input_tokens by the number of cache breakpoints set on the request.Breakpoints segment the prefix for caching. They do not scale the token count, and the number of them has no arithmetic relationship to request size.Your answerC.Add input_tokens to output_tokens and subtract any cached token counts.output_tokens measures generation, not input. Cached input tokens are part of the input total and must be added, not subtracted.Your answerD.Read input_tokens alone; cached tokens are reported in a separate response body.Cached token counts are reported in the same usage object, as cache_read_input_tokens and cache_creation_input_tokens. There is no second response body.

   Written from platform.claude.com/docs/en/api/rate-limits

2. You batch 30,000 requests that all share a 60,000-token reference corpus, marked with a default cache_control breakpoint. The batch takes about forty minutes to work through, and the observed cache hit rate is far lower than expected. What change would most effectively improve the hit rate?

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

   Not that one: D 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.Split the corpus across four breakpoints so more of its prefixes can matchSplitting one stable corpus across several breakpoints does not extend any entry's lifetime. All of them still expire on the same five-minute clock.Your answerB.Submit the batch in blocks of 1,000 requests and poll between the blocksChunking the submission changes the shape of the work, not the cache TTL. Each block still faces entries that expire five minutes after the previous write.Your answerC.Send a synchronous max_tokens: 0 warming request inside the batch firstmax_tokens: 0 is explicitly unsupported inside a batch, precisely because an ephemeral entry written during batch processing would likely expire before the follow-up request ran.The answerD.Set cache_control: {"type": "ephemeral", "ttl": "1h"} on the corpusThe default cache lifetime is five minutes, and a batch that runs for forty minutes will repeatedly outlive its own entries. A one-hour TTL keeps the shared corpus resident for the whole run, at a 2x write multiplier paid once instead of many 1.25x writes.

   Written from platform.claude.com/docs/en/build-with-claude/batch-processing

3. You design the prompt layout for a multi-tenant assistant on Claude Opus 5 (claude-opus-5). Each request carries a frozen 8,000-token instruction set, a per-tenant style guide that changes weekly, and the user's question. Your design must maximize prompt-cache reuse across tenants. Which approach should you take to order these segments and meet these requirements?

   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.Frozen instructions first, then the tenant style guide, then the user question, with breakpoints after the first two.Prompt caching matches on an exact prefix, so content must be ordered from most stable to most volatile with breakpoints at the boundaries.Your answerB.Tenant style guide first, then frozen instructions, then the user question, with breakpoints after the first two.Because invalidation cascades forward from the point of change, putting the weekly style guide first means each weekly edit invalidates the 8,000 frozen tokens behind it — and no two tenants share a prefix at all.Your answerC.User question first, then frozen instructions, then the tenant style guide, with a breakpoint after the question.The user question changes on every single request. Anything placed after it can never match a cached prefix, so this layout guarantees a zero hit rate on both the instructions and the style guide.Your answerD.Frozen instructions first, then user question, then the tenant style guide, with a breakpoint after the question.The style guide changes weekly while the question changes every request. Ordering them this way traps the more stable block behind the more volatile one, so the style guide is re-written into the cache constantly.

   Show the full explanation and doc quotes

   Frozen instructions first give every tenant a shared cached prefix; the weekly style guide forms a second, per-tenant layer; the question comes last, after the final breakpoint, where it invalidates nothing.

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