98.60%. 97.86%. 89.31%. Three numbers, one 48-hour window, and a rare moment of public honesty from an open-source tool founder. OpenCode co-founder Dax Raad shared the client-side cache hit rates for DeepSeek traffic over the past two days. The leader was not OpenCode. It was Zhipu’s ZCode, an Agentic Development Environment (ADE) that most Western developers have never installed. ZCode logged 98.60%. OpenCode V2 followed at 97.86%. Claude Code / CLI, the incumbent benchmark, sat at 89.31%. Dax’s reaction was blunt: "I don’t know what ZCode is, but it’s doing a really good job."
Every timestamp is a potential crime scene. This trace is not a hacker’s footprint; it is a billing ledger. DeepSeek prices cache-miss input at roughly fifty times the cost of cache-hit input. That asymmetry transforms a seemingly abstract percentage into a direct determinant of survival. A coding agent with a slightly lower hit rate is not paying slightly more. It is paying multiples more for the same input tokens. The difference between 98.60% and 89.31% is not nine percentage points. It is a 3.7x difference in input cost. That is the kind of gap that decides which small team survives a bear market and which one quietly shuts down.
I audit smart contracts for a living. I have spent more than a decade reading code that moves money. So when a number like 98.60% appears, my first instinct is not admiration. It is suspicion. The ledger bleeds where logic fails to bind. In this case, the logic is the cache hit rate, and the ledger is your monthly API bill.
Let me put the context on the table. DeepSeek is one of the most aggressive API pricing models in the market. It offers automatic prefix caching: when a request contains a long prefix identical to a prior request, the provider can reuse the cached computation and bill those tokens at a deeply discounted input price. A cache miss, by contrast, is charged at roughly fifty times that rate. This is not a small nudge. It is a structural cliff. For an agentic coding workload, every loop sends the same repository context, the same system prompts, the same conversation history, and the same tool definitions. If the client can keep that prefix stable, it rides on the cheap side of the cliff. If the client reorders the prompt, injects timestamps at the top, or resends the repository in a different file order, it falls off the cliff.
ZCode is the tool that stayed on the cliff. ZCode is an Agentic Development Environment launched by Zhipu, the lab behind GLM-5.2. It is not a model; it is a client. It is an ADE built to give GLM-5.2 a first-class agentic workflow. But it is not locked to GLM-5.2. It supports connection to other models, which is how it appeared in DeepSeek traffic. In crypto terms, ZCode is not a Layer 1. It is a wallet. And the wallet you use determines how cheaply you interact with the chain.
OpenCode V2 came in second at 97.86%. That is an excellent number. Claude Code / CLI sat at 89.31%. That is not catastrophic, but it is a structural disadvantage. At 89.31%, the miss rate is 10.69%. At 98.60%, the miss rate is 1.40%. That means Claude Code / CLI is suffering roughly 7.6 times more cache misses than ZCode. With a 50x price penalty, those misses are not noise. They are the cost engine of a tool that burns money while pretending to be efficient.
The arithmetic is straightforward. Let h be the hit rate. Let the cache-hit price per token be P. Let the cache-miss price be 50P. Then the effective input cost factor, relative to P, is:
C = h 1 + (1 - h) 50 = 50 - 49h
Plug in the numbers. ZCode at 98.60% gives C = 50 - 49 0.986 = 1.686. OpenCode V2 at 97.86% gives C = 50 - 49 0.9786 = 2.0486. Claude Code / CLI at 89.31% gives C = 50 - 49 * 0.8931 = 6.2381. Now divide ZCode by Claude Code: 1.686 divided by 6.2381 is about 0.270. That is where the 27% figure comes from. ZCode’s hit rate translates to only about 27% of Claude Code’s input cost, assuming the same token structure and the same workload. If you invert it, Claude Code’s input cost is roughly 3.7 times ZCode’s.
This is not a clever marketing claim. It is the direct consequence of a 50x penalty and a simple percentage. At 99% hit rate, the effective cost factor is 1.49. At 98%, it is 1.98. At 97%, it is 2.47. At 95%, it is 3.45. At 90%, it is 5.90. At 80%, it is 10.80. The curve is almost linear in the percentage points, but the cost penalty makes every fraction of a percentage point matter. The difference between 97.86% and 98.60% looks tiny on a dashboard. In dollars, ZCode is about 18% cheaper than OpenCode V2 on input tokens. The difference between 89.31% and 97.86% is the difference between a premium product and a discounted one.
Now comes the part that most coverage will ignore. The cache hit rate is a fraction, not a completion rate. It tells you what portion of the input was already known to the provider. It does not tell you whether the agent fixed the bug. It does not tell you how many tokens were spent per successful code change. It does not tell you how much output was generated. The missing variables are the whitespace that the dashboard does not show. The bug hides in the whitespace you skipped.
A coding agent can achieve a high cache hit rate by doing very little. If it simply repeats the same context while asking small confirmations, the cache stays warm and the hit rate stays high. But a good agent is supposed to generate new, unique diffs, not repeat old ones. The more code it actually writes, the more new tokens it will produce. A high hit rate can be a sign of intelligence, but it can also be a sign of laziness. You cannot distinguish between those two cases from a hit-rate screenshot.
I have seen this movie in DeFi. A protocol will report a high collateralization ratio, and the crowd will call it safe. Then the underlying asset moves 5% and the entire position is underwater because the denominator was structured to hide risk. The same logic applies here. The denominator is not hit rate. The denominator is cost per completed task. Hit rate is a useful numerator, but it is not the verdict.
Let me be even more suspicious. High cache hit rates can be gamed. DeepSeek’s caching is a prefix cache. If the client sends a warm-up request containing only the stable prefix, then follows with the full request, the full request will see a cache hit on that prefix. The reported hit rate may look excellent, but the actual workflow made two calls instead of one. This is cache laundering. It is legitimate cost optimization when done carefully, but it becomes dashboard gaming when the reported metric is treated as a proxy for product quality. I do not know whether ZCode is doing this. The public data is not sufficient to convict or acquit. But the question must be asked.
What makes ZCode’s number interesting is that it is not just high; it is almost suspiciously high. A 98.60% hit rate implies that fewer than 1.4 tokens in every hundred are new to the cache. That is the profile of a client that treats context as a reusable asset, not as a disposable envelope. It suggests discipline: stable system prompt first, stable file map second, dynamic task instruction last. It suggests that ZCode has spent real engineering effort on context orchestration. It may also suggest that ZCode guards its context aggressively, which is a double-edged sword. A tool that locks the context may become too conservative to explore alternative solutions.
ZCode is made for GLM-5.2. It is reasonable to assume that Zhipu designed its context manager with cache economics in mind. Chinese model providers have been aggressive on pricing and have trained users to watch token costs. An ADE that burns cache misses would not survive that market. ZCode’s high hit rate on DeepSeek suggests that the cache discipline learned on GLM-5.2 generalizes to other providers. It is also possible that ZCode’s tokenizer alignment with Chinese models makes DeepSeek’s caching more effective. The same repository content can be tokenized differently by different tokenizers. If ZCode produces prompts that align naturally with DeepSeek’s cache boundaries, the hit rate improves without any hidden trick.
But there is a darker reading. A tool that optimizes for cache hit rate may also be optimizing for semantic reuse rather than semantic progress. Suppose the agent repeatedly sends a huge static map of the repository and only appends a tiny request at the end. The hit rate will be extremely high. The cost per token will be low. But the tool may be spending most of its time reading, not editing. A lower hit rate might actually mean a more ambitious agent that is pushing the token stream forward. The bulls who read 98.60% as a sign of superiority may be confusing frugality with capability.
Let me say this plainly: I do not know which explanation applies to ZCode. The evidence is a 48-hour snapshot from one client’s telemetry. There is no public methodology, no confidence interval, no task difficulty profile, no success rate data. Dax Raad is a credible source, but his report is a snapshot, not an audit. In my line of work, I would never issue a security conclusion based on a screenshot. I would run the test myself, control the workload, and measure the response. The same rigor applies to the economics of an AI coding agent.
This is also a market problem. The bear market rewards survival. Developer tooling is going through a brutal compression: fewer empty venture checks, more scrutiny on burn rate, and a stronger preference for tools that reduce cost without reducing output. In that environment, a 3.7x input-cost difference matters. If the bull case is true, ZCode may be a serious financial weapon for teams using DeepSeek. If the bull case is false, the number is another inflated KPI that will collapse under a real workload.
Now, the contrarian angle. The bulls are not entirely wrong. The 98.60% hit rate is a real, measurable property of real traffic. It is not a whitepaper promise. It appeared in the telemetry of a competitor’s client, which gives it more credibility than a vendor dashboard. Dax Raad had no incentive to praise ZCode. His public confusion — "I don’t know what ZCode is" — is the most honest part of this entire story. It tells you that a major Western open-source tool founder was not tracking a direct competitor. That is not ZCode’s failure. It is the Western market’s blind spot.
From my crypto experience, I have seen this pattern before. The best audit tooling, the best execution infrastructure, and the best risk-management software are not always the products that appear on Western conference stages. Teams that wait to hear about a competitor from a tweet are already late. ZCode’s 98.60% is a signal that should force Western agent developers to look East. It does not mean ZCode is the final answer. It means someone outside the usual bubble has been paying attention to cost engineering in a way that the incumbent has not.
There is also a security angle that almost no one will discuss. High cache hit rates introduce a side-channel question. If a provider’s cache is shared across clients, the presence or absence of a cache hit can leak information about whether another user previously sent the same prefix. In a coding agent, that prefix might contain proprietary repository structure, file names, or user-specific instructions. A cache-timing observation can become a confirmation oracle. The very mechanism that creates the 50x discount may create a new privacy boundary. Trust is a variable, never a constant. You cannot assume that a cheap cache hit is socially or operationally free.
The same applies to DeepSeek itself. The 50x discount is not an act of charity; it is a pricing engine designed to encourage stable, repeatable prompts. That makes economic sense. It also means the provider benefits when users become lazy about context diversity. If every request is a copy of the previous one, the provider wins efficiency and the user loses novelty. An agent should not be rewarded for saying the same thing over and over. It should be rewarded for producing a correct diff with minimal waste.
The correct response to this data is not to crown ZCode. It is to run a benchmark. Take 100 real GitHub issues. For each issue, run ZCode, OpenCode V2, and Claude Code / CLI against the same repository state. Record input tokens, output tokens, cache hit rate, latency, and pass@1. Then compute the cost per merged pull request. That number is the only number that should matter. A tool can have a 98.60% hit rate and still lose because it makes three times as many attempts. A tool can have an 89.31% hit rate and still win because it solves the problem in one pass. The hit-rate screen is the teaser. The task-level benchmark is the audit.
Silence in the logs screams louder than alerts. The logs in this story are missing exactly what the screenshot hides: the total number of tokens per task. A hit rate of 98.60% over 100 million tokens is more expensive than a hit rate of 96% over 30 million tokens. The absolute token count changes the conclusion. The screenshot does not tell us whether ZCode is using fewer tokens or simply reusing more of them. If ZCode’s prompt is 10 times larger than Claude Code’s prompt, then a better hit rate can still produce a worse total bill. The percentage is meaningless without the denominator.
This is where I would caveat the 27% claim. The calculation says that, based on the same token structure, ZCode’s input cost is about 27% of Claude Code’s. The phrase "same token structure" is doing a lot of work. In reality, different clients send different numbers of tokens. One client may compress file contents; another may send full files every turn. One may keep a long conversation history; another may truncate it aggressively. So the 27% is a conditional estimate, not a universal invoice.
What ZCode likely got right is the stability of its context. The best way to keep a high cache hit rate is to place stable content at the beginning of the prompt and dynamic content at the end. System prompts, tool schemas, repository trees, and conversation history should come first. The newest instruction and the latest diff should come last. If a developer puts a timestamp at the top of a prompt, the cache is invalidated on every call. That is the kind of self-inflicted wound I see constantly in code-review bots. I have audited systems where a trivial reordering of fields increased API costs by an order of magnitude. The bug hides in the whitespace you skipped.
ZCode’s edge may be as simple as good prompt engineering. It may also be more fundamental: the underlying model, GLM-5.2, may have been trained with a cache-aware attention pattern that benefits any compatible platform. ZCode is built specifically for GLM-5.2, so it can shape its context in ways that Claude Code cannot easily copy. That is a real moat. It is not a trick; it is product design.
But there is a catch. The most cache-efficient agent is not necessarily the most correct agent. If ZCode’s high hit rate is driven by a very conservative behavior, then its users may be paying less but achieving less. The 98.60% number would then be a symptom of low ambition, not high capability. We cannot know without looking at task outcomes. And Dax’s tweet, while fascinating, does not include outcomes.
The next step is not to switch tools. The next step is to measure your own workload. If you run a weekly maintenance bot that reads the same repository and posts the same style of comments, then cache hit rate is the most important cost lever in your system. You should push that number as high as possible. If you run a research agent that explores unfamiliar code and writes new tests, you should expect a lower hit rate. The same target is not equally appropriate for every workload.
The deeper problem is that hit rate has become a vanity metric. In crypto, we learned this lesson with total value locked, with exchange volume, with unique wallet count, and with any number that can be rented or gamed. The industry always starts with a metric that has some truth, then abuses it until it has no signal left. Cache hit rate is on that path. If everyone starts optimizing for cache hits, we will get an ecosystem of agents that repeat themselves and avoid novelty. The metric will rise, and the value will fall.
I am not saying that ZCode’s 98.60% is fake. I am saying that it is insufficient. A forensic analyst wants to know who sent the request, what was requested, what was returned, and what it cost. The reported hit rate, by itself, is the beginning of the story. The end of the story is whether a developer landed working code and whether it cost less than the alternatives.
In the past 48 hours, the market learned a name it should have known earlier. ZCode deserves attention. Zhipu deserves some respect. Dax Raad deserves credit for publicly sharing a result that did not favor his own product. But the next 48 hours should be spent building a better benchmark, not building a better meme. Exploits are not hacks; they are conversations. The conversation here is between a client’s context manager and a provider’s billing table. It is an economic conversation, and ZCode appears to be speaking it fluently.
At the end of the day, code does not lie; it merely waits. The code that determines this story is not visible in the tweet. It is inside ZCode, inside OpenCode, and inside Claude Code. It is waiting for someone to run a fair benchmark. The ledger bleeds where logic fails to bind, and right now the logic is clear: hit rate is a cost factor, not a quality score.
So here is my takeaway for developers, founders, and investors. Do not ask whether ZCode is better than Claude Code. Ask how much it costs to complete one real task with each tool. Ask how many tokens are wasted on repeated context that never becomes action. Ask whether the cache is being used as a tool or exploited as a trick. Reputation is liquid; solvency is binary. In a bear market, the tool that appears cheapest but fails more is more expensive than the tool that appears costly but ships. What matters is not the hit rate. What matters is the cost per merged pull request. If you cannot calculate that number, you are not auditing your AI spend; you are gambling with it.
I know what I will be doing in the next 48 hours. I will be reading ZCode’s source, checking how it orders prompts, and running my own controlled tests on DeepSeek. And I will be watching the logs. Because silence in the logs screams louder than alerts. And the cache hit rate, left unexamined, is just another way to look busy while the money leaks out.