Dao Code: a DeepSeek V4 terminal coding agent built around cache economics

The problem Dao Code picks: agent quality is usually bought with model price

Most terminal coding agents assume you will pay top-tier model rates. Claude Code needs an Anthropic account and network access, which the README calls a high bar to use out of the box in mainland China. GLM's Coding Plan is described as having scarce quota. Dao Code takes the opposite position: keep the model cheap and put the engineering effort into the request shape instead.

The target user is a developer in a terminal who wants read, edit, run and self-review loops on real repositories, and who cares about the per-task bill. The README is explicit that the project is Chinese-first and inspired by Claude Code, and that it builds on DeepSeek's register-and-go, pay-as-you-go access rather than on a waitlist. If your constraint is model quality above all else, this is not the pitch. If your constraint is that the agent has to be runnable and affordable on every task, the pitch is coherent.

The cost argument is stated with numbers: DeepSeek's prefix-cache hit price is given as roughly 1/120 of a miss. That single ratio explains almost every design decision in the codebase.

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

DeepSeek bills cached prefix tokens far below uncached ones, so the agent's job is to never invalidate the prefix. Dao Code keeps the system prefix, the tool table and the memory block byte-stable across turns. Anything that would rewrite those bytes costs money on every subsequent turn, so the project pushes variable work elsewhere.

Reflection and memory run as forks that reuse the main prefix cache. In practice this means the agent can invoke a self-review pass or write a memory entry without paying a cold-start price for the whole conversation prefix. The README states these forks do not break the prefix. That is the central engineering claim, and it is also the part a reader should verify rather than assume.

Context growth is handled by auto-compaction: a reactive retry when the limit is hit, in-place clearing of stale tool results, an incremental summary, and a hard-truncate fallback if the summarizer itself fails. Oversized tool output spills to disk and leaves only a pointer in context. The README does not document what the user sees when hard truncation triggers, which is a gap worth knowing about before you run long autonomous sessions.

Two slash commands expose the mechanism. /cost reports hit rate and spend. /audit cache uses a four-dimension fingerprint to identify what broke the cache. Those are the observability hooks for the whole cost model.

Installing dao from npm and running a first task

The package is published on npm as dao-code, and package.json declares bin as dao pointing at dist/index.js. Node 20 or newer is required. The repository also ships install.sh and a bundle:install script that compiles a standalone binary with bun and copies it to $HOME/.local/bin/dao.

Start with the npm route so you get the published build:

npm install -g dao-code
dao

Running dao opens the Ink terminal UI. The README describes a taiji welcome screen and streaming reasoning plus tool calls behind an approval gate. You will need a DeepSeek API key configured before the first request succeeds; the README does not spell out the exact environment variable name in the excerpt available, so check the configuration section of the project docs rather than guessing.

If you would rather build from source, the dev script runs the TypeScript entry point directly:

npm install
npm run dev

The cache acceptance script is the first thing worth running on a live key, because it demonstrates the mechanism the project is built around:

npm run accept:cache

According to the README, this runs a multi-turn conversation against the live API so you can watch the hit rate climb from a cold start to steady state. It is described as a mechanism demo, not as the source of the cost figures. The cost figures come from the eval suite under evals/runs/, and /cost replays them.

What the eval numbers do and do not prove

The README reports 7 SWE-bench-style tasks drawn from valibot, date-fns, es-toolkit, sqlglot and hono, totalling 3,886,037 input tokens at a 95.8% aggregate cache hit rate, 85.4% to 97.7% per task. It states the full seven-task run cost ¥1.07, with individual features at ¥0.07 to ¥0.21 and an average of ¥0.15. It also states that pricing the same token trace at Claude Opus 4.8 and Sonnet 4.6 rates comes out roughly 30x and 18x more expensive respectively, crediting the high hit rate to Claude as well.

Read that comparison carefully. It is a repricing of one token trace, not a head-to-head task run. The README says so directly: multiples are USD-on-USD and exchange-rate-independent. What it demonstrates is the arithmetic of cache pricing. What it does not demonstrate is that a different agent would produce the same trace on the same tasks.

Separately, the README reports 13/14 solved on a SWE-bench-style set with dual-track fail2pass and pass2pass judging and test files hidden from the agent, and 70/89 (78.7%) on Terminal-Bench 2.1 via Harbor with deepseek-v4-pro at the benchmark's official 1x timeout. The project attributes its Terminal-Bench progress to evaluation-driven engineering: reading failure traces and fixing framework bugs rather than tuning prompts. That is a plausible process claim, and the evals/ directory is where you would confirm it.

