DeepSeek Shipped a Harness That Doesn't Need DeepSeek

August 21, 202612 min read

On August 13, 2026, DeepSeek open-sourced Harness — MIT licensed, developer preview, npx @deepseek-ai/dsh web. Within roughly two days it had crossed 95,000 GitHub stars.

Everyone immediately filed it as "the open-source Claude Code." That framing is wrong, and being wrong about it means missing the only part that actually matters.

Claude Code is a product. Harness is a runtime with no privileged center — including no privileged model. DeepSeek, a company whose entire business is selling tokens, shipped an agent framework in which DeepSeek's model is one swappable plugin among many, sitting at exactly the same level of privilege as Anthropic's, OpenAI's, Bedrock's, Vertex's, or whatever OpenAI-compatible endpoint you point it at.

No model vendor has done that before. Claude Code assumes Claude. Codex assumes GPT. Gemini CLI assumes Gemini. Every harness built by a model company so far has been, structurally, a funnel. This one isn't. That is the story.

Agent = Model + Harness: before and after the unbundling The whole argument in one picture. Every harness a model company shipped before this one was, structurally, a funnel.

First: what a harness even is

DeepSeek's own framing is the cleanest I've read: the model is the soul of an agent; the harness is everything that lets that soul act in the world.

Concretely, the harness is the thing that connects the model to a filesystem, a shell, an editor, the web, and other agents — while recording what it did and constraining what it's allowed to do. Agent = Model + Harness. Nothing else.

This matters because for the past two years the industry has been benchmarking souls while quietly competing on bodies. The gap between "GPT-5 in a chat box" and "GPT-5 in Codex" is not a model gap. It's tool design, context management, permission policy, and loop discipline. Everyone who has actually shipped an agent knows this. Almost nobody was willing to say the harness was the product, because saying so devalues the model.

DeepSeek just said it out loud, and then gave the body away.

The architecture: everything is a plugin, and the plugin kernel is borrowed

Cordis, or: DeepSeek did not invent this

Harness is built on Cordis — a plugin meta-framework whose central capability is disposability: load, unload and reload a plugin with complete cleanup of its side effects. Plugins contribute services, typed events, and reversible effects into a shared context.

Here's the detail almost every English write-up skipped: Cordis is not new and not DeepSeek's. It's an independent open-source project by the developer Shigma, and it has been the plugin kernel of Koishi — a chatbot framework — since 2019, where it accumulated on the order of 4,000 community plugins. DeepSeek vendored it in and co-published a paper formalizing the design.

I find this the single most instructive engineering decision in the whole release. DeepSeek looked at "build an agent runtime" and correctly identified it as a plugin lifecycle and dependency problem — a problem the Chinese bot-framework community had already spent six years and four thousand plugins beating into shape. So they took the solved part. Meanwhile a dozen VC-funded agent startups are writing their own plugin loaders from scratch this quarter.

Taste in what not to build is a real engineering skill, and it is scarcer than the ability to build.

The layers

  • dsh-base — model adapters, tools, persistence
  • dsh-web-app — the browser UI
  • dsh-headless — CLI-only

Composition is layered config: bundles apply in order, then the profile's cordis.patch.yml, then the home-level patch, then any --patch overlay from the command line. Any row can be targeted and replaced outright. The core packages hang off the context — ctx.sessions, ctx.agents, ctx.tools, ctx.systemPrompt, ctx.llm, ctx.shell, ctx.sandbox, ctx.approval.

Read that list again. The agent loop itself is a plugin. You can replace the thing that decides what happens next without forking the project.

DeepSeek Harness architecture: bundles mount into the Cordis kernel, which exposes ctx.llm, ctx.tools, ctx.agents, ctx.sessions and ctx.sandbox/ctx.approval; model adapters hang off ctx.llm as peers Bundles and patch layers compose the runtime, Cordis mounts them, and every capability shows up as a service on the context. Note the bottom row: DeepSeek's own model sits in the same slot as everyone else's.

Step vs turn

A step is one model request plus its tool calls. A turn is zero or more steps, opening before the first input and closing only when the obligations of that input are satisfied.

That distinction sounds pedantic until you've tried to bill, cancel, retry, or audit an agent. "One user message" and "one model call" are not the same unit, and almost every homegrown agent conflates them — which is why cancellation is broken in most of them, and why cost attribution is a mess.

One turn contains many steps; each step is a model request plus its tool pipeline, and every event is appended to the session log which projects back into model context A step is one model request. A turn is however many steps the input owes. Everything either side of that loop lands in the append-only log — which is then projected back into the context window rather than mutated in place.

The session log is the actual product

