DeepSeek Harness Explained: The Plugin Architecture Behind Super Agent
DeepSeek Harness treats every component as a swappable plugin, built on the Cordis composability framework. Here's how it actually works.
What is DeepSeek Harness (DSH)?
DeepSeek Harness, or DSH, is an open-source, MIT-licensed coding agent framework DeepSeek released on August 13th alongside DeepSeek V4 Pro. It is not tied to DeepSeek’s own models: it works with other model providers and OpenAI-compatible endpoints. The defining idea behind DSH is that every part of the system, including the agent loop itself, is a plugin. There is no fixed core that plugins attach to. The router, the tool registry, the session log, and the loop that actually drives the agent are all pluggable components, which makes the whole harness reconfigurable without forking anything.
TL;DR
- DSH makes the agent loop itself a plugin, not just the tools around it, so the core behavior of the agent can be swapped like any other component.
- The framework underneath DSH is called Cordis, built on a design the creators describe as a paradigm for spatio-temporal composability: components can be added or removed cleanly, with no leftover state.
- An independent benchmark, Frontier Harness Eval, ran the same model (Kimi K3) through nine harnesses and found DSH matched Claude Code’s pass rate at a fraction of the cost per successful task.
- DeepSeek’s Super Agent, a GitHub-and-chat-watching coding agent, is built entirely as a set of DSH plugins rather than a forked or separate codebase.
- Super Agent splits work between a lightweight router that handles orchestration and isolated worker agents that do the actual coding, and the router gets more efficient as load increases rather than less.
- DeepSeek’s own repo has stopped accepting outside pull requests to the core, pushing contributors toward building plugins instead, which is a direct consequence of the plugin-first design.
How does the Cordis plugin system actually work?
Cordis is the composability framework underneath DSH, developed with input from researchers at Beijing University and described by DeepSeek as a programming paradigm for “spatio-temporal composability.” That phrase covers two fairly simple ideas.
The first is temporal composability. When a plugin is removed, everything it did gets undone completely. If a plugin registered a tool, hooked into an event, or patched some behavior, unloading it reverses all of that automatically. Nothing lingers.
The second is spatial composability. Components declare what they depend on, and the runtime activates or deactivates them as those dependencies appear or disappear. This means plugins can be plugged in and unplugged safely, even while the system is running, without leaving orphaned state behind.
This matters because coding agent harnesses change constantly. Teams swap models, add and remove tools, and flip permissions on and off. Without a formal system for cleanly adding and removing components, that churn tends to leave debris in the codebase. The transcript notes this is a real pattern seen across the agent harness space, where fast iteration has historically meant leftover code and inconsistent state.
How is DSH actually structured and configured?
Running DSH boots a tree of plugins assembled from layered configuration. Bundles are packaged sets of plugins plus their configs. Profiles patch a YAML file called cordis.patch. There’s also a home-level patch layer, and finally anything passed on the command line. Each layer can target a specific plugin by ID and override its config or insert new plugins entirely. A dump config command prints the full tree the system is booting from, and every row in that tree can be overwritten.
The DSH UI ships with four modes: standard, PGC, minimal, and creator. Each mode is just a different bundle of plugins. Creator mode is the clearest expression of the plugin philosophy: you can describe a new plugin in chat, and the agent will write it, install it, and verify it’s live. That effectively brings continual, in-session extensibility to the harness itself, not just to the underlying model.
Why does the harness matter more than people assume?
A natural assumption is that the model does most of the work and the harness is just plumbing around it. The Frontier Harness Eval benchmark pushes back on that. The test took one model, Kimi K3, and ran it through nine different coding agent harnesses across twelve configurations, including Codex, Claude Code, Pi, Open Code, and DSH, all given the same 30 tasks and the same runtime.
Codex came out on top with a 66.7% pass rate. DSH’s “creator” configuration and Claude Code tied at 63.3%. But the cost per successful task was wildly different: DSH’s run cost about $3.28 per successful task, while Claude Code’s cost about $18.34, for the same pass rate using the same model. Across the full set of configurations, the gap between the cheapest and most expensive setups was roughly 17.5x.
That’s not a huge sample (30 tasks means each one is worth about 3.3 percentage points), so exact rankings should be read with some caution. But the broader point holds: the harness changes cost, caching behavior, speed, and success rate even when the model is held fixed. Judging a model’s quality from a single harness risks blaming the model for problems that actually belong to the orchestration layer around it.
What is Super Agent and how does it use DSH’s plugin design?
Super Agent is DeepSeek’s recently released system that sits on a GitHub repo (and on Feishu, ByteDance’s Slack-like chat app), watches issues and pull requests, and acts when someone asks it to do something. It spins up its own session, does the work, and comes back with a pull request. DeepSeek describes it explicitly as a research prototype grown out of their internal development work, not an official product, and says much of the implementation was written by coding agents themselves.
What makes Super Agent relevant to the harness story is that it isn’t a separate codebase. Opening the Super Agent repo, the first thing you find is a cordis.patch.yaml file that inserts a core Super Agent plugin, a GitHub watcher plugin, and a Feishu watcher plugin. Everything else comes from a separate worker preset: a stripped-down version of DSH’s standard configuration with no clarifying questions to the user, no plan mode, no web fetch, and no spinning off of sub-agents. Shell commands that run longer than five seconds get pushed to a background job automatically, so a long build doesn’t block the worker from noticing new instructions arriving mid-task.
How does the router and worker architecture work?
Super Agent runs two layers. On top sits a single long-running session called the router, which handles all communication with humans, keeps broad context, and distributes work. Underneath are isolated worker agents, each running its own session, each never talking to a person directly. Workers only report back through the router, except for one detail: once a worker owns a ticket, it subscribes directly to that conversation thread, so follow-up comments on its pull request go straight to the worker and skip the router. DeepSeek found that disabling this shortcut increased router decisions by roughly 30%, along with the associated token cost.
Every incoming trigger (a new issue, a review comment, a chat message) first passes through a gate that is plain code, not a model call. That gate checks deterministic things like whether the person is authorized and whether the agent was actually addressed. Only after passing the gate does a model evaluate whether it’s real work, turning it into a ticket with a “mandate” that records who asked, under what rules, and how far the work can go.
The router turns out to behave counterintuitively under load. Because it batches incoming triggers that pile up mid-inference, DeepSeek’s stress test found that pushing trigger volume from about one per minute to about 40 per minute increased average batch size from 1 to 2.8. Individual calls got slightly slower (2.5 seconds to 3.9 seconds), but time per decision actually dropped, from 6.4 seconds to 1.6 seconds, because batching made the router more efficient rather than less. DeepSeek also notes the router’s job is simple enough that a lighter, cheaper model handles it fine, reserving stronger models for the workers doing actual coding.
Is DSH worth building on?
For teams already comfortable forking or customizing coding agent harnesses, DSH’s plugin model is worth a serious look, mainly because its cost and performance profile on the Frontier Harness Eval benchmark was competitive with Claude Code at a much lower price, using an identical model. The tradeoff is that DeepSeek’s core repo isn’t accepting outside pull requests anymore, pushing the community toward discussions and standalone plugins instead of core patches. That’s a deliberate consequence of the architecture: if there’s no monolithic core to modify, plugins become the contribution path by default.
Frequently Asked Questions
What does “everything is a plugin” mean in DSH?
It means components typically treated as fixed infrastructure in other agent frameworks, such as the agent loop, the tool registry, the router, and the session log, are all implemented as swappable plugins in DSH, with no privileged core component.
What is Cordis?
Cordis is the underlying composability framework DSH is built on, developed with researchers at Beijing University. It handles cleanly adding and removing plugins (temporal composability) and managing dependencies between components as they’re activated or deactivated (spatial composability).
Is DeepSeek Harness only for DeepSeek models?
No. DSH works with other model providers and OpenAI-compatible endpoints, so it isn’t locked to DeepSeek’s own model lineup.
What’s the difference between Super Agent and DSH’s earlier “agent teams” feature?
Agent teams coordinate multiple agents within a single job. Super Agent is designed for handling many independent jobs arriving from outside sources (GitHub issues, chat messages) over time, which is a different coordination problem.
Why did the router get faster under heavier load in DeepSeek’s tests?
Because incoming triggers that arrive while the router is mid-inference get queued and processed together in the next call. Larger batches meant slightly longer individual calls but a lower average time per decision overall.
