Original URL: https://getagenttools.com/blog/deepseek-harness/ # DeepSeek Harness: everything is a plugin, except the parts that are not 13 Aug 2026Marek. - agent-harness - coding-agents - open-source DeepSeek open sourced its agent harness today under an MIT license, and the pitch is that everything is a plugin: models, tools, skills, sessions, sandboxes, storage, loops, scheduling and the UI. That is the headline everyone is repeating. The architecture documents say something more useful, and more honest: most of it is swappable, four services are not, and the short list of what you cannot replace is the real shape of the product. - **What it is.** `dsh`, an open-source agent harness from DeepSeek, MIT licensed, in developer preview, started with one `npx` command. - **The idea.** Capabilities are plugins on a framework called Cordis, so you select, swap or extend them in configuration instead of forking the source. - **The spine.** Four services have one owner and no alternative implementation, and the session log is one of them. That is where the architecture actually lives. - **The rule worth stealing.** Model-visible means logged: anything that reaches a model request has to be reconstructable from an append-only log. - **The verdict: WATCHING.** Breaking changes are promised in writing, and I have not run it. The harness carrying real work here is [Claude Code](https://getagenttools.com/tools/claude-code/), and the last time a lab shipped one of these I went through [what Meta put in Muse Code](https://getagenttools.com/blog/muse-code-agent-harness/). ## What is DeepSeek Harness? DeepSeek Harness, `dsh` on the command line, is an open-source agent harness released in developer preview on 13 August 2026 under an MIT license. A [harness](https://getagenttools.com/blog/what-is-an-agent-harness/) is the software around the model: the loop that decides what happens next, the tools the agent may call, the approvals it has to ask for, and the record of what it did. I unpacked that definition in [the Muse Code post](https://getagenttools.com/blog/muse-code-agent-harness/) and will not repeat it here. It needs Node and starts with one line, which serves a web UI on `127.0.0.1:3080`: ```bash npx @deepseek-ai/dsh web ``` From source it is pnpm: ```bash git clone https://github.com/deepseek-ai/deepseek-harness.git cd deepseek-harness pnpm install pnpm run build pnpm dsh web ``` The [README](https://github.com/deepseek-ai/deepseek-harness) carries a warning in capitals: THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Read that as a schedule, not as boilerplate. One piece of context the launch posts mostly skip. The harness is free, the model is not. DeepSeek raised API prices in the same week, effective 16 August 2026, and [the numbers](https://the-decoder.com/deepseek-launches-an-improved-v4-pro-model-raises-api-prices-and-makes-its-agent-software-open-source/) are not small: off-peak V4-Pro input goes from $0.435 to $0.66 per million tokens, output from $0.87 to $1.98, cache hits from $0.003625 to $0.022. Peak rates are double the off-peak ones. An MIT harness that keeps the model behind a swappable interface is worth more to the person paying that bill, not less, and the pricing move is a decent argument that the swap is meant to be used. ## Everything is a plugin, except the four services that are not The marketing line is that everything is a plugin. The architecture doc is more precise, and the precision is the part you want. It sorts services into three kinds: seams, which are interfaces with more than one interchangeable implementation; core services, which have a single authoritative owner and no alternatives; and composition points that aggregate other services. Four names sit in that middle group: `ctx.sessions`, `ctx.invariants`, `ctx.typert` and `ctx.agents`. The doc calls them architectural spine points. You can replace the model adapter, the shell, the filesystem and the approval gate, and the thing still runs. Take out the session log and there is no product left, because every other promise in the design leans on it. That is not a complaint. Every system claiming full modularity has a spine, and most of them do not tell you where it is. This one publishes the list on day one. If you are weighing a harness to build on, that list is the first page to read, because it is the set of decisions you adopt permanently. Swappable seams like ctx.llm and ctx.shell sit next to four core services the harness keeps as its fixed spine The seams on the left ship with more than one implementation and swapping one leaves every consumer untouched. The four on the right have a single owner and no alternative. The cordis tools add plugins while a session runs, and ship switched off. ## What can you actually swap in DeepSeek Harness? The seams are named services that ship with more than one implementation. The ones that change how the thing behaves in practice: | Seam | What it decides | Implementations named in the docs | | --- | --- | --- | | `ctx.llm` | which model answers | deepseek, pi-ai, replay | | `ctx.shell` | how a command runs | bash-local, bash-sandbox, pwsh-local | | `ctx.fs` | which filesystem it touches | fs-local, fs-sandbox, fs-e2b | | `ctx.subprocess` | where processes execute | local, e2b sandbox | | `ctx.storage` | where state persists | storage-json, storage-sqlite | | `ctx.sessionPersistence` | how the log survives | jsonl, sqlite | | `ctx.web` | how it searches and fetches | exa, perplexity, deepseek, fetch-http | | `ctx.approval` | what needs a human | acp bridge | Read that as a blast radius control panel rather than a feature list. Moving `ctx.shell` from `bash-local` to `bash-sandbox` changes what an agent is able to destroy, and the tools calling it do not change at all. The doc says it plainly: sandboxed, remote or PowerShell executors replace `bash-local` without touching the bash tool or any other consumer. There is a second-order effect worth naming. The filesystem and subprocess providers share one execution world, so moving to a remote sandbox moves both together. That is the right behaviour and it is easy to get wrong. A setup where the shell runs in a container while file reads still hit the laptop is a setup where the isolation is decorative. `ctx.approval` being a seam is the line I would look at first. Approval is where "the agent asked me" lives, and making it swappable turns the answer to "what needs a human here" into configuration instead of source code. Same principle as every campaign my automation creates through the [Meta Ads API](https://getagenttools.com/tools/meta-ads-api/) arriving paused: the gate is a property of the setup, not a habit of the operator. ## The session log rule: model-visible means logged This is the sentence I would take even if I never install the thing. The doc states it as "model-visible means logged": anything that reaches a model request has to be reconstructable from the append-only log. `ctx.sessions` owns that log, it is a core service rather than a seam, and the doc says fork, resume, replay and telemetry all fall out of it without extra machinery. Last week I wrote that the append-only event log in Meta's Muse Code was the part I would copy first. DeepSeek went a step further. Logging is not a feature sitting next to the runtime here, it is a rule about what the runtime is allowed to do, and everything a model can see is inside the log by definition. The practical difference shows up on a bad day. With logging as a feature, you learn what was missing when you replay a failed run and the reconstruction does not match. With logging as an invariant, a message that cannot be logged cannot be sent. That is the gap between an audit trail you hope is complete and one that is complete by construction, and it matters the moment an agent goes near anything that spends money. The vocabulary is tighter than most too. A turn is one drain of admitted input, ending after the model and its tools stop or a policy intervenes. A step is one model request plus the tool executions its response causes, and a turn holds zero or more steps. Boring definitions. Boring definitions are what let two people argue about a bug without arguing about words first. ## The cordis tools let an agent extend its own runtime Seven tools ship in a package called `@deepseek-ai/dsh-tool-cordis`: `cordis_define`, `cordis_run`, `cordis_inspect_list`, `cordis_inspect_query`, `cordis_inspect_self`, `cordis_stop` and `cordis_undefine`. In plain terms the agent can define a plugin, activate one exact package of it, list what is loaded, run read-only queries against it, stop the run and permanently remove it. Inside its own session, while working. The catalog also says where they are, and the phrasing does the work: not in any shipped tree, a deliberate opt-in, because dynamic package code reaches the real runtime. A composition that leaves the package out never activates the tools. I would leave that switch alone, for the reason DeepSeek put in the parenthesis. Every guardrail I run assumes the tool surface is fixed when the session starts: the deny lists, the approval prompts, the reviews. A tool that can add tools is a tool that can add one outside all of them. That is not a flaw in the design. It is a capability with a large blast radius, shipped switched off and labelled as such, which is close to the most honest way to ship one. The signal is still real. The distance between what an agent does and what an agent runs on gets shorter every release, and this is the first harness I have read where the agent gets a documented, named handle on its own composition. Worth reading. Not going anywhere near production. ## How DeepSeek Harness is configured: bundles, profiles and patches A running instance is a stack of ordered layers. Bundles are the distribution format, Cordis configuration plus code. Profiles are named compositions stored locally that list the bundles in play and the user's patches. Patches are overlays targeting specific rows. They apply in one order: bundles, then the profile, then home, then CLI flags. A base bundle, `dsh-base`, brings the model adapters, tools and persistence, and other bundles add the web interface or a headless runner. Every plugin publishes a config type and the runtime validates against it, so a field a plugin does not expose cannot be set in `cordis.yml` at all. Invalid values fail when the plugin loads, with a diagnostic, instead of falling back to something quiet and wrong. Settings live under `$DSH_HOME` or `~/.dsh`. There are also permission presets that pair a sandbox mode with an approval policy: workspace-write with ask, full access with never, or your own combination. That pairing is the right shape. Sandbox mode and approval policy are two halves of one decision, and setups that store them apart drift into a permissive value of each. [DeepSeek's own page](https://www.deepseek.com/harness/en/) lists four ways to run it: a standard mode with the full toolset, a code mode driven by model-generated TypeScript, a minimal mode for benchmarking, and a creator mode for custom presets. ## DeepSeek Harness vs Claude Code The honest comparison is short, because I run one of these daily and have not run the other. [Claude Code](https://getagenttools.com/tools/claude-code/) is the harness doing real work here. DeepSeek Harness is a developer preview with a written promise of breaking changes. Within a release or two the feature lists will look similar, and the feature list was never the decision anyway. What you actually choose is where your rules live. Changing harness means moving the approvals, the deny lists, the directories that stay off limits and the muscle memory of someone who has typed the same command a thousand times. The install takes five minutes. The rules are the switching cost, and they do not travel by copying a config file. Where DeepSeek is different today is ownership. The whole codebase under MIT, with the model sitting behind a swappable interface. If your concern is being tied to one vendor's assumptions about how an agent should behave, that is a real answer rather than a marketing one. Whether the thing is any good is a separate question, and it needs a run. One more thing for anyone pointing an agent at real systems: reach. A harness stops being a coding tool the moment it can touch your files, analytics, hosting and email through [MCP servers](https://getagenttools.com/tools/mcp-servers/). This one is no different, and the plugin model makes that reach easier to add. Cuts both ways. ## Should you install DeepSeek Harness today? Install it if you are curious and it is nowhere near anything that matters. Build on it, not yet. The reasons are printed on the tin. Developer preview. Compatibility-breaking changes stated in capitals in the README. Core plugins and APIs will keep moving, by DeepSeek's own admission on the announcement page. Anything you write against the plugin API this month is work you may get to do twice. So the verdict is WATCHING, which on this site means it looks worth the time and has not carried real work yet. TESTED means it did a real job end to end at least once. The rules are in [the field notes post](https://getagenttools.com/blog/field-notes/), and a boring verdict beats a fast one. What I would do with a day on it: give it a job whose shape I already know, break it on purpose partway through, then read the log and find out whether "model-visible means logged" survives contact with a crash. That is the claim worth testing here. The rest of the architecture is a set of good ideas, and good ideas stay cheap until a run falls over. Put this into practice [See the tool list](https://getagenttools.com/tools/)[Train your team](https://getagenttools.com/#training)