DeepSeek Harness

You will like this if you already run on DeepSeek and want the official harness rather than a community wrapper: one npx command opens a local web UI, and the daily trait is plan mode with subagents, so you watch it draft the steps before it touches a file. It feels closer to a workstation than a chat box.

What you give up is polish and git: there is no git tooling, so commits are on you, and the browser tab is the whole interface. Pick it if DeepSeek is your model and you like working in a tab. Pick pi if you want a smaller harness you can read in an afternoon.

The risk is maturity. The README states the project is in developer preview and warns, in capitals, that there will be compatibility-breaking changes. The star count reads like a mature product. The release history does not. A harness that rewrites its plugin contract between versions turns every skill and config file you write into a migration.

The consequence: pin a commit, not a version, and keep your skills in your own repository. What it does right is the file sandbox on the shell plugins, which scopes what a command can touch instead of hoping the model behaves.

The architecture is documented at the level of a parts list. 1. Context is gathered through ripgrep search, file read and an LSP plugin, so symbol lookups come from the language server rather than the model's guess. 2. Actions run through tool plugins for edit, write and persistent terminals. 3. Composition is a config tree over the Cordis framework, which makes the tool set a declaration rather than a code change.

Verification is where the documentation thins: the docs site fetched as a bare title, the tool catalog link returned nothing, and a BENCHMARK.md is present without published numbers on the board. The design is principled; the evidence is pending.

DeepSeek does not need this to make money; it needs it to make DeepSeek the default key in the config. Give away the harness, sell the inference, and let the accounting land on the API line. There is no pricing power because there is no price, and the moat is only as deep as the model's cost advantage.

The interesting detail is the pi-ai route, a multi-provider door that lets users bring other vendors. A lab that lets you leave is either confident or hedging. Likely path: no acquirer, since the lab owns it; the pivot is the harness becoming the front door for whatever DeepSeek ships next. Position: use it as a DeepSeek client, not as a platform bet.

The demo is a local web UI that runs shell commands and delegates across an agent team. Procurement sees something else: sixty local web UIs on sixty laptops, keys in sixty config files, and nothing in the config catalog about SSO, SCIM or a central audit log. Headless mode exists, so a CI job is possible, but the agent-team mode is labelled experimental and the support channel is a GitHub issue tracker.

Cost is whatever DeepSeek bills for tokens, which is low, and onboarding is short if the engineer already knows a chat UI. The gap is governance, not capability. Not yet.

MIT and buildable from source with pnpm, which is the first test. The second is whether I can change it, and everything-is-a-plugin means yes: a tool is a plugin, a model route is a plugin, and the MCP client hangs my servers off the same tree. If I do not like the web search plugin I replace it rather than patch around it.

Where it loses me is model freedom. The routes are DeepSeek and pi-ai, and the board marks local models as unsupported, so my own hardware gets in only if pi-ai speaks to it. I could add a route; that is the point of the architecture. Grudging respect for the design, less for the defaults.