DeepSeek open-sources Super-agent prototype: p95 task completion time of 15.7 minutes vs. 29.5

On October 31, the DeepSeek Harness team published an architecture paper and the code for its Super-agent prototype (repository dsh-superagent-prototype). In the experiment, p95 task completion time was 15.7 minutes versus 29.5 for a single-session setup, roughly 47% faster. The methodology and task set are not disclosed in the summary we have, so the figure should be checked against the primary source. • p95 is the time within which 95% of runs finish • The code is in the public repository dsh-superagent-prototype • The post names only one component of the architecture, the Router; the rest is not disclosed

AI-processed from X: @JamesX_ai; edited by Hamidun News
DeepSeek open-sources Super-agent prototype: p95 task completion time of 15.7 minutes vs. 29.5
Source: X: @JamesX_ai. Collage: Hamidun News.
Listen to article
Article Fact Sheet & Key Figures
ParameterDetails
Primary sourceX: @JamesX_ai ↗
Editor-in-Chief
Key metric #1p95 is the time within which 95% of runs finish
Key metric #2The code is in the public repository dsh-superagent-prototype
Key metric #3The post names only one component of the architecture, the Router; the rest is not disclosed

The DeepSeek Harness team has published an architecture paper on its Super-agent prototype and released the code in the public repository dsh-superagent-prototype. According to a summary on X, the multi-component setup had a p95 task completion time of 15.7 minutes in the experiment, versus 29.5 minutes for the single-session solution. The difference is about 47%: the longest runs finish almost twice as fast. The paper itself is not quoted in the text available to us, so we have to rely on the post author's brief summary.

What the post tells us

The source is a short post on X by @JamesX_ai with very little reach, around 22 views. The author writes that seven AI bloggers from his feed are discussing the news, and dates the paper's publication to October 31. Of the architecture, he managed to name only one element: the Router, a component that, judging by its name, distributes incoming work. The description cuts off after that, so the remaining components, the number of subagents, and the way context is passed between them are unknown.

Very little can be stated with confidence. The prototype has been published openly. The team compared it with a variant in which the entire process runs in a single session. The comparison used p95 completion time. Everything else is speculation, and presenting it as fact would be wrong.

Why p95 matters here

The p95 metric shows the time within which 95% of runs finish. It captures the "long tail": rare but painful cases where an agent goes in circles, rereads a bloated context, or waits on a heavy step. For agent-based products, this figure often matters more than the average, because users remember not the typical run but the longest one.

A single-threaded session typically suffers in exactly this tail. Context grows, each next step gets more expensive, and independent subtasks run strictly one after another. If the Router in the prototype splits the work and runs parts in parallel, a gain in p95 looks plausible. But that is a hypothesis: the summary contains no data on how the speedup actually works.

What the report leaves out

Evaluating the result requires information the post does not provide:

  • which tasks were used and how many there were;
  • which model ran in both configurations, and whether the token budgets were identical;
  • how many runs went into the p95: on a small sample, a tail metric is very noisy;
  • whether result quality was compared, not just speed;
  • what the speedup cost: parallel subagents usually consume more tokens.

The last point is critical. A nearly twofold reduction in time can easily be bought with a larger inference bill or lower accuracy on hard tasks. Until the source provides data on the share of tasks solved successfully and on token consumption, 15.7 versus 29.5 minutes speaks only to speed.

What practitioners should do

The repository is open, so the claim can be checked independently. Developers building agent systems should look at how the code implements the Router and state passing, and run the prototype on their own typical tasks. The comparison should cover three axes at once: p95 time, success rate, and token cost.

Until the full paper and independent measurements appear, the news should be treated as a claim about an interesting architecture, not a proven result. The fact that DeepSeek released open code matters in itself: it lets the community quickly confirm or refute these numbers.

Story

Key Questions Answered

What the post tells us?

The source is a short post on X by @JamesX_ai with very little reach, around 22 views. The author writes that seven AI bloggers from his feed are discussing the news, and dates the paper's publication to October 31. Of the architecture, he managed to name only one element: the Router, a component that, judging by its name, distributes incoming work. The description cuts off after that, so the remaining components, the number of subagents, and the way context is passed between them are unknown. Very little can be stated with confidence. The prototype has been published openl

Why p95 matters here?

The p95 metric shows the time within which 95% of runs finish. It captures the "long tail": rare but painful cases where an agent goes in circles, rereads a bloated context, or waits on a heavy step. For agent-based products, this figure often matters more than the average, because users remember not the typical run but the longest one. A single-threaded session typically suffers in exactly this tail. Context grows, each next step gets more expensive, and independent subtasks run strictly one after another. If the Router in the prototype splits the work and runs parts in pa

What the report leaves out?

Evaluating the result requires information the post does not provide: which tasks were used and how many there were; which model ran in both configurations, and whether the token budgets were identical; how many runs went into the p95: on a small sample, a tail metric is very noisy; whether result quality was compared, not just speed; what the speedup cost: parallel subagents usually consume more tokens. The last point is critical. A nearly twofold reduction in time can easily be bought with a larger inference bill or lower accuracy on hard tasks. Until the source provides

ZK
Zhemal Khamidun — CPO at Alpina Digital, product manager of AlpinaGPT. Building AI products since 2019. Hamidun News is a pet project that grew into a production aggregator with 6,000+ readers.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
What do you think?
Loading comments…