DeepSeek Open-Sources Super-agent Prototype: p95 Task Time Drops from 29.5 to 15.7 Minutes

DeepSeek has released a prototype of Super-agent, a multi-agent system that splits talking to people and doing the work into separate sessions. A single router session accepts requests and distributes tasks, while isolated workers execute them in parallel, launching on GitHub events. In DeepSeek's own test, p95 task completion time fell from 29.5 to 15.7 minutes compared with a single session. The release was flagged by AI news analyst @kimmonismus, whose post on X drew about 91.6 thousand views.

Router on one side, workers on the other

The design will look familiar to anyone who has built coding agents. In a typical single-session setup, one agent both talks to the user and carries out the long-running work: it reads the repository, edits code, and runs checks. While it is busy, new requests either wait or get squeezed into its context and derail the current task.

Super-agent separates these roles. The router remains the system's "face": it talks to people, works out what they want, and passes the work on. The work itself goes to workers. Each one is isolated, meaning it lives in its own environment with its own context and does not affect its neighbors. GitHub events act as the trigger: a new issue, a comment, a pull request, and similar signals. The agent does not wait for a command in a chat. It reacts to what happens in the repository.

This approach has two obvious advantages. Parallel tasks do not sit in a single queue, and an error or hang in one worker neither corrupts the other workers' context nor blocks the conversation with the human.

What DeepSeek's measurement shows

The only public figure in the announcement is p95 completion time. This is the time within which 95% of tasks finish, a "long tail" metric that captures the slowest cases. It matters for team workflows: average speed says little if every twentieth task hangs for half an hour. For the single session, p95 was 29.5 minutes; for the system with a router and workers, it was 15.7 minutes. That cuts the latency tail by almost half, roughly 47%.

The plausible explanation is parallelism. When tasks arrive in a batch, a single session processes them one after another, and the last ones wait the longest. Workers take them at the same time, so the queue does not grow. This explanation is inferred from the description of the architecture, not from published test data.

What the announcement leaves out

The numbers deserve a cautious read. First, DeepSeek ran the test itself, and there are no independent reproductions yet. Second, the post does not reveal the composition of the workload: how many tasks there were, how complex they were, and how often they arrived at the same time. With low concurrency, the gain could be noticeably more modest. Third, the link to the baseline in the post is cut off, so it is unclear which single-session configuration the comparison used.

Speed is also only one axis. The announcement says nothing about the quality of the output: the share of accepted pull requests, the number of errors, or token consumption. Several workers almost certainly use more compute than a single session, which means the speedup will have to be paid for in money.

What developers should do

The release is worth opening for anyone building agents around GitHub and running into queues. The prototype lets you see how DeepSeek organizes the router, worker isolation, and event-based launches, and compare that with your own design. The word "prototype" speaks for itself: it is too early to treat this as a production-ready product.

You can test the claimed gain on your own workload. Take a repository with a stream of typical tasks, run them through a single agent and through the "router plus workers" setup, and compare p95, along with cost and the share of accepted changes. If the latency tail shrinks by a comparable amount, the architecture will pay off. If not, DeepSeek's numbers will remain a good result on its own task set.