A coding agent deep in a session sends a hundred thousand tokens of conversation and gets a few hundred back. The server does not recompute that history: if the earlier text is unchanged, it replays its key-value cache and prefills only the new tail. That is the whole deal prompt caching offers, and the harness, not the model, decides whether the deal holds.

Neuralwatt runs an inference cloud that bills by measured GPU energy, and their CEO went through a month of request metadata to see how much of that energy the client controls. Across their most widely used clients, 1.6 to 11.1 percent of input tokens could not be served from cache. The spread is the finding: a client at 97 percent cached sends three uncached tokens per hundred, a client at 92 percent sends eight, which is 2.7 times the prefill work for the same conversation. A mostly-uncached request uses about twice the energy of a cached one of the same size. Past 128k tokens of context, roughly 3 turns in every thousand re-read more than half the prompt from scratch, and a single one of those costs as much prefill as about 600 ordinary turns. A cache break never raises an error. You still get your answer, later and more expensively.

In their lab, every reproducible break came from the harness editing text it had already sent. OpenCode 1.x attaches a plan-mode reminder to each new user message and removes it on the following turn, so every turn re-reads the entire previous one, tool calls and all. omp replaces a re-read file with “[Superseded by a newer read of a file]” — one edit, 62 percent of the way into the prompt, re-read 5,846 of 15,520 tokens. OpenCode 1.x and Kilo Code write today’s date into the system prompt, so crossing local midnight re-reads nearly everything, once. Switching reasoning effort mid-session re-reads everything from token 8. Idle time, restarts, and sub-agents broke nothing.

None of these are bugs. omp’s pruning exists to shrink the prompt; the reminder exists to keep the model on task. The cost appears because the harness and the server keep two different ledgers: the harness counts tokens, and the server recomputes from the first difference onward. An edit that saves a thousand tokens can re-buy a hundred thousand. OpenCode 2.x shows the fix without giving up the features: the reminder moved into its own message, the session keeps its original date with a note appended when it changes, the tool list stays put when an MCP server connects. Same information, appended instead of rewritten.

One client in their capture never broke the cache at all, including across restart and resume: deepseek-harness, which rebuilds every request from an append-only session log, writes its system prompt once and leaves anything that changes (the date, git status, the OS) out of it, appends state changes after the history as superseding snapshots, keeps the tool list sorted and stable in every mode, and compacts late with the summarizer reusing the existing prefix. Each package in its repo carries a short “KV cache effect” section, so the cache contract gets reviewed like a security surface. For harnesses you only configure: settle effort, MCP servers, and skills before the session gets long, because that is when a break hurts most; in omp, compaction.supersedeReads: false and compaction.dropUseless: false keep the cache at the price of the tokens the pruning saved.

The honest limits: their production numbers include cache eviction under memory pressure, which a server cannot distinguish from a harness edit, so the clean causes come from their lab runs — and every figure above is Neuralwatt’s, metered on their cloud and a scripted recording proxy I have not re-measured. They also leave the field an open question: OpenCode 2.x fixes most of the 1.x cache breaks they reproduce in the lab, and that improvement does not show up in their production traffic. They don’t know why yet.