A developer marks a `cache_control` breakpoint on a large, static system prompt sent with every request to Anthropic's Messages API. According to Anthropic's documentation, how does this affect billing across the first request and later requests that reuse the same cached prefix?
- the first request's cache-write tokens are billed at a discount below the base input-token rate, while every later request that hits the same cache is billed at a premium above the base rate, since maintaining a cache costs more than reading fresh input
- cache writes and cache hits are always billed at exactly the same per-token rate as ordinary, uncached input tokens, so prompt caching only ever provides a latency benefit and never a cost benefit
- the first request that establishes the cache is billed at a premium above the base input-token rate for the cached portion, since writing a new cache entry costs more, while later requests whose prefix hash matches that cached entry are billed at a steep discount for the reused portion, which is where the overall cost savings come from
- prompt caching only ever reduces the cost of output tokens, never input tokens, because it works by shortening how much text the model generates in its response rather than by reusing previously processed input
Why C? And why not the others?
Correct answer: C. the first request that establishes the cache is billed at a premium above the base input-token rate for the cached portion, since writing a new cache entry costs more, while later requests whose prefix hash matches that cached entry are billed at a steep discount for the reused portion, which is where the overall cost savings come from
Anthropic's documented pricing structure charges a premium multiplier, above the base input-token rate, for tokens written into a new cache entry on a cache miss, and a steep discount, well below the base rate, for tokens read from a matching cache entry on a subsequent cache hit -- so the first request that establishes the cache actually costs more than an equivalent uncached request, and the savings only materialize on later requests whose prefix hash matches what was already cached. The option reversing which side is discounted and which is a premium gets the direction backwards relative to the documented pricing tiers. The option claiming no price difference exists ignores the documented multiplier structure entirely and would leave a developer unable to explain why caching is recommended as a cost-saving feature at all. The option tying caching to output-token cost is wrong because prompt caching operates entirely on the input side, reusing previously processed prompt content, and has no mechanism for shortening generated output.
Source: Anthropic, Prompt caching documentation, https://platform.claude.com/docs/en/build-with-claude/prompt-caching