Memory that re-verifies itself, and where the documentation thins out

At session end Dao Code distills preferences, project conventions and key facts. At startup it verifies those entries against the current code, dropping stale ones and flagging changed ones instead of appending history indefinitely. A decay GC removes dead memories, and the model can call memory_read on demand. The README's own framing of the alternative is blunt: other agents remember, but misremember.

This is the most interesting idea in the project and the least specified. The README says verification is deterministic, which implies checks that do not depend on model judgement. It does not say what happens when a memory references a file that has been renamed, or whether a flagged memory blocks startup or is merely surfaced. The scripts verify:mem, accept:mem and debug:distill exist in package.json, so the machinery is testable, but the user-facing behaviour on conflict is not described in the excerpt available.

The priority order is stated as a constitution: safety and truth first, then your current instruction, then Dao Code's core policy around model and cache discipline, then skills and memory. The README notes that a third-party skill can change how work is done but never the safety and cache bottom line. That ordering is what makes installing arbitrary skills less alarming than it would otherwise be, and it is worth reading the actual prompt in src/ before you rely on it.

When Dao Code is the wrong tool

The cache strategy is the product, and it only pays off on DeepSeek. Point the agent at a provider without comparable prefix-cache pricing and the byte-stability engineering buys you nothing while the fork-based reflection and memory layers still add turns. The README does not present a multi-provider story, and the cost tables are all DeepSeek V4 Pro rates.

Long autonomous runs are the second boundary. Auto-compaction has a hard-truncate fallback for when the summarizer fails, which means the failure mode is context loss rather than a clean stop. If your work depends on the agent holding a large, precise context for hours, a fallback that discards content is a real risk, and the README does not document how it is surfaced.

The third boundary is ecosystem maturity. Dao Code is Claude Code config compatible, which the README lists as a feature, so Skills, MCP and Hooks configurations may carry over. Compatibility with another tool's config format is a convenience, not a guarantee that every hook or skill behaves identically under a different priority order and a different approval gate.

The real alternative, and how the approaches differ

Claude Code is the comparison the README itself invites. The difference is not feature count; it is where the engineering budget goes. Claude Code pairs a top-tier model with a polished harness and assumes you can reach Anthropic. Dao Code pairs a cheap model with a harness whose main job is to keep the prefix byte-stable and to run auxiliary work on cache-reusing forks.

That changes what breaks. In a top-tier-model setup, a badly shaped request costs more but the model still compensates. In Dao Code, a prefix invalidation is the expensive failure, which is why /audit cache exists and why the constitution puts cache discipline above skills and memory. You are trading model headroom for request discipline.

A second alternative is simply using DeepSeek through a generic agent framework. You would get the low token price but not the byte-stable prefix, the cache-reusing forks, the self-verifying memory or the compaction ladder, since those are implemented in this repository rather than provided by the model API. Whether that trade is worth it depends on how much of your bill is cache hits, which is exactly what /cost tells you.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-09. The most recent release listed is v0.4.7 on 2026-07-18, while package.json on master reads version 0.5.1, so the published npm package and the tagged releases are not moving in lockstep. Check which version you actually installed before comparing behaviour against the changelog.

Dao Code is MIT licensed. That permits commercial use, modification and redistribution with the licence and copyright notice preserved. It says nothing about your obligations to DeepSeek as a separate service provider, and nothing here is legal advice; the LICENSE file in the repository is the authoritative text.

Upgrade cost is dominated by one file: DAO.md sits at the repository root alongside README.md and CONTRIBUTING.md. If your project conventions live in memory and in that file, a change to how memory is distilled or verified is the upgrade that will affect you most. The scripts verify:mem and accept:mem are the checks to run after bumping the package, since they exercise the layer that persists across sessions.

Editorial conclusion

Adopt Dao Code if you already have a DeepSeek API key, work in a terminal, and want cross-session memory without paying full input price on every turn. Skip it if you need a vendor-neutral agent or cannot accept that the memory verification and reflection layers are the parts least documented in the README. Before committing, run npm run accept:cache to watch the hit rate climb on your own key, and read src/ to see how compaction behaves when the summarizer fails.

Frequently asked questions

Official sources

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