📦 What DeepSeek shipped 0:00
Over a weekend, DeepSeek released something people are already calling the answer to Claude Code: an agent that sits on a GitHub repository, watches issues and pull requests, and when someone on the team asks it to do something, goes off into its own session, does the work, and comes back with a pull request.
Sam Witteveen's interest is elsewhere, and that is what makes the video useful: the agent is not the interesting part, how it was built is. The entire super agent is a set of plugins dropped into DeepSeek's existing agent harness. No fork, no patch to the core, no special build.
| Piece | What it is | Status |
|---|---|---|
| DeepSeek Harness (DSH) | MIT-licensed agent runtime, open-sourced 13 August 2026 alongside DeepSeek-V4-Pro; "everything is a plugin" | v0.1, developer preview, ~271k GitHub stars |
| dsh-superagent | Proactive coding agent for one repository, packaged as a DSH bundle; listens to GitHub and optionally Feishu | MIT, research prototype, ~16.5k stars |
| "Exploring Super-agent Design" | Design essay published with the code (originally Chinese); architecture, two experiments, open problems | Ideas, not a feature list — some designs are future work |
The repo's own framing is the most important sentence in the whole release: a proactive coding agent for one repository, packaged as a bundle for DeepSeek Harness. Everything else follows from "packaged as a bundle".
🧪 A prototype, written partly by agents 1:16
DeepSeek is unusually direct about what this is. The README says, in bold: "Research prototype for reference only, not an official DeepSeek product." It grew out of the team's own day-to-day development, and much of the engineering was done by coding agents. The published code is not identical to their internal version.
They also report that they have been running an internal version continuously — reproducing and fixing bugs, responding to code review comments, and even improving the DeepSeek Harness itself. That claim is the interesting one, and it is a company statement rather than a measured result: the agent maintaining the harness it runs on.
🔁 How one request becomes a pull request 1:48
The mechanism inverts the usual interaction. Instead of you opening a session and talking to an agent, the agent listens where your team already works — in this release, GitHub, plus optionally Feishu, ByteDance's Slack-equivalent collaboration app (sold internationally as Lark).
| Step | What happens |
|---|---|
| 1 | Someone who is allowed to ask requests work in a conversation |
| 2 | The agent opens a work item and spins up its own session in its own directory |
| 3 | It does the work, and replies in the original conversation — usually with a pull request |
| 4 | A web panel shows what needs a person |
Witteveen places this in the software-factory lineage of the last few months, and the framing is right: what makes it a factory rather than a chatbot is that the trigger comes from outside the session, and the output lands where the team already reviews work.
⚖️ Model or harness — which matters now? 2:49
Before the how, the why. On the VentureBeat podcast he co-hosts, Witteveen put the same question to the CTOs of Instacart and Box: what is more important now, the model or the harness? Both said the harness.
That is an anecdote, not evidence — and he does not pretend otherwise. But it matches what the benchmark in the next section shows, and it changes how you should read every "model X is better" claim you will see this month.
📊 Same model, nine harnesses, 17× the cost 3:53
The evidence is FrontierHarness Eval: one model — Kimi K3 — run through nine coding-agent harnesses in twelve configurations, on the same 30 software-engineering tasks (21 Terminal-Bench, 9 DeepSWE), 360 evaluations in total, with deterministic verifier-based scoring and first-turn cache reads repriced consistently so the cost comparison is fair.
| Harness | Pass rate | Median cost per pass | Cache hit | Median time |
|---|---|---|---|---|
| Codex | 66.7% | $3.47 | 88.0% | 6m 43s |
| DSH Creator | 63.3% | $3.28 | 84.3% | 6m 44s |
| Claude Code | 63.3% | $18.34 | 67.8% | 9m 38s |
| Pi | 60.0% | $2.43 | 79.4% | 7m 33s |
| DSH PTC | 60.0% | $4.58 | 87.2% | 7m 44s |
| DSH Standard | 60.0% | $3.46 | 86.5% | 6m 17s |
| Oh My Pi | 56.7% | $4.75 | 82.2% | 6m 46s |
| Kimi Code | 56.7% | $3.65 | 88.0% | 7m 56s |
The headline pairing: DeepSeek Harness in its creator configuration and Claude Code land on the same 63.3% pass rate — but at $3.28 versus $18.34 per successful task. Across the whole table the spread between cheapest and most expensive configuration is about 17.5×.
🧩 DSH: everything is a plugin 5:52
DeepSeek Harness shipped on 13 August 2026 with DeepSeek-V4-Pro (1.6T total parameters, 49B active, one-million-token context). It is MIT licensed, starts with a single npx command, has a web UI and a desktop app, and — importantly — is not locked to DeepSeek models: it works with other providers and any OpenAI-compatible endpoint.
Its tagline is meant literally. In most agent frameworks there is a core — the agent loop, model calls, tool handling — and plugins hang off the side. In DSH:
| Thing you would expect to be core | In DSH |
|---|---|
| The router | A plugin |
| The tool registry | A plugin |
| The session log | A plugin |
| The agent loop itself | A plugin |
Underneath sits a meta-framework called Cordis, which handles only plugin mounting, unloading and dependency resolution. That is why the super agent could be built as a bundle: there is no privileged core to modify, only a composition to extend.
🧠 Cordis and the two kinds of composability 6:49
Cordis comes with a paper — A Programming Paradigm for Spatiotemporal Composability (arXiv 2608.25512, three authors) — and its two ideas are simpler than the title.
| Dimension | Definition (from the paper) | Plain English |
|---|---|---|
| Temporal composability | The ability to completely revert a component's side effects when it is removed | Unplug something and everything it did is undone — registered tools, event hooks, all of it |
| Spatial composability | The ability to declare and reactively manage inter-component dependencies | Components declare what they need; the runtime activates or deactivates them as those dependencies appear and vanish |
Why does an agent harness need this? Because harnesses change constantly — you swap models, add tools, toggle permissions — and if every change leaves residue behind, the system rots. Witteveen notes the same thing happened when people reverse-engineered how Claude Code worked: new harnesses are shipping so fast that code gets left behind.
🗂 Four layers of configuration, four modes 8:10
Running DSH produces a tree of plugins composed at boot from layers, and each layer can target any plugin by ID to replace its configuration or insert new ones:
- Bundles — package sets of plugins plus their configs
- Your profile patch — a YAML file,
cordis.patch - A home-level patch
- Command-line arguments
A dump config command prints the whole tree the machine is booting from, and every row in it can be overridden. In the UI the same idea appears as four modes — standard, PTC, minimal, creator — which are themselves just different sets of plugins.
That is a genuinely new capability shape: while the industry has focused on continual learning for models, this is continual learning for the harness — the agent extending the runtime it runs inside, with the installation and verification in the loop.
One consequence of the design is worth noting: the core repository is not accepting outside pull requests, pointing contributors to discussions and plugins instead. If there is no core to patch, plugins are the contribution mechanism.
📄 The integration is one patch file 9:40
Open the super agent repository and one of the first files you see is cordis.patch — and that file is essentially the whole integration. It inserts a core super-agent plugin, a GitHub watcher plugin, and a Feishu watcher plugin. Turn off the ones you do not use.
The workers get their own preset, and the definition is subtractive: it is DSH's standard preset with things removed.
| Removed from the worker preset | Why |
|---|---|
| Asking a person questions | Workers never talk to people; the router does |
| Plan mode | The ticket and its mandate already define the work |
| Web fetch | Reduce the ways a worker can wander |
| Spawning sub-agents | Keeps one ticket to one accountable session |
There is one small, very practical detail: the shell is configured so any command running longer than 5 seconds is pushed to a background job. A long build therefore does not stop the worker from noticing that someone left a new comment — which addresses a real frustration with other agents, where once a long command starts you sit waiting, unable to inject a correction as you watch it go the wrong way.
👥 Agent teams versus a super agent 10:53
DSH already had an experimental agent teams feature with a roster, a taskboard and a mailbox. So why build this?
| Agent teams | Super agent | |
|---|---|---|
| Unit | Coordinating agents inside one job | Handling many independent jobs arriving from outside |
| Time horizon | One task, start to finish | Days or weeks, continuously |
| Source of work | The operator inside the session | Many people posting in GitHub or chat |
| Model assignment | Same session family | Router and workers can each use a different model |
They address different problems, and the distinction is worth internalising before you build either: parallelism inside a task is a throughput question, while many independent requests is an operations question. The second needs authorization, tracking and a way for a busy human to see what needs them.
🚦 The gate, the mandate, and the shortcut 11:32
The architecture has two layers. On top, one long-running session called the router: it handles all human interaction, keeps the big-picture context, and hands work out. Below, worker agents, each in an isolated session, none of which ever talks to a person — they report to the router, and the router does the communicating.
Everything arriving from outside is a trigger — a new issue, a review comment, a chat message — and each trigger passes through a gate before a model sees it.
| Stage | What decides | Deterministic? |
|---|---|---|
| Gate | Is this person allowed to ask? Did they actually address the agent? | Yes — plain code, not a model |
| Triage | Is this real work? | Model, and only after the gate passes |
| Ticket + mandate | Who asked, under which rules, how far the work may go | Recorded, so it can be revalidated later |
| Worker | Does the work in its own session and directory | Bounded by the mandate |
That separation is the best security idea in the release: authorization is code, not inference. A prompt injection cannot talk its way past a list of allowed senders, because no model is asked whether the sender is allowed.
Then the detail that saves the most tokens. Once a worker owns a ticket, it subscribes to that conversation, so a comment on the pull request it opened goes straight to the worker and skips the router entirely.
By the numbers in the design essay: router decisions rose about 30%, and cached tokens read rose from 23.23 million to 31.77 million — roughly 37% more, or a 27% saving with pass-through enabled.
📈 Why the router gets more efficient under load 13:16
Here is the counter-intuitive finding. You would assume a single central session doing all the orchestration becomes the bottleneck as things get busy. It does the opposite: triggers that arrive while the router is mid-inference pile up and get handled together in the next call, and because the router's job is structured as long input and short output, that batching is cheap.
| Measure | Low load | High load | Direction |
|---|---|---|---|
| Trigger rate | ~1 per minute | ~40 per minute | 40× |
| Average batch size | 1.0 | 2.8 | Absorbs the burst |
| Latency per call | 2.5 s | 3.9 s | Slower per call |
| Time per decision | 6.4 s | 1.6 s | 4× better, amortised |
Two consequences follow, and both cut against received wisdom. First, a single router can plausibly serve a team-sized workload. Second, the router's job is simpler than you would expect — often handled fine by a lighter, cheaper model. It does not even need a bash tool.
🎯 Attention as the scarce resource 15:01
The design principle, stated in the README and repeated in the video: take as little human attention as possible and give as much value as possible. An agent that can act for a whole team can also waste a whole team's attention, so it acts only when asked, or when a rule the team wrote allows it — and speaks only when someone must act or can use a result.
The most interesting implementation detail: when work nobody asked for starts, it first runs in a mode where it only records what it would have done, then checks whether that would have worked, and only speaks up when there is a result or a decision someone needs to make.
⚠️ Four caveats worth taking seriously 15:32
| Caveat | Details | How much it should worry you |
|---|---|---|
| It is a prototype | Published code is not identical to the internal version; some designs in the essay are future work — e.g. the watchdog session is not fully there | Read it as reference, not deployment |
| It is narrow | One GitHub repo; no Slack or email out of the box | Low — everything is a plugin, and there is a cookbook for adding a new source |
| Synthetic benchmarks | The reported experiments ran on simulated workloads in a simplified environment; the team calls the results a preliminary reference | Medium — treat the numbers as direction, not performance claims |
| Security is unsolved | The team lists prompt injection, credential leakage and cross-device permissions as unsolved | High in shared environments; low if you run local models in a locked-down setup |
The synthetic-workload caveat deserves emphasis because it is easy to misread the results. In the scheduling experiment they ran roughly 300 simulated chat and CI messages per run, including about 20 real work requests, five runs per setup — with coding replaced by a deliberately time-consuming tool. That measures scheduling and attention, not code quality. Which is exactly the right thing to measure for this design, as long as you do not quote it as a coding benchmark.
✅ Claims checked
| Claim | Verdict | Evidence |
|---|---|---|
| DeepSeek released a super agent over the weekend as a GitHub repo + design essay | Correct | Repo deepseek-ai/dsh-superagent-prototype, MIT, created 31 Oct 2026; essay "Exploring Super-agent Design" published with it (originally Chinese) |
| It is a research prototype, not an official product | Correct — stated by DeepSeek | README: "Research prototype for reference only, not an official DeepSeek product" |
| Watches GitHub, and optionally Feishu | Correct | README: "It listens to GitHub and, optionally, Feishu"; the transcript's "FYU / Bance" is Feishu (ByteDance) |
| Most of the engineering was done by coding agents | Company statement | README says much of the engineering was done by coding agents; unverifiable externally |
DSH released 13 August 2026 with DeepSeek-V4-Pro, MIT, npx, web UI + desktop app | Correct | Repo deepseek-ai/deepseek-harness created 2026-08-13, MIT; V4-Pro-0813 shipped the same day (1.6T total / 49B active, 1M context) |
| DSH is not locked to DeepSeek models; works with OpenAI-compatible endpoints | Correct | Independent harness comparisons list "any OpenAI-compatible endpoint" as a defining property |
| "Everything is a plugin": router, tool registry, session log, agent loop | Correct | Repo description and Cordis docs: kernel handles mounting/unmounting and dependency resolution only |
| Cordis comes from a paper by three authors on spatiotemporal composability | Correct | arXiv 2608.25512, "A Programming Paradigm for Spatiotemporal Composability", Yifan Shi, Wei Zhang, Tianyi Cui (Aug 2026). The video's "Beijing University" affiliation was not verified here |
| Temporal composability = full reversion of side effects; spatial = declared dependencies | Correct | Definitions match the paper's abstract and the video's explanation |
| Config layers: bundles → profile patch → home patch → CLI; four UI modes | Correct | cordis.patch at profile level per the README; DSH modes standard / PTC / minimal / creator appear in the benchmark table |
| The core repo is not accepting outside PRs | Reported | Consistent with the plugin-first design; not re-checked against the repo's contributing policy for this article |
| FrontierHarness Eval: 9 harnesses, 12 configs, 30 tasks, one model | Correct | frontier-harness-eval/eval: same Kimi K3 model, 21 Terminal-Bench + 9 DeepSWE tasks, 360 evaluations. The transcript's "Kimmy Kade 3" is Kimi K3 |
| Codex 66.7%; DSH Creator and Claude Code 63.3%; $3.28 vs $18.34 per pass | Correct | Published result table: Codex 66.7% / $3.47; DSH Creator 63.3% / $3.28; Claude Code 63.3% / $18.34 |
| Cheapest to most expensive configuration differs ~17.5× | Consistent | Independent coverage headlines the same ~17× spread across configurations |
| Worker preset removes asking questions, plan mode, web fetch, sub-agents; 5-second shell cutoff | Correct | Super-agent architecture doc: worker shell commands and job waits return after 5 seconds; router/worker presets are separate |
| Workers subscribe to their conversations; comments skip the router | Correct | Architecture doc: a Trigger fans out to subscribed Tickets, so a person's message reaches the owning Ticket directly |
| Without pass-through: ~30% more router decisions, cache reads 23.23M → 31.77M | Correct | Ablation in the design essay, as reported in multiple independent summaries |
| Stress test: 1→40 triggers/min, batch 1.0→2.8, 2.5→3.9 s per call, 6.4→1.6 s per decision | Correct | Design essay, Table 2 (real router model, mock workers), reported consistently |
| Scheduling experiment: p50 12.4 min, p95 15.7 min vs 29.5 min p95 for a single session | Correct — and it measures scheduling, not coding | ~300 simulated messages per run, ~20 real requests, 5 runs, coding replaced by a slow tool |
| The router is often fine on a lighter model and needs no bash tool | DeepSeek's finding | Stated in the essay and repeated in the video; not independently measured |
| Security issues (prompt injection, credentials, cross-device permissions) unsolved | Correct — stated by DeepSeek | Listed as open problems in the essay; README warns it is not production-ready |
Transcript notes. Auto-captions garbled several names: "Deep Sea Caress / Deep Secret / DeepSync" → DeepSeek Harness / DeepSeek, "clawed code" → Claude Code, "Kimmy Kade 3" → Kimi K3, "FYU / Bance" → Feishu / ByteDance, "quarter.patch / cortis.patch" → cordis.patch, "facial watcher" → Feishu watcher. Star counts (DSH ~271k, super agent ~16.5k) were read from the GitHub API on 3 November 2026 and move fast.
🔑 Key takeaways
- The harness is now the variable. Same model, nine harnesses: pass rate, cost, cache behaviour and speed all move. Benchmark a model in at least two harnesses before forming an opinion about the model.
- Cost per successful task is the number that matters. 63.3% pass rate at $3.28 versus $18.34 is the same capability at a fifth of the price — the ranking is noise, the spread is not.
- "Everything is a plugin" is an architectural commitment, not a slogan. When the agent loop itself is a plugin, new agent topologies become compositions instead of forks.
- Composability needs both dimensions. Loading must be reversible (temporal) and dependencies must be declared (spatial), or every experiment leaves residue in the runtime.
- Authorization belongs in code, not in a prompt. A deterministic gate — are you allowed to ask, did you address the agent — is the one part of the pipeline no injection can argue with.
- Triage first, model second. Cheap rules screen every trigger; only surviving requests reach a model, and only accepted ones become tickets with a recorded mandate.
- Bypass the orchestrator where you can. Letting the owning worker receive follow-ups directly cut router decisions ~30% and cached tokens ~27%.
- A router under load batches rather than queues. 1→40 triggers per minute took time per decision from 6.4 s down to 1.6 s — the central session got more efficient as it got busier.
- Invert the model-tiering advice: the router can be cheap and tool-less; the workers that touch code are where a stronger model earns its cost.
- Run proactivity in shadow mode first. Record what the agent would have done, verify it would have worked, and only then grant it the authority to act.
- Subtract to specialise. The worker preset is the standard preset minus questions, plan mode, web fetch and sub-agents — capability removed on purpose to keep one ticket to one accountable session.
- Long commands must not block awareness. Pushing anything over five seconds into a background job is what lets a worker still notice a new comment mid-build.
- Read the caveats as the roadmap: prototype code, one repo, synthetic benchmarks, and security problems the authors themselves list as unsolved.
🔗 Resources
- The source video — Sam Witteveen, "NEW DeepSeek Harness - Super Agent!", 17:52, 3 November 2026
- deepseek-ai/dsh-superagent-prototype — the MIT-licensed super agent bundle, with numbered docs (philosophy, domain model, authorization, execution, prompts, deployment, architecture, cookbook)
- deepseek-ai/deepseek-harness — the harness itself: "Everything is a Plugin"
- DeepSeek Harness site — download, web UI and docs
- A Programming Paradigm for Spatiotemporal Composability — the Cordis paper (arXiv 2608.25512)
- cordiverse/cordis — the meta-framework DSH is built on
- frontier-harness-eval/eval — public results and task definitions for FrontierHarness Eval
- DeepSeek Harness on X — the announcement and the "Exploring Super-agent Design" essay (originally Chinese, machine-translated)