DeepSeek Super-agent: Open-Source Coding Agent Handles Many Requests at Once
The DeepSeek Super-agent is open source: an MIT-licensed prototype that handles many GitHub requests at once. See how it works, what DeepSeek measured and where the limits are.
TL;DR
• DeepSeek’s Harness team released dsh-superagent, an MIT-licensed research prototype for one GitHub repository. It is not an official DeepSeek product.
• A long-running Router sends events to separate Worker sessions, one for each work item.
• Work the agent infers on its own is only recorded by default (observe mode), not acted on.
• In DeepSeek’s own tests on simulated tasks, the 95th-percentile time was 15.7 minutes. A single session that never used a subagent took 29.5 minutes.
• Both setups run with full access as the operator’s OS user. DeepSeek advises using a dedicated account.
DeepSeek Super-agent: Open-Source Coding Agent Prototype
The DeepSeek Super-agent is now open source. DeepSeek’s Harness team has released dsh-superagent, an MIT-licensed prototype of a coding agent for one GitHub repository, along with a design essay from the team. The README calls it a research prototype for reference only, not an official DeepSeek product.
What the DeepSeek Super-agent does
According to the README, the agent listens to GitHub and, optionally, the Feishu chat app. When an allowed person asks for work, it opens a work item, handles it in its own agent session and folder, and replies in the original conversation, for example with a pull request. A web panel shows what needs a person.
The README states the aim as taking as little human attention as possible while giving as much value as possible. The code is packaged for DeepSeek Harness, the company’s agent tool. One report says it uses whichever model the Harness profile is set to.
How the router-worker design works
DeepSeek’s design essay says most agents treat one session as the basic unit of work. In the team’s experience, one person can usually keep track of only three to five active sessions.
Its answer has two layers. A long-running Router handles interaction and dispatch. Isolated Worker sessions do the actual work.
The domain documentation names the steps:
• Source: where events come from, such as GitHub.
• Trigger: an event from a source.
• Ticket: a unit of authorised work, created if the evaluation step accepts a batch of triggers.
• Mandate: what that approval allows, including the policy version, scope, strength, matched rules, the sender’s identity and how the trigger arrived.
Subscriptions let later discussion reach the Worker without anyone mentioning the agent again.
Observe mode is the default
Explicit requests from allowed people work in every mode. Work the agent infers on its own is controlled by an accept mode with three settings: off, observe and auto.
In the default observe mode, the agent assesses inferred candidates and records a positive result as an ignore marked “would accept”. Nothing is accepted. The authorisation document says to start in observe and switch to auto after reviewing the recorded decisions.
Some reports describe the agent as watching developer group chats and suggesting fixes without waiting for instructions. In the default setup documented in the repository, inferred work is only recorded.
What DeepSeek’s tests measured
The essay reports early experiments. Each run had about 300 messages, about 20 of them real work requests, with the coding replaced by a simulated task. Each approach ran five times.
• Super-agent finished tasks in a median of 12.4 minutes. Its 95th-percentile (p95) time was 15.7 minutes, meaning 95% of tasks finished within that time.
• The baseline was a single session with a subagent tool. With a neutral prompt, the model never used a subagent in any of the five runs, and p95 reached 29.5 minutes.
• With a prompt telling it to delegate first, the model delegated in four of five runs and did better, but stayed slower than Super-agent.
• Super-agent used more cache-read tokens, trading extra token use for shorter, steadier times.
All of these figures come from DeepSeek’s own team. The essay says the experiments used synthetic workloads and simplified environments, so they are early reference points. They measure scheduling under load, not the quality of the code the agent writes.
Access and limits
The deployment documentation says both agent presets run with danger-full-access as the operator’s OS user. It advises a dedicated OS account holding only the agent’s credentials. The execution document adds that its wrappers and directories set defaults, not a security boundary.
The README also says the code is not identical to DeepSeek’s internal version or to the implementation in the essay. Some designs in the essay are directions for future work.
What the DeepSeek Super-agent means for developers
• A design to study, not a finished tool. The release is a published design and reference implementation for agents that handle many requests at once.
• The Claude Code comparison goes further than the project does. Some reports call it a challenger to Anthropic’s Claude Code. The README makes no such comparison, and DeepSeek’s own benchmark compares Super-agent only with single-session setups.
The upside:
• The code is open under the MIT licence, so anyone can inspect and adapt it.
• Observe mode is a cautious default for unprompted work.
• In DeepSeek’s tests, completion times were shorter and steadier than the single-session baseline.
The concerns:
• Both presets run with full access as the operator’s OS user.
• The tests used simulated tasks and do not measure code quality.
• It is a research prototype, and the code differs from DeepSeek’s internal version.
The bottom line
DeepSeek has open-sourced an idea more than a product: a Router that sends each request to its own Worker. Its early numbers look promising, but they come from simulated tasks run by DeepSeek itself. Until others test it on real repositories, the main value is the design, which anyone can study and adapt under the MIT licence.
