Why this lesson exists
Everything up to now has been the model. This lesson introduces the thing that turns the model into a worker: a coding agent harness built specifically for DeepSeek. Understanding why it was designed the way it was is what makes the rest of Module 7 make sense.
What a coding agent harness is
From Lesson 7: a harness supplies the tool loop, filesystem access, command execution and context management that a bare API call lacks. Reasonix is one of those, and it is unusual in one specific way.
Most coding agents were built for a different model family and reach DeepSeek through a translation layer — they convert their native request format into something DeepSeek accepts, and convert the response back. Reasonix talks directly to api.deepseek.com. There is no Anthropic markup, no OpenRouter middleman, no format mapping.
Why that matters more than it sounds: a translation layer can only preserve the intersection of two APIs. DeepSeek-specific features — the thinking controls, cache accounting, the response fields that tell you what actually happened — tend to be flattened or dropped on the way through. A native client can use all of them.
The one-line version: Reasonix is a DeepSeek-native terminal coding agent — a worker that reads your files, writes code, runs it, and iterates, with no translation layer between it and the model.
The design idea: cache-first
This is the part worth understanding properly, because it is the design decision that everything else in Module 7 flows from.
Go back to Lesson 6. A cache hit costs one-fiftieth of a cache miss. In a coding agent session, the context is enormous and it is sent again on every single step — file contents, tool output, conversation history, thinking traces. If that context is unstable, every step pays full price and the session becomes expensive fast. If it is stable, the whole session runs on hits.
Reasonix is explicitly engineered around prefix-cache stability. The project describes it as an agent you can leave running, and the design choices follow directly from that goal:
- Prompt prefixes are kept stable so the cached portion survives across steps.
- Startup injects a small, stable environment summary rather than a large volatile one — a stable summary caches; a changing one destroys the prefix.
- Stale tool output is pruned before compaction, so the context shrinks without reordering the stable region.
- Tool schemas are treated as a contract with documented regression review — because changing a schema changes the prefix and invalidates the cache.
The observable result is a cost profile that is genuinely hard to believe until you see it. A full single-file build — the model reading a brief, composing a page, writing it, running checks — has been measured at well under a cent, because the overwhelming majority of those tokens were cache hits.
The counter-intuitive consequence
In most systems, "make the context smaller" is the optimisation. In a cache-first harness, "keep the context stable" is often the better one. A large stable prefix that caches is cheaper than a small prefix that changes every step. Once you internalise this, you will start designing prompts for cacheability in every harness you touch, not just this one.
What it can do
| Capability | What it means in practice |
|---|---|
| Read a brief and build | The core workflow. Point it at a spec file and a directory; it reads, writes and iterates. |
| Run commands and react | It can execute tests and builds, read the failure, and fix. This is the iteration-against-reality loop. |
| Multi-step runs | Bounded by a step cap you control, with state persisted so a paused run can continue rather than restart. |
| Code review | A dedicated review mode over local git diffs. |
| Session and cost management | Inspect sessions, tasks and spend from the CLI. |
| Multiple surfaces | Terminal, desktop app, browser, and ACP-compatible editors share the same local engine. |
| Model accounting | Reports token, cache and cost receipts against the official price table, so you can see whether a run was cheap and why. |
It is open source under a permissive licence, and — useful signal — DeepSeek documents it in its own agent integration guides alongside general-purpose coding tools. It is not a random community script.
Why this course uses it
Three reasons, in order of importance to you:
- It makes the rest of the course affordable to practise. A cache-first harness on off-peak pricing means you can run real builds, repeatedly, for amounts of money you do not have to think about. That changes how much you are willing to experiment.
- It enforces the right structure. Because you hand it a directory and a brief, it pushes you toward the two things that make agent builds work — a written spec and a verifiable artifact. Those are the skills Modules 5 and 6 are teaching anyway.
- It teaches the model's real behaviour. Running a native DeepSeek client means you see DeepSeek's actual thinking traces, cache accounting and failure modes — not a translated approximation of them.
What it is not
Be clear-eyed, because over-trusting a harness is its own failure mode:
- It is not a substitute for a spec. A vague instruction produces a vague build at machine speed. The harness amplifies whatever clarity you bring.
- It is not a verifier. It reports what it believes it did. Lesson 25's rule applies unchanged: its summary is a claim, and you own the acceptance test.
- It is not free of failure modes. Permission defaults, environment quirks, and a tendency to refactor beyond instructions are all real and all covered in the next four lessons.
- It is not the only option. It is a very good default for DeepSeek work. Lesson 34 covers when to route elsewhere.
Checkpoint
- What does "DeepSeek-native" mean here, and what does it avoid?
- Why is a stable prefix more valuable in a coding agent than in a single API call?
- Why would pruning stale tool output be done before compaction rather than after?
- Name two things the harness does not do for you.
Answers
- It calls
api.deepseek.comdirectly, avoiding a translation layer that would flatten DeepSeek-specific features and accounting. - A coding session resends a large context on every step. Stability means those steps run as cache hits at one-fiftieth the price instead of full price each time.
- To shrink the context without disturbing the stable leading region — reordering would invalidate the cached prefix.
- It does not replace a written spec, and it does not verify its own work independently. It also cannot decide what you actually wanted.
Exercise: place it in your own stack
Without installing anything yet, write answers to three questions.
- Which project on your machine would benefit most from an agent that can read files, edit them, run tests and iterate? Name the actual directory.
- What is the concrete deliverable that directory would gain — an artifact another person could receive?
- What could go wrong if you gave that agent write access and shell access with no supervision? Be specific about the worst plausible outcome.
Question three is not a formality. Your answer determines the permission mode you will choose in Lesson 28, and answering it honestly now is what makes that choice a decision rather than a default.
Next
Lesson 27 installs it, configures it, and deals with the environment trap that eats most people's first session.