DeepSeek Super-Agent: What a Proactive Coding Agent Costs

Updated November 2, 2026 · first published November 2, 2026

DeepSeek's Super-Agent (dsh-superagent) is an MIT-licensed research prototype of a proactive coding agent. It watches one GitHub repository and, optionally, Feishu chat, turns requests from allowed people into work items, and replies in the original thread, often with a pull request. DeepSeek publishes no cost or token figures for it, so you must measure your own.

Facts below come from the project README and Help Net Security's 2 November 2026 report, read on 2 November 2026. Bloomberg also reported the release as a challenge to Anthropic's Claude Code. DeepSeek has published no benchmark against Claude Code, so treat that framing as press positioning, not a measured result.

What is confirmed?

• Scope: a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness.
• Flow: when an allowed person asks for work, it opens a work item, works on it in its own agent session and directory, and replies in the original conversation. A web panel lists items that need a person.
• License and status: MIT. The README calls it a “research prototype for reference only, not an official DeepSeek product,” says to treat it as research code and not production-ready software, and says some designs in DeepSeek's accompanying article are future directions not implemented in the prototype.
• Setup: the README says setup has many steps and points to SETUP.md and a deployment document. It does not state which models, API keys or spend limits to configure.

What is not published?

The README and Help Net Security report no token usage, per-task cost, budget setting, concurrency limit or benchmark. Some third-party write-ups quote latency numbers from a DeepSeek test; we could not find them in the README or the Help Net Security report, so we do not repeat them. Anything about cost per pull request has to come from your own runs.

Why does a proactive agent change the cost model?

A normal coding assistant spends when one person types a prompt. A team agent spends when a message arrives. That moves three things:

1. Who triggers spend. Any allowed person in a covered chat or GitHub scope can start a work item by mentioning the agent, so the budget owner is a team, not a seat. Help Net Security says a team can open a chat or GitHub scope and anyone in it can request work.
2. How much runs at once. Each work item gets its own agent session and directory. Several requests in the same hour mean several sessions in parallel, which is the same fan-out risk covered in subagent fan-out and concurrency limits. The sources describe no cap, so set one in your own infrastructure.
3. What counts as a request. This is where the design is useful for cost control. By default, implicit requests (unaddressed messages, bot messages, follow-ups from people not on the allow list) are logged as ones the agent would have accepted, but none are accepted. Explicit requests from allowed users work in every mode, and the report advises reviewing those logs before switching to auto mode. That log is a free preview of how much extra spend auto mode would create.

The same report says a message, comment or quoted document cannot expand what the agent is allowed to do, because the host enforces the allow lists and rules. For spend, that is the right layer: the limit lives outside the model's own judgment.

How should you budget a trial?

Use the logged would-have-accepted count to size the work, then price it with your own measurements. The formula for a month is: accepted work items x average billed cost per work item, where cost per item includes every model call, retry, tool call and abandoned attempt. Divide total spend by items that actually became merged or accepted changes, as in cost per successful task.

Illustration with assumed inputs, not DeepSeek data: 200 work items a month at an assumed $4 average billed cost each is $800. If only 140 produce an accepted change, the cost per accepted change is $800 / 140 = $5.71, not $4. The gap is the price of abandoned and rejected work.

What controls to set before turning on auto mode

• Keep the allow list small and add people deliberately. It is the first spend gate.
• Run in the default mode first and read the would-have-accepted log for at least a week.
• Cap parallel sessions and per-item spend at your model gateway or provider key, since the project documents no built-in budget. See three agent budgets and production spend guardrails.
• Tag spend by repository and work item so a pull request can be traced to its bill.
• Leave merging to people. The report says the agent does not enable auto-merge under its own account by default, because GitHub credits the merge to whoever enabled it, and that merge behavior is governed by a Delivery requirements prompt. Treat that prompt as a policy file with an owner.
• Watch idle cost. A listener that is always on has a standing cost even with no requests; see the background-agent cost clock.

Should you deploy it now?

For production, no: DeepSeek itself says it is not production-ready. For a contained trial on a non-critical repository with a capped key, it is a cheap way to learn what proactive agents cost your team, because the code is free and the spend is visible at your own provider. The decision metric is cost per accepted pull request against the attention it saves, not the headline that it competes with another tool.

Related

• What is DeepSeek Harness?
• Subagent fan-out and concurrency limits
• Background agents and the cost clock
• Three agent budgets

Want this applied to your stack? Bring the provider bills, gateway logs, and top workflows; we will map the cost drivers and savings path. Book a free audit →

Back to finopsllm.com