DeepSeek-Reasonix Is a Coding Agent Built Around One Number: the 50x Gap Between a Cache Hit and a Cache Miss

DeepSeek charges $0.0028 per million input tokens on a cache hit and $0.14 on a miss. Most agent harnesses pay the miss price every turn without noticing. Here is what a harness looks like when someone designs around that instead.

Open DeepSeek's pricing page and the interesting column is not the one people quote. V4 Flash bills output at $0.28 per million tokens and cache-miss input at $0.14. Cache-hit input costs $0.0028. That is fifty times cheaper for the same tokens, decided entirely by whether the prefix of your request matched something already sitting on DeepSeek's disk.

Now think about what a coding agent does for forty minutes. Every turn it resends the whole conversation, the file contents it read, the tool results, the system prompt. That prompt grows. If the growing part is appended cleanly to an unchanged front, almost all of it bills at the hit price. If anything near the front moves, even by a byte, the whole thing bills at the miss price again.

esengine/DeepSeek-Reasonix is a terminal coding agent whose entire architecture is an answer to that sentence. The tagline on the repo is "engineered around prefix-cache stability," and unlike most taglines it describes a real constraint that shows up in the design decisions.

The rule that makes caches break

DeepSeek's context caching docs explain the mechanism precisely enough to plan against, which is rarer than it should be.

Caching is on by default for everyone. Each request writes a hard disk cache. A later request hits that cache only when it fully matches a persisted cache prefix unit, and under sliding window attention, full match means full match. Partial overlap does not earn a partial discount.

Three things create those units. Every request persists one at the end of the user input and one at the end of the model output. When the system notices a common prefix across several requests, it persists that shared span as its own unit. And for very long inputs or outputs it carves units at fixed token intervals, so a long prefix does not go permanently uncacheable just because it never reaches a boundary.

The documented example is the one that should worry anyone who writes a harness. First request is A + B. Second request is A + C. No hit, because A + C does not fully match the A + B unit. The system does notice the shared A and persists it, so a third request A + D finally hits. You pay full price twice to earn the discount on the third.

Now consider what a typical agent does between turns. It rewrites the system prompt with a fresh timestamp. It re-sorts the tool list. It compacts the middle of the conversation into a summary. Each of those is a B becoming a C, and each one throws away the cache in front of it.

The response tells you when this happens. Every DeepSeek reply carries prompt_cache_hit_tokens and prompt_cache_miss_tokens in its usage block. Most people never read them.

What Reasonix actually does about it

The loop is append-only. History grows at the end and the front stays byte-identical, so each turn replays the previous turn from cache and computes only what is new. That is the whole trick, and everything else in the design protects it.

Compaction runs at low frequency rather than continuously, because compaction is the single most expensive thing a harness can do to a cache: it rewrites the middle of the prefix and invalidates everything after it. Running two models is handled by giving the executor and the planner separate cache-stable sessions instead of interleaving them into one thread, which would mean two different prefixes fighting over the same conversation.

The rest is conventional and well-executed. It is a single CGO-free Go binary cross-compiled to six targets, with a TOML parser as the only dependency, installed by npm i -g reasonix or Homebrew. Providers are config entries in reasonix.toml rather than code, so DeepSeek Flash and Pro and Xiaomi's MiMo ship as presets and any OpenAI-compatible endpoint is three lines. Built-in tools cover read, write, edit, multi_edit, glob, grep, ls, bash, web_fetch, task, and todo_write. It is an MCP client over stdio and Streamable HTTP, it reads an existing .mcp.json field-for-field, and MCP prompts show up as slash commands while resources come in through @server:uri references.

The permission model deserves a note because it separates two things most harnesses blur. Permissions are policy: deny beats ask beats allow, readers default to allow, writers fall back to your configured mode, and reasonix run stays autonomous while still honoring deny rules. The sandbox is enforcement: file writers refuse any path outside the workspace root, resolving symlinks and .. so a link cannot tunnel out. On macOS, bash is jailed under Seatbelt by default and reaches the network only when you enable it.

