News · Agents and coding · News
DeepSeek Open-Sources dsh-superagent, a Router-Worker Coding Agent
DeepSeek has released dsh-superagent as open source. MarkTechPost reports that it is a router-worker coding agent. It takes incoming requests from GitHub and Feishu and breaks them into worker sessions that run in parallel. For a team that already tracks work across GitHub issues and Feishu messages, this is a direct fit. The source does not yet specify the license or the full runtime details.
DeepSeek says the p95 task completion time dropped from 29.5 minutes to 15.7 minutes after the switch to the router-worker pattern. The p95 number matters more than average time because it describes the slow edge that users actually wait on. A cut from 29.5 to 15.7 minutes is a substantial improvement in that tail. It means the worst common case nearly halved.
In one line: DeepSeek has open-sourced dsh-superagent, a router-worker coding agent that parallelises GitHub and Feishu requests and reports a p95 task completion time drop from 29.5 to 15.7 minutes.
What the release includes
The release is open source, but the MarkTechPost piece does not specify the license. dsh-superagent is not a single model. It is a router-worker agent. The router receives requests from GitHub and Feishu, then spawns worker sessions that handle tasks in parallel. The source material does not detail how workers are isolated, what models they run, or how results merge back.
The main number to note is p95. DeepSeek reports a p95 task completion time of 15.7 minutes, down from 29.5 minutes before. This is a self-reported figure. I have not seen an independent benchmark yet.
How the router-worker pattern helps
In a single-agent setup, one long task can block the queue. A router-worker design changes that. The router is the single entry point. It decides which worker should handle each request. Workers can then run independent sessions in parallel. This suits queues where many small tasks arrive at once, like GitHub issue triage or Feishu support requests.
The gain shows up in the tail. If one task takes 25 minutes, a single agent keeps others waiting. With parallel workers, other tasks can finish while that slow one runs. That is the practical meaning of the p95 drop. The slow common case no longer sets the pace for everything else.
Why GitHub and Feishu matter
GitHub is already the default intake for coding work in many teams. Issues and pull request comments are natural task queues. Feishu, also known as Lark, is used by a smaller but real set of teams in India, especially where cross-border collaboration happens. If dsh-superagent can treat both as first-class input channels, it shortens the distance between a request and an active worker.
From a delivery angle, the interesting part is not that the agent can code. It is that the router can fan out work. A long running task no longer blocks the whole queue. For client projects where one repo can have multiple open issues at once, parallel worker sessions can reduce the waiting time my team reports to clients. But only if the work is actually independent. When two issues touch the same file, parallel sessions can create merge conflicts that are worse than waiting.
What I would check before using it
The source material leaves several questions open.
- Worker isolation. If parallel workers touch the same repository, merge conflicts can eat the time saved. I would want to see how dsh-superagent serialises writes or handles conflicts.
- Feishu permissions. A bot that can act on Feishu messages needs a clear permission boundary.
- Cost. Parallel workers may use more tokens and compute per minute, even if the p95 time falls.
- Model support. The source does not say whether it is tied to DeepSeek models or can run with other providers.
For client work, I would not point this at a production repository on day one. I would first run it on an internal project or a low-risk repo and measure our own p95 before and after. The reported 29.5 to 15.7 minutes is a vendor number. It needs to hold on our tasks, our models, and our host environment.
Where I would try it first
I would watch the repository and read the setup notes when they appear. A small test would be to take five GitHub issues from an internal maintenance repo, let dsh-superagent route them in parallel, and compare completion times with our current agent loop. I would also check whether it can run against a local model, because some client environments have data residency constraints.
If the conflict handling and permissions look clean, this could fit internal tooling before it touches client delivery. For now, the release is worth a watch, not an immediate change to production.