Harness keeps an append-only event log — turn/start, step/start, user/message, assistant/*, tool/*, step/end, turn/end — governed by one rule:

Model-visible means logged. Anything that reaches the model must be reconstructable from the log.

Model history is then derived from the log by projection functions, rather than being some mutable array a dozen code paths poke at.

I'd argue this, not the plugin system, is the most important design decision in the repo. It turns context engineering from vibes into a data structure. Every context injection has a recorded source. Trajectories become replayable. resume, fork, search and replay all become operations on one event stream instead of four bespoke features.

If you've ever debugged an agent that went insane on step 14 and had no idea what was actually in its context window at step 13 — this is the fix, and it's the part worth stealing even if you never run dsh.

Sandbox and approval are two different things

ctx.sandbox confines spawned processes. ctx.approval enforces policy. Policy attaches by listening on fs/*, tools/*, telemetry/* capability events — without importing the loop.

Most agent frameworks collapse these into one "are you sure?" prompt. They are not the same axis. What the process can physically touch and what the human has agreed to are orthogonal, and conflating them is how you end up with a tool that is simultaneously annoying and unsafe.

Credit where due, and a caveat: the filesystem sandbox does not currently govern network or process visibility. That's a real hole, and DeepSeek says so in their own docs.

The usage patterns that are genuinely new

1. Run Claude Code and Codex as subagents

Harness explicitly supports calling other coding agents as child agents. So the shape you can build is:

DeepSeek Harness orchestrates. Cheap fast model drives the loop. Claude Code gets handed the gnarly refactor. Codex gets handed the thing Codex is weirdly good at. Results come back into one session log.

DeepSeek Harness routing subtasks to V4-Flash, Claude Code and Codex subagents, all writing into one session log that supports fork, replay and trajectory inspection Routing by subtask, with three vendors' agents in the same run — and one event stream underneath all of them, which is what makes fork, replay and per-source context auditing possible at all.

This is the first mainstream harness that treats rival harnesses as tools. Strategically it is close to insolent, and practically it is the correct architecture: model quality per dollar varies wildly by subtask, and nothing about routing should be decided at signup time.

2. Fork the trajectory instead of restarting the chat

Because everything is one append-only stream, you can fork a run at step 9 and try three different continuations. This is git branch for agent behavior — and it quietly makes prompt and tool changes testable: replay the same trajectory against a modified tool schema and diff what happens.

The industry has been shipping agents with no regression suite. This gives you the substrate for one.

3. Audit context by source

The Trajectory view lets you inspect every record by where it came from: system prompt, reasoning, tool result, subagent scheduling, injected context. When your agent degrades over a long session, the cause is almost always something put into the window, not the model getting dumber. Being able to point at the offending injection is the difference between engineering and superstition.

4. Headless in CI, Web UI from your phone

dsh-headless makes the same composition run as a CI worker; the web app makes it something you can drive remotely. Same session log underneath. The "agent as a long-running background process I check on" pattern gets much cheaper here than in a terminal-first tool.

5. Write your own loop

The strongest reason to care. If your domain needs deterministic orchestration — this step, then that step, always, with the model filling gaps rather than choosing the path — you don't fight the framework, you replace the loop plugin.

That is the real philosophical split with Claude Code: Claude Code gives the model autonomy; Harness gives the developer determinism. Both are legitimate. They are not the same product, and pretending they compete head-on is how you pick the wrong one.

What it actually means

The bundle everyone accepted is being broken up

For two years, adopting a model meant adopting a harness, and adopting a harness meant adopting a company. Your prompts, your tool definitions, your permission policy, your session history — all of it lived inside somebody's product.

Notice where the switching cost really was. It was never the model; models swap behind an API in an afternoon. The lock-in was always the body, never the soul. Harness is the first serious attempt by a model vendor to make the body portable, and once portability is the default expectation, every closed harness has to justify itself on quality rather than gravity.

DeepSeek is commoditizing its complement — one layer up

This is the same move as open-weights, played at a different altitude. If harnesses are free and interchangeable, competition moves back to price-per-token and capability-per-token — the axis where DeepSeek has spent its whole existence winning.

And the timing is the tell. In the same window as this "free and open" release, DeepSeek raised V4-Pro API pricing sharply — peak-hour output went from roughly $0.87 to $3.96 per million tokens. Free harness, more expensive tokens, same week.

That is not hypocrisy, it's a thesis: margin lives in inference; the harness is distribution. Anyone reading the stars as pure altruism is reading the wrong artifact.

There's a real cost to the choice, too. A locally-run MIT harness sends DeepSeek no trajectory data — and agent trajectories are among the most valuable training and eval assets in existence right now. DeepSeek traded visibility for default position. If you believe agentic RL is where the next capability jump comes from, that trade is either brave or expensive, and we won't know which for a year.

If you're building on top: don't build a harness

The clearest practical takeaway. Harness infrastructure is now a commodity with a credible free implementation, a plugin kernel with six years of production history, and a vendor incentive to keep it free forever.

Your durable layer is the plugins: domain tools, evaluated skills, permission policy that matches how your organization actually works, and the trajectory data your own users generate. That's the Cinema Studio lesson again in a different costume — own the part that survives the model swap, not the part that gets commoditized by the next release.

And now the cold water

95,000 stars in two days measures agreement with an idea, not adoption of a codebase. It's a vote about the model-agnostic thesis, cast by people who mostly haven't run it.

The honest status: developer preview, explicitly unstable APIs, breaking changes promised, hot-swap not actually implemented yet, a plugin ecosystem that is currently mostly first-party, no published performance benchmarks, documentation gaps around circular plugin dependencies and multi-agent context sharing, and the sandbox limitation noted above.

The correct posture is a contained pilot, not a production control plane. Put it on internal tooling, run it against a repo you don't mind breaking, and keep it away from customer data and production credentials until the API stops moving.

The line worth keeping

The model is the soul. The harness is the body. For two years we argued about souls while quietly paying rent on bodies.

DeepSeek just made a body that runs any soul, gave it away under MIT, and raised the price of its own soul in the same breath. Whether or not dsh is the tool you end up using, the assumption it broke — that your agent runtime and your model provider must be the same company — is not going back in the box.


Sources and further reading: DeepSeek Harness official page · Architecture reference · The New Stack · VentureBeat · Cordis explained · Production-readiness review