Put this into practice, with or without Reasonix

The cache discipline is portable. Anthropic, OpenAI, and Google all price cached input below fresh input, and the same rules about prefix stability apply. If you are building or tuning a harness, five changes do most of the work.

Freeze the front of your prompt. No timestamps, no session IDs, no "current time" line, no randomly ordered tool schemas in the system message. Anything that varies per request belongs at the end, and the docs say this directly: keep the reusable part in front, the variable part behind it.

Append instead of rewriting. If your loop edits earlier turns, trims the middle, or reformats old tool output, you are paying full price to do it. Add to the tail.

Compact rarely, and at a boundary. Every compaction resets the cache from that point forward, so treat it as an expensive operation you schedule rather than a background hygiene task. Reasonix landing on "low-frequency compaction" is the same conclusion arrived at from the billing side.

Load the expensive context once, early, and leave it there. Reasonix maps the codebase a single time and keeps that map in the warm prefix. Any large stable artifact, a schema, a style guide, a file tree, should be placed once at the front and never touched.

Give each model its own session. Two models sharing one thread means two prefixes and two sets of misses. Separate them.

Then measure, because none of this is worth assuming. Log prompt_cache_hit_tokens against prompt_cache_miss_tokens on every call and watch the ratio over a long session. If it drops after a specific action, you just found the thing in your loop that mutates the prefix.

The honest limitations

The headline numbers are self-published and they do not quite agree with each other. Reasonix's site claims long sessions hold 90%-plus cache hit and that input-token cost collapses to about one fifth. Run those against DeepSeek's own prices and the arithmetic does not line up. At a 90% hit rate on V4 Flash, blended input works out near $0.0165 per million against $0.14 all-miss, which is closer to one eighth than one fifth. One fifth implies a hit rate around 82%. There is no published benchmark, no methodology, and no repro script behind either figure. The direction is right and well-founded in DeepSeek's documented pricing. The precision is marketing.

The star count is a mess too. GitHub served 18.1k stars and 1.1k forks on the repo page during this session. Reasonix.io says 28,942 stars, 2,815 merged PRs, and 98 contributors. The README's own acknowledgments list nine people by name. None of those numbers are lies exactly, they are just measured at different moments by different systems, and it is a reminder to treat any single count on a fast-moving repo as a screenshot rather than a fact.

The provider bet is the real risk. This is a DeepSeek-native harness whose central advantage is a DeepSeek pricing behavior. Cache-hit pricing is a business decision, and if DeepSeek narrows that fifty-times gap, the architecture is still fine engineering and the headline advantage evaporates overnight. The config-driven provider layer means you can point it elsewhere, but pointing it at a provider without aggressive prefix pricing means you kept the constraint and lost the payoff.

The cache is best-effort by DeepSeek's own admission. No guaranteed hit rate, construction takes seconds, and unused cache clears automatically within hours to days. So "leave it running" works within a working session and does less for you across a weekend.

Maturity is mixed. Version 1.0 is a ground-up rewrite in Go on the main-v2 branch, the 0.x TypeScript line is legacy and maintenance-only, and anything you learned about the old version is stale. The repo showed 163 open issues and 106 open pull requests. The bash sandbox is macOS-only right now, with Linux bubblewrap support listed as still to come, so on Linux and Windows bash runs unconfined and the permission rules are your only control.

None of that is disqualifying for a tool you run on your own machine against your own key. It is disqualifying for treating the marketing numbers as measurements.

What I would take from this repo even if I never installed it is the framing. We have spent a year arguing about which model to route to, and the more useful question for anyone running long agent sessions is whether the harness is rebuilding its prompt from scratch every turn without telling you. That is a design property you control. Go read your own loop and find out what it does to the first two thousand tokens between calls.

Sources: esengine/DeepSeek-Reasonix README; reasonix.io; DeepSeek Context Caching docs; DeepSeek Models and Pricing.