Prompt caching raised my bill — the write premium I missed

Enabling prompt caching on a running agent should cut costs, but the next invoice went up instead. The overlooked detail: cache reads are billed at roughly 0.1x the input rate, but cache writes carry a premium of about 1.25x. A timestamp buried in the system prompt was regenerated on every call, making the 'stable' prefix different each time — so every call wrote a fresh cache entry and none were ever read back. Only the expensive half of caching was active.

The usage response made this visible the whole time: cache_creation_input_tokens climbing while cache_read_input_tokens stayed at zero is the exact signature of a broken prefix. The fix isn't more caching, it's discipline — static content (system prompt, tool schemas, documents) must sit first and stay byte-identical across calls, while anything dynamic (timestamps, user turns, request IDs) belongs after the cache breakpoint.

The broader lesson for engineers: caching is amortization, not a free discount. It pays off in agent/tool loops, long-document Q&A, and bulk extraction where a large prefix is read many times — but a single unstable character anywhere in that prefix means you pay the write premium and never recoup it. Teams routing through API gateways face an added risk: some proxies silently reorder fields or strip cache_control, breaking cache matching with no error message. The only reliable check is sending the same request twice and confirming cache_read_input_tokens is nonzero on the second call.