A 94.5% Cache Hit Rate Cut This Coding Agent's Costs by 85%

Foreword

What determines whether a coding agent burns through money isn't the model's unit price — it's the cache hit rate.

That sounds counterintuitive. I ran DeepSeeker-Code for a full day of testing, broke down the bill and tokens, and that's the conclusion. This article settles the account completely: how many tokens were burned in a day, how much it cost, why it's so cheap — and most critically, this cheapness didn't fall from the sky; it was preserved, point by point, through engineering.

(The previous article discussed the overall design trade-offs. If you haven't read it, you can check it out first: The Design Philosophy of DeepSeeker-Code. This one is its sequel, specifically about "saving money.")

1. First, the Bill: How Much Was Burned in One Hour

The model is deepseek-v4-flash, and the time slot is 16:00~17:00, a single hour of high-intensity use:

Posting note: The two images above are local paths. Please manually upload and replace them when publishing to Juejin.

Organized into a table:

Item	Value
Time Slot	16:00 ~ 17:00 (one hour)
Total Tokens	25,682,801
Input (Cache Hit)	24,094,336
Input (Cache Miss)	1,393,449
Output	195,016
Consumption for the Slot	¥2.26

25.68 million tokens, two yuan and twenty-six fen. That's the entire cost of one hour of high-intensity agent use.

Three numbers are the most critical: a cache hit rate of 94.5%, output accounting for only 0.76% of the total, and two yuan and twenty-six fen for one hour. Let's break them down one by one.

2. The Agent Is an "Input Monster": Costs Are Almost Entirely in the Input

First, look at a counterintuitive point: the output was only 195,000 tokens, while the input was 25.48 million — the input was 130 times the output.

Why? Because an agent is not a chat. A chat is you say something, I say something, and the context is light. For an agent, every time it completes a round of "reasoning → calling a tool → getting a result," the next round of reasoning requires it to re-send the entire context to the model again: the system prompt, the tool list, all previous conversations, and the results returned by the tools. After ten rounds of work, the system prompt and tool list have been re-sent ten times.

Therefore, an agent's cost structure is naturally lopsided: the output (content generated by the model) is the minority, and the input (context re-sent repeatedly) is the bulk. In this one hour, 99.2% of the cost was on the input side.

And the good news is — caching only applies to the input.

3. Caching Saved the Day: The Hit Unit Price Is Only One-Tenth of a Miss

DeepSeek has a mechanism called context caching: the context you sent in the previous round is cached by the model for a period of time; in the next round, as long as the prefix is the same and hasn't changed, this part goes directly through the cache, and the unit price is only about one-tenth of the normal input price.

Look back at that 94.5% hit rate: out of the 25.48 million input tokens, 24.09 million hit the cache and were billed at the bargain-basement price of one-tenth; only 1.39 million were cold data, charged at full price.

How much does this save? Let's do the math. Assume the unit price for an uncached input is p, then the hit part is p/10:

• With caching, the input cost ≈ 24.09 million × (p/10) + 1.39 million × p, which converts to roughly 3.8 million × p
• If there were no cache at all, everything would be at full price: 25.48 million × p

Caching reduced the input cost to about one-seventh, slashing nearly 85%. This is why 25.68 million tokens only cost two yuan and twenty-six fen — the bulk was eaten up by the cache at a 90% discount.

Without this cache dividend, the input cost for the same hour would be nearly 7 times higher. Accumulated over a day or a week, the difference is in the hundreds or thousands.

4. The Hit Rate Doesn't Come for Free: How Engineering "Preserves" the Prefix Cache

At this point, someone is bound to think: isn't a high cache hit rate DeepSeek's own business? What does it have to do with how you write an agent?

It has everything to do with it. There is a hard prerequisite for a cache hit: the prefix of the context must be exactly the same as last time. If the prefix differs by even a single word, everything from that position onward is counted as a miss.

So here comes the problem — the agent is stuffing new things into the context with every round (new tool results, new conversations). If you aren't careful, and you change a section of the system prompt today or insert a line tomorrow, or if the timing of compression is wrong and alters the preceding content, the cache "snaps" instantly, the 94.5% hit rate goes to zero in a moment, and the bill immediately multiplies several times.

To preserve this prefix, DeepSeeker-Code does several critical things:

First, the system prompt is absolutely stable. The first item in the message list is always the system prompt, and content is only ever appended to the end; it is never reordered, and nothing is ever inserted in front of it. No matter the round, its prefix remains motionless — this is the foundation for a cache hit.

Second, compression defers to the cache's mood. When the context is nearly full, it needs to be compressed, but compression itself will shatter the cache (because the content changes). So my timing for compression is dynamic: when the cache hit rate is high, it's better to hold on a bit longer and continue to reap the cache dividend, not acting rashly; when the hit rate is low, since it has to be recalculated anyway, it's better to compress early. This directly ties the decision of "whether to compress" to "whether the cache is healthy."

Third, the positions of the summary slot and tool list are fixed. Which content goes first and which goes second have fixed positions; no unnecessary structural adjustments are made. Once the positions are fixed, the prefix is stable, and the cache is stable.

To put it plainly, this whole set of practices repeatedly chooses stability over "flexibility." Every bit of flexibility sacrificed for cache friendliness saves real money.

5. What Is the Cost?

These optimizations for the cache are not without cost:

Cost one: many constraints. The structure of the system prompt cannot be casually changed. Wanting to add a new feature or adjust the order of a prompt requires weighing whether it will hurt the prefix. A lot of flexibility has been sacrificed.

Cost two: locked into DeepSeek. This set of "stable prefix + cache-aware compression" is tuned to DeepSeek's cache temperament. Switch to a model with a different caching strategy, and this whole skill set has to be torn down and rebuilt. Another trade-off of "generality for specificity."

Cost three: a fallback for when it shatters. The cache will inevitably fail sometimes (after a long period of disuse, or when a major prefix change is unavoidable). At those times, it relies on another system — using the real token consumption of each round to calibrate a local estimate, ensuring the compression timing isn't based on guesswork, preventing a situation where costs spiral out of control unnoticed once the cache breaks.

Honestly speaking, the cache is a blade: wielded well, it saves money; wielded poorly, it's a pile of invisible constraints and coupling. But weighing it all up, for a high-frequency local agent, this deal is more than worth it.

Conclusion

Talking up to this point, that statement lands: the logic of an agent saving money is essentially about letting repeated context go through the cache.

The model providing the cache capability is giving you a seed; whether it can grow into a 94.5% hit rate and press the bill down to two yuan and twenty-six fen depends entirely on how much soil you've left for it in your engineering. Don't mess with the system prompt, let compression defer to the cache, seek stability in the message structure — these unremarkable constraints are the true heroes of saving money.

Running locally, DeepSeek's cache dividend, plus engineering optimized for the cache point by point — this combination is what produced the real cost of two yuan and twenty-six fen for an hour of high-intensity use. Compared to cloud solutions that bill per call or subscription fee, this account looks comfortable to me.

The project is open source: github.com/xknk/deepSeekCode. Welcome to take a look and raise an issue. If you find this money-saving line of thinking a bit interesting, giving a star is the greatest encouragement for me.

Summary

1. The agent is an input monster: Out of 25.68 million tokens in one hour, output accounts for only 0.76%; input is 130 times the output — the cost is almost entirely in the repeatedly re-sent context;
2. Caching is the core of saving money: The unit price for a cache hit is only about one-tenth of a miss; a 94.5% hit rate slashes the input cost by nearly 85%;
3. The hit rate is preserved: An absolutely stable system prompt, compression that defers to the cache, and a stability-seeking message structure — these constraints are the true source of the 94.5%;
4. The cost is constraints and coupling: Flexibility is sacrificed, it's locked into DeepSeek, and a fallback for cache breakage must be prepared, but the trade-off is worth it.