Prompt caching, when it saves money and when it costs more

Prompt caching is one of the few cost levers that can move a model bill by a large fraction without changing a line of application logic. The idea is simple: the stable part of your request — a long system prompt, a document, a fixed set of instructions — gets stored on the provider's side, so repeated calls that share that prefix don't pay full price to process it again.

The catch is that caching is not free by default. A cache write usually costs more than an ordinary token; a cache read costs much less. You come out ahead only when reads outnumber writes, and that depends entirely on details you control: whether the cached prefix is byte-stable across calls, whether anything unique is prepended to the front, whether the window between calls stays inside the provider's expiry. Get those right and the same workload gets markedly cheaper. Get one wrong and every call writes, nothing reads, and you have quietly signed up for the premium with none of the discount.

That makes caching a place where measurement matters more than usual. The savings are real but invisible unless you read the provider's own cache-hit and cache-write figures and price them — a summary that says "caching enabled" tells you nothing about whether it's working.

The guides below explain when caching pays off and when it doesn't, how to enable it correctly, how to read the usage that proves it's working, and how to diagnose it when the reads never show up.