Like google search, this does not work because of how common long tail use is.
What you think could be a big chunk, is more likely to be a fraction of a percent of queries.
And what use is similar query caching - so you (very often! if actually cost effective, maybe half the time) get a response to a query that was different from yours. Including for when you have a lot of context input already. You’re going to get trash.
If it were constrained to only very common initial prompts, and somehow the long tail did not actually dominate as it does with Google search (can't find the reference at the moment but it was a famous article some years ago), it also wouldn't account for serious enough cost savings. Long context is what is expensive.
This might only work in constrained domains like customer service where there’s tolerance for generic answers and escalation paths. For technical work? For general purpose use, with secretly canned responses charged at full price?
I would be very surprised if they hadn’t sorted out some form of shared KV caching
Please pardon the pure speculation incoming. Yes, caching the answer doesn't seem useful. Caching the progression, the graph, may be. This is similar to making code changes with ed(1) instead of editing in vi.
The transform script(s) are cached and can be played back or adjusted. Surely for some breadth of question inputs, they map more often to similar answers--but not static answers; instead, evented edits.
It's nearly untenable for a human to keep private edit scripts to generate code changes. The extra steps for custom regex, essentially one-offs for a shared codebase, is inefficient. But maybe not to an LLM.
But there must be a ton of generic questions that people ask. Stuff like "What's the capital of country X?" - it's probably at least 10% of queries. Memories, custom instructions etc would invalidate them, but if you can return the answers basically free it's probably worth it.