An enterprise platform processes 50,000 API requests per day to Claude. The engineering team discovers that 35% of these requests have identical system prompts (10,000 tokens each) combined with unique user messages (500-2,000 tokens each). Without caching, the monthly bill is $180,000. The team implements prompt caching using cache_control with type: 'ephemeral' on the system prompt. However, after implementation, they observe only a 12% cost reduction instead of the expected ~70% reduction. Which root cause is MOST likely responsible for this underperformance?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Here's the deal — the most likely root cause for a 12% actual vs. ~70% expected cache savings is dynamic content injection into the supposedly 'static' system prompt.
Full explanation below image
Full Explanation
The most likely root cause for a 12% actual vs. ~70% expected cache savings is dynamic content injection into the supposedly 'static' system prompt. Claude's prompt cache key is computed from the exact byte sequence of the cached prefix. If the engineering team's code injects anything variable — a request timestamp, session ID, user tier, dynamic date reference — into the system prompt before the user message, every request generates a unique cache key and results in a cache miss. The 35% of requests with 'identical' system prompts may in practice not be byte-identical. Option B is plausible but assumes all requests are spaced more than 5 minutes apart — at 50,000 requests/day for a 35% overlap group, the inter-request interval for the repeated system prompt is likely under 5 minutes. Option A describes a configuration mistake that would produce 0% savings, not 12%. Option C misidentifies the threshold issue — 10,000 tokens is well above the minimum cacheable size — and the 'last block' placement issue would cause cache misses, not partial savings.