To receive a (non-guaranteed) discount, the entire initial input context needs to be the same. The cache is temporary after the recent call, with a lifetime around 10-60 minutes (someday I’ll classify how long is delivered).
If you change initial system message instructions from “you are a helpful ai” to “you are a helpful ai with these user preferences”, then you have broken the caching.
That also applies to the list of internal tools and developer-provided functions that are appended to your system message. Switch tools on and off and you break caching.
The Responses mechanisms for a server conversation state do NOT offer improved caching discount quality, nor do they save you any input token cost. Your benefit is only the fact that you don’t need to send all the user’s chat messages again over the network (but instead, another database of user chat tracking with equal complexity must be made by you anyway).
So, it would be possible to increase the cache chances by building a platform’s monotonal input of system message and tools up to beyond 1200 tokens (or so) for a match guarantee. You could get a 50% - 75% discount on that part that is often reused.
It also means your chat length management of your own can be cache-aware: only truncate and alter if the chat is stale, as it might take 50% truncation or more to reduce the costs below a cache discount opportunity.