Dao Code: a DeepSeek V4 terminal agent built around prefix-cache discipline

The problem Dao Code actually targets: agent cost under a cache-priced model

Most terminal coding agents assume the model is the expensive part and the orchestration is free. Dao Code inverts that assumption. It is built for DeepSeek V4, where the README states the prefix-cache hit price is roughly 1/120 of a miss. When a hit costs two orders of magnitude less than a miss, prompt structure stops being a style question and becomes the main cost lever. Anything that perturbs the system prefix, the tool table, or the memory block turns cheap cached tokens into full-price tokens for the rest of the session.

The project's stated audience is developers who want a Claude Code style workflow but cannot rely on an Anthropic account or network access, and who do not want to compete for quota on a subsidised plan. The README frames this as availability rather than ideology: DeepSeek is described as register-and-go and directly reachable in mainland China. The second audience is cost-sensitive: anyone running long autonomous sessions where input tokens dominate the bill.

That framing matters for evaluation. Dao Code is not trying to be the most capable agent on any single benchmark. It is trying to make a cheap model behave like an expensive one by never wasting a cache hit.

Byte-stable prefixes and cache-reusing forks: the actual mechanism

The core mechanism is prompt stability. The README states that Dao Code keeps the system prefix, the tool table, and the memory block byte-stable so DeepSeek's prefix cache can hit on the longest possible span. Reflection and memory operations run as forks that reuse the main prefix cache rather than starting a fresh conversation with a new prefix. In other words, the self-correction layer and the cross-session memory layer are designed to add almost no token cost, because they ride on a prefix that is already cached.

Around that sit several context-management behaviours the documentation describes. Near the context limit the agent auto-compacts using a reactive retry, in-place clearing of stale tool results, an incremental summary, and a hard-truncate fallback if the summariser fails. Oversized tool output spills to disk with only a pointer left in context. Memory is distilled at session end, then deterministically verified against the current code at startup: stale facts are dropped and changed facts are flagged. A decay GC clears dead memories, and the model can call memory_read on demand.

The README also describes a constitution-style priority order: safety and truth, then the current instruction, then Dao Code's core policy covering model and cache discipline, then skills and memory. The claim is that an installed third-party skill can change how work is done but cannot override the safety and cache bottom line. That is a design commitment worth noticing, because it means a skill that would improve answers by rewriting the system prefix is deliberately constrained.

Getting it running: the commands and config surface named in the README

The package is published on npm as dao-code and installs a command called dao. The README does not spell out a full install invocation in the material available here, so the concrete entry points I can point at are the ones it does name. npm run accept:cache runs a multi-turn conversation against the live API so you can watch the cache hit rate climb from a cold start to steady state. The README is explicit that this is a mechanism demonstration and that the published cost figures come from the separate eval suite, not from this script.

Inside a session, two slash commands carry the operational weight. /cost reports hit rate and spend. /audit cache is described as pinpointing what broke the cache, using a four-dimension fingerprint. If you are evaluating Dao Code for a team, those two commands are the ones that turn the architecture claim into something you can check on your own traffic rather than take on faith.

Configuration compatibility is stated as Claude Code compatible, with Skills, MCP and Hooks supported. The README does not enumerate the config file paths or key names, so I cannot give you a config snippet without inventing one. The practical consequence is that existing Claude Code skills and MCP server definitions are intended to carry over, but you should confirm the exact file locations against the repository before assuming a drop-in migration.

What the published evaluation does and does not establish

The README reports two evaluation tracks. The first is a SWE-bench-style set drawn from recent open-source bug fixes in valibot, date-fns, es-toolkit, sqlglot and hono, judged on dual-track fail2pass and pass2pass with test files hidden from the agent. Seven tasks, 3.89M input tokens, 95.8 percent aggregate cache hit rate, and a stated total of ¥1.07 at DeepSeek V4 Pro pricing. The README says every figure traces to evals/runs/<task>/run-1/agent.log and can be replayed with /cost. A separate line reports 13/14 solved reliably on a broader SWE-bench-style set.

The second is Terminal-Bench 2.1, described as 89 third-party agentic-coding tasks run through Harbor, spanning sysadmin, security, data science, scientific computing, debugging and ML. The reported result is 70/89, or 78.7 percent, with deepseek-v4-pro at the benchmark's official 1x timeout.

