Ninety-eight point six percent.
No blockchain exploit. No token collapse. No NFT mint. Just a number on a telemetry dashboard—and yet it set the AI-coding world on edge.
According to monitoring by Dongcha Beating, OpenCode co-founder Dax Raad shared client-side cache hit rates for DeepSeek traffic over the past 48 hours. His own OpenCode V2? 97.86. Claude Code/CLI? 89.31. At the top sat a name most people outside China's AI circles had never seen: ZCode. 98.60.
Raad's response was disarmingly honest. “I don't know what ZCode is, but it's doing a really good job.”
I know that feeling. The first time a number humbles you in public, you don't reach for a rebuttal. You sit still and re-check your data. This is a fork in the road where code met chaos—and won.
Why does this number matter so much? Because DeepSeek has become the default open-weight family for cost-conscious developers building agents. DeepSeek doesn't treat all input tokens equally. A cache hit is cheap. A cache miss is roughly 50 times more expensive. For an agentic coding environment that re-reads the same repository tree, the same file diffs, and the same instruction block dozens of times a day, that difference is not theoretical. It is the difference between a tool that survives and a tool that bleeds runway.
ZCode is an Agentic Development Environment, or ADE, launched by Zhipu for GLM-5.2. It is not a walled garden—it also supports connections to other models. But it was born inside Zhipu's stack, and that matters more than any feature list. When you control both the model and the editor, you can shape the request so the cache sees the same tokens again and again. You are not just sending a prompt. You are sending a prompt engineered for reusability.
Before the math, let me make one point clear: this is not a benchmark that rewards intelligence. It is a benchmark that rewards memory. DeepSeek's cache is keyed to token prefixes. When your prompt starts with the same ten thousand tokens as the last prompt, the server can reuse the precomputed representation. When you change an early line, the entire following chain breaks and the model recomputes. For a coding agent, this means the way you order your repository context is more important than the quality of your model prompt. Most developers still think “sending everything from the repo” is safe. In cache terms, it is a coin flip.
Let's do the math. We don't need absolute prices; the ratio is enough. Normalize a cache hit to one cost unit. Let a cache miss be fifty units. For any hit rate H, the expected input-cost multiplier is:
H + 50 x (1 - H)
ZCode's H = 0.9860. That puts its multiplier at 0.9860 + 50(0.0140) = 1.686.
OpenCode V2's H = 0.9786. Multiplier: 0.9786 + 50(0.0214) = 2.049.
Claude Code/CLI's H = 0.8931. Multiplier: 0.8931 + 50(0.1069) = 6.238.
Now compare them directly. Relative to Claude Code, ZCode's input cost is 1.686 / 6.238 = 0.270. Roughly 27%. OpenCode V2 is 2.049 / 6.238 = 0.328, or about 33%. Based on the same token structure, ZCode's hit rate translates to only about 27% of Claude Code's input cost. That's not a margin. It's a wall.
Let's translate that into something tangible. Suppose one cache hit costs one unit and one cache miss costs fifty. If an agent workload consumes one million input tokens per week, Claude Code would burn 6.238 million cost units. A ZCode-style workflow would burn 1.686 million. Every week, that saves 4.552 million units. Double the workload. Triple it. Add an entire team of agents. The gap compounds faster than the imagination can follow. The best teams I know in crypto don't stare at token prices; they stare at the structural cost of every transaction. This is the same discipline. The cache is the transaction fee of AI, and hit rate is the gas price.
The client-side detail makes this even more interesting. A client-side cache hit rate is not just a server-side count. It measures whether the client sends tokens in a way the provider's cache can recognize. In my years auditing decentralized systems, I learned that the biggest cost is almost always hidden in the interface between two systems. Here, the interface is the prompt prefix. If a client reorders files, alphabetizes imports, or inserts timestamps, it shatters the prefix and pays the 50x toll. If a client is built to preserve the exact same token sequence across turns, it wins.
Think of it like a Uniswap V4 hook: a small piece of logic placed at the exact point where tokens flow and where value is either reclaimed or wasted. ZCode has installed itself inside that hook. It knows the tokenizer. It knows how GLM-5.2 expects to see context. And it reuses that context ruthlessly. OpenCode V2's 97.86% deserves equal respect. It means Dax's team achieved a near-98% hit rate on a provider they do not fully control. That is not luck. That is cache-aware engineering, built with the same speed and focus I've seen in the best crypto risk teams—they don't wait for the black swan; they build the mempool-level defense before the transaction lands.
OpenCode's result is even more impressive when you remember it is an open-source tool that supports multiple models without the benefit of owning the model's tokenizer. ZCode has the unfair advantage of being co-designed with GLM-5.2. OpenCode has to be an indifferent neutral party across many providers, and it still hit 97.86%. That is the real upset.
This is the fork in the road where code met chaos and won—again. The first win was DeepSeek itself, proving that open-weight models can deliver frontier-scale code at a fraction of the legacy cost. The second win is ZCode, proving that a focused ADE can make even that cheap price dramatically cheaper. But here's the thing about winning with a metric like this: it doesn't stay won.
Now for the uncomfortable part. A high cache hit rate is not always proof of superiority. It can be proof of sameness.
ZCode is new. Its user base is likely smaller and less chaotic than Claude Code's. A smaller population means less variance in prompts. If a tool is mostly used by developers inside the same ecosystem, with similar project structures, the cache stays warm. Claude Code, by contrast, serves millions of people who do all kinds of unpredictable things with it. Every developer introduces a custom instruction. Every repo has a different layout. Every session begins with a different problem. That diversity destroys cache hits.
The 89.31% number might be the price Claude Code pays for being the default agent for the messiest, widest community in the world. It could be a sign of adoption breadth, not engineering failure. And in behavioral terms, the gap between 98.60% and 97.86% is barely above noise. One new template across a few thousand sessions can move that number by half a percentage point.
The 48-hour window is another caveat. Short samples favor tools with tight prompt templates. A weekend is a weird time for enterprise coding agents; there are fewer users and more repetitive tasks. We need a month of data before we crown an agent.
We should also ask whether the metric can be gamed. It can. If you are optimizing for cache hits, you can make your editor send the same enormous context prefix every single time, even when that context is irrelevant. The cache will hit. You will save money. But now the model is chewing on obsolete context, and your output quality quietly decays. Cache efficiency can become cargo cult efficiency. You can have a perfect 99% hit rate and still ship code that breaks production.
This is the DA layer of AI. I have spent years saying the Data Availability layer is overhyped—that 99% of rollups don't generate enough data to need a dedicated DA chain. The cache hit rate is starting to feel like DA: a metric that gets hyped because it is easy to measure. Then teams distort their workflows to make the number look better. Don't be that team.
Teams should start with cold-start cost. The cache misses are expensive, but they are also the moments when real learning happens. Measure what you pay when a new repository enters the session. Measure what you pay when a developer jumps to an unfamiliar language. Those are the true stress tests. A tool with a 98% hit rate and a terrible cold-start cost is just a very efficient tool for doing one thing over and over. A tool with a 90% hit rate but a low cold-start cost can handle the unknown—and the unknown is where software bugs live.
Then, treat the cache as a design surface, not a side effect. The next generation of agentic tools will be built with prompt-prefix stability as a core feature. They will pin repeated context blocks at the front of the request, use deterministic ordering for repository maps, and reserve expensive context slots for information that changes between turns. This is not fancy research. It is disciplined systems design.
And watch ZCode carefully. If its hit rate stays at 98.6% as its user base grows into the hundreds of thousands, something structurally different is happening—not just sample-size luck. If the rate drifts downward after a few months, we will know it was a reward for being small and focused. Either outcome is informative.
In a bear market, survival matters more than upside. If you are a founder reading this while you watch your compute bill climb, I know the pressure. Every dollar of token spend is a dollar you cannot put into engineering, safety, or runway. Cache hit rate is not another buzzword; it is a survival tool. Users don't care about the cleverest agent. They care about which agent still has money left at the end of the month. It is the new validator inclusion rate, the new gas price, the new grant runway. It tells you which protocol can keep producing without bleeding out.
Behind every cache hit is a developer who didn't have to think about token budgets. Behind every cache miss is a developer refreshing the cursor again, waiting for the model to re-read a file it already saw. That is the sociology of this market. The tools that make efficiency invisible will win the emotional loyalty of teams.
Dax Raad may not know what ZCode is. But ZCode knows exactly what it is. It is a reminder that the biggest edge in any infrastructure war comes from the boring layer nobody wants to talk about—the layer where tokens are either reused or burned.
The fork in the road where code met chaos and won is still being paved. The question now is whether the winning agent can hold that pace when the road gets crowded. I don't know the final answer. But I know where to look: not at the benchmark leaderboard, not at the GitHub star count, but at the cache dashboard, where the real cost of intelligence hides in plain sight.
