Caching does not automatically reduce AI cost.
A stable prompt prefix creates an opportunity for reuse. It does not guarantee savings. The timing of that reuse matters.
The visual follows four requests at minutes 0, 4, 8 and 15. Both models have the same displayed input, cache-write and cache-read rates. Their cache lifetimes differ.
Claude Sonnet 5.5's default five-minute cache refreshes on each hit. Requests at minutes 4 and 8 reuse the prefix. But the seven-minute gap before minute 15 exceeds that lifetime, requiring another paid write.
GPT-6.1 Sol's documented thirty-minute reuse window can accommodate that same gap, provided the matching cache entry remains eligible and available.
For a 100,000-token prefix, the illustrated sequence costs $0.52 versus $0.28 in prefix charges alone: two writes and two reads versus one write and three reads.
That is not a full model-cost comparison or a quality benchmark. New input, output, failed attempts, retries and human review are excluded.
The rates have not changed. The economics of reuse have.
For engineering and FinOps, the decision is not simply whether to enable caching. It is whether the policy fits actual request cadence, cache lifetime, hit rate and write frequency. Any extra retention charge must also earn its return through reuse.
As in context allocation more broadly, caching is one lever, not the whole strategy. It changes the cost of processing stable context; it does not remove that context from the window.
Select what matters. Reuse what is stable. Then measure cost per accepted result, not just cost per cached token.