Reasonix and the real cost lever for coding agents: prefix-cache stability

2026-06-02 · ~7 min read · Conor Dobbs

A DeepSeek-native coding agent called Reasonix has been making the rounds with a striking claim: one user ran it for a full day, pushed 435 million input tokens through it, hit a 99.82% cache hit rate, and paid about $12 for work that would have cost roughly $61 without the caching. That is a 5x cut, and the number is real enough to take seriously. The interesting part is not the tool. It is the mechanism, because prefix-cache stability is the single biggest cost lever any coding agent has, and most agents leave it on the floor.

What Reasonix is

Reasonix is a terminal-first coding agent, MIT-licensed, written in TypeScript, with a bit over 9,000 GitHub stars at the time of writing. DeepSeek lists it in their official agent integrations docs, where it is described as talking to api.deepseek.com directly without a translation shim. By default it runs DeepSeek-V4-Flash for cheap iteration and lets you switch to V4-Pro with a slash command when a task needs the heavier model.

The design pitch is a "cache-first loop" with "flash-first cost control." Strip the marketing off and what it means is that Reasonix is built from the ground up to never break DeepSeek's prefix cache. That is the whole game.

Why prefix caching is the lever

Here is the part worth internalizing even if you never touch Reasonix.

Every modern LLM API bills input tokens, and most of them now offer a discount on tokens that match a prefix the server has already seen. The provider keeps the attention state for a common prefix warm and charges you a fraction of the normal rate to reuse it. DeepSeek's prefix cache is aggressive: a cached input token costs a small fraction of an uncached one.

The catch is that the discount only applies to an exact prefix match, byte for byte, from the start of the prompt. The moment anything early in the prompt changes, every token after the change is a cache miss and you pay full freight.

A coding agent is the worst-case workload for this. It runs in a loop. Each turn re-sends the system prompt, the project context, the conversation so far, and a pile of tool outputs. If any of that early context shifts between turns, the cache shatters and you re-pay for the entire window on every single step. Run that loop a few hundred times across a workday and the bill is dominated not by how smart the model is but by how often you broke its cache.

This is the same cost dynamic I wrote about in how to cut your Claude Code bill: the spend on an agent is governed by how much it writes and how often the loop re-reads the same context, not by the sticker price per token.

What Reasonix gets right

Reasonix's design is three rules that keep the prefix stable, and they are worth copying regardless of which model you run:

Fixed prefix ordering. The system prompt, project context, and memory always sit in the same position. New information is appended to the end, never inserted into the middle. Inserting anything early would push every later token to a new offset and miss the cache.
Incremental context growth. When the agent reads a new file, that file goes at the end of the context, behind everything already cached. Nothing in front of it moves.
Stable tool-call formatting. Tool calls are serialized identically every time. A reordered JSON key or a different whitespace style is enough to break a byte-exact prefix match, so the format is frozen.

None of this is exotic. It is disciplined prompt construction in service of a billing reality. The lesson generalizes: if your agent rebuilds its prompt from scratch each turn, sorts a dictionary non-deterministically, or splices fresh data into the middle of the context, you are paying for cache misses you could have avoided.

Where it quietly breaks

The 99.82% figure is a best case, and it is fair to be skeptical of it. A clean demo that reuses a tidy prompt will cache beautifully. Real work introduces entropy: file diffs, timestamps, shifting tool output, error messages that vary run to run. As one critical writeup put it, early demos feel fast because they reuse prompts, and then cache keys stop matching once real usage sets in.

The failure mode is specific. Anything that reorders context, injects a volatile value early, or varies a format will silently drop your hit rate, and you will not see it unless you are watching the cached-token ratio on your invoices. A timestamp in the system prompt, a file tree that re-sorts when a file is added, a tool that returns results in a non-deterministic order: each one is a leak. The 99.82% headline is achievable, but it is a ceiling that careful engineering reaches, not a default you get for free.

So treat the number the way I treat every vendor benchmark. It is plausible under ideal conditions and worth verifying against your own billing data before you bank on it.

How I would use this

If you are a solo developer, the token bill barely registers. A few dollars a day is noise against an hour of your time, and you should pick the agent that finishes your real tasks, which is a question of capability and reliability, not price. I worked through that capability gap in Cursor vs Claude Code vs Aider, and it still holds: the leaderboard is not the lived experience.

The calculus flips the moment you run agents at volume. A team running coding loops in CI, batch refactors across a monorepo, or thousands of automated runs a day is exactly where a 5x caching discount stops being a footnote and becomes a budget line. There, two moves pay off:

Measure your cache hit rate before anything else. Most teams have never looked. Pull the cached-token ratio from your provider's usage data. If it is low, you are leaking money on every loop and no model swap will fix it, because the problem is your prompt construction, not your model.

Stabilize the prefix. Freeze the order of your system prompt and context. Append, do not insert. Make tool-call serialization deterministic. Strip volatile values like timestamps out of the cached region. These are cheap changes that compound across every run, and they work on any provider that offers prefix caching, not only DeepSeek.

Reasonix is worth a look if you live in DeepSeek's ecosystem and want an agent that bakes these rules in. But the durable takeaway is the principle, not the product. The cheapest token is the one you do not re-send, and prefix-cache discipline is how you stop re-sending it.

The honest bottom line

Reasonix is a real, open-source agent built around a real insight: for any agent running in a loop, cache stability dominates the bill. The 99.82% hit rate is a ceiling, not a promise, and your mileage depends entirely on how much entropy your own workflow injects into the prompt. Verify the savings against your invoices rather than the launch chart.

The reason this matters beyond one tool is that the same discipline cuts costs on Claude, GPT, Gemini, and anything else that prices cached input below fresh input. Stop breaking your own cache, and the bill follows.