The cost comparison table prices the same token trace under Claude Opus 4.8 and Sonnet 4.6 official rates, crediting Dao Code's hit rate to Claude as well, and reports roughly 30x and 18x differences. Read that carefully: it is a re-pricing exercise on an identical token trace, not a head-to-head run of Claude Code on the same tasks. The README says so plainly. It is a fair way to isolate the price-per-token difference, and it is not evidence that the two agents produce the same output quality. The benchmark scores are the place to look for that, and the README does not report a Claude Code score on the same task set.

Where the cache-first design becomes a liability

The central constraint is the same thing that makes the project cheap: the prefix must stay byte-stable. Any component that injects variable content into the system prefix, the tool table, or the memory block risks collapsing the hit rate for the remainder of the session. That is a real failure mode, and the existence of /audit cache with a four-dimension fingerprint is an admission that it happens. A tool description that changes between turns, a memory entry rewritten mid-session, or an MCP server that returns a timestamp in its schema can each cost you the discount.

The second limitation is model lock-in. Dao Code targets DeepSeek V4 specifically. The 1M context window, the cache pricing, and the constitution's cache discipline are all calibrated to that provider. If your organisation requires a different vendor, or needs to switch models per task, the architecture's main advantage does not transfer. You would be running a terminal agent whose defining feature is inert.

The third is that this is a young project. The release history in the material shows v0.4.0 through v0.4.7 between late June and mid July 2026, with the repository last pushed in September 2026. That is a fast-moving 0.4 line. The README also notes that the Terminal-Bench iteration involved fixing framework bugs surfaced by reading failure traces, which is honest but also tells you the framework had bugs to fix at that point. There is no long-term stability record here to lean on.

Alternatives and the real difference in approach

The obvious comparison is Claude Code, which the README names as its inspiration. The difference is not features, since Dao Code advertises Claude Code config compatibility and similar Skills, MCP and Hooks support. The difference is where each puts the engineering effort. Claude Code assumes a model priced high enough that orchestration overhead is a rounding error, so it can afford generous context and frequent fresh calls. Dao Code assumes the opposite and spends its complexity budget on keeping the prefix reusable. That is why memory verification, reflection and compaction are all implemented as cache-reusing forks rather than as separate model calls.

A second alternative is a general-purpose agent framework where you bring your own model, such as wiring an OpenAI-compatible client into an existing CLI agent. That gives you provider freedom and no opinionated cache discipline. The trade-off is that you own the prompt-stability problem yourself. If you swap models or restructure prompts casually, you pay full price on every token, and the 1/120 hit ratio the README cites simply never materialises for you.

A third path is staying on a subsidised coding plan from another vendor. The README's argument against that is quota scarcity rather than capability. If your plan has quota you can actually use, the availability case for Dao Code is weaker, and the decision reduces to whether the cost-per-task difference matters at your volume.

Licence, maintenance and what to verify before adopting

Dao Code is MIT licensed. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are preserved. It does not grant trademark rights, and it comes with no warranty. This is not legal advice; check the LICENSE file in the repository if your organisation has specific requirements, particularly if you plan to redistribute a modified build.

Maintenance cost is the part the material supports least. The repository is active, not archived, with a 0.4.x release cadence in mid 2026 and a push in September 2026. There is CI configured via GitHub Actions, and the README invites pull requests. What is not visible here is a contributor base, a deprecation policy, or a compatibility guarantee across the 0.4 line. For a tool that sits between you and your editor, that matters. Pinning a version is the reasonable default until the project signals a stable interface.

The upgrade cost has one specific dimension worth naming. Because cache discipline is enforced at the framework level, a version bump could change the system prefix or tool table layout and reset your cache behaviour. That is not a breaking API change in the usual sense, but it is a change you would feel in /cost. Running npm run accept:cache after an upgrade, and checking /audit cache on a real session, is the concrete way to detect it. The verification step is cheap and the failure is otherwise silent.

Editorial conclusion

Adopt Dao Code if you are already paying for DeepSeek V4, work from a terminal, and want cross-session memory and a self-review pass without watching token spend climb. Do not adopt it if you need a vendor-neutral agent or cannot accept a DeepSeek dependency. Before committing, run npm run accept:cache to watch the hit rate climb on your own account, then replay a task with /cost and /audit cache to confirm the prefix stays byte-stable under your own skills and MCP servers.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tigicion/dao-code on GitHub