DeepSeek Harness subagents: delegation as a cost multiplier
Published 16 August 2026
The fastest way to multiply an agent bill is to let agents spawn agents. One user request becomes a tree, and the tree has no natural size. DeepSeek Harness treats delegation as a first-class subsystem with an explicit depth cap, which makes it a good place to study how the multiplier actually works.
Subagents are a seam, not a built-in
Delegation lives behind ctx.subagents, a capability seam rather than core agent-loop machinery. Unlike the shell executor, which permits exactly one implementation, subagent providers are registered by name and multiple can coexist. Documented transports cover in-process spawning and forking (creating ordinary agents through the parent's context), an ACP bridge for remote deployment, and Codex, Claude Code, and SDK-based implementations.
That plurality is the point. Where a child runs is a deployment decision with a price attached, and here it is chosen at composition time instead of compiled in.
Two delegation modes, two cost profiles
| Mode | Shape | Cost characteristic |
|---|---|---|
| One-shot | Create child, send prompt, await result, dispose | Bounded, attributable to the parent turn |
| Continuable | Durable background session with a resident activation | Open-ended; accrues across turns |
One-shot delegations resolve into a run handle with a terminal result promise. Continuable children are heavier: the continuation manager reserves identity, composes the child, and orders every turn through the child's inbox, with the provider contributing only initial creation metadata. Their activation moves through three states — running, waiting (quiescent but owning uncompleted child activations), and settled — and a message arriving with no live activation triggers a cold resume from the persisted session.
Cold resumes are the line item people forget. Reconstituting a child from its session log costs input tokens proportional to that log, and a chatty continuable child gets more expensive to wake the longer it lives.
Capabilities fail loud, not silent
Before delegating, the service validates the requested capabilities against the chosen provider. The specification is explicit that a request needing a capability the provider lacks is rejected with a typed error rather than accepted and then ignored. Start-time capabilities cover output schemas, depth limits, tool filters, and personas, each mapping one-to-one onto a request option.
This is the correct default for cost work. Silent degradation is how a tool filter meant to keep an expensive tool out of a cheap child quietly stops applying, and nobody finds out until the invoice.
Depth is capped, and the cap cannot be laundered
Delegation depth is persisted in the session header, with a runtime field tracking the greater value. Two rules protect it: a cold resume cannot lower depth, and a start is rejected if the derived depth exceeds the maxDepth cap or safe-integer bounds. You cannot reset the counter by restarting a child.
Discovery is cheap, delivery is authoritative
Two enumeration operations exist. listChildren() returns direct children from a live-preferred corpus with three-tiered acceleration — a watermark cache, then a projection checkpoint, then persistence inspection. listDescendants() walks the whole tree in pre-order, adding parent and depth positions. Both deliberately consult no agent registries, activations, or providers; message delivery remains the authoritative operation.
The practical read: you can audit the delegation tree without paying to instantiate it.
Results carry a stop reason
A subagent result carries the output (last non-empty assistant message, or the accumulated text stream), optional structured output validated against the requested schema, and a stopReason from a merge-extensible union: completed, aborted, error, max-tokens, refusal. Anything other than completed indicates partial output, and consumers map those to error tool results.
Track that distribution. A rising share of max-tokens or error stop reasons is spend that produced nothing, and it is usually the cheapest waste in the system to eliminate.
What to measure
- Children per parent turn, and descendants per user request.
- Maximum observed delegation depth against your configured cap.
- Share of continuable children resumed cold, and the log size at resume.
- Stop-reason distribution across all subagent runs.
Related
- DeepSeek Harness: what "everything is a plugin" buys you — the seam model.
- DeepSeek Harness goals and the Ralph loop — the other unbounded-iteration risk.
- Where to put spend guardrails in DeepSeek Harness — the enforcement points.
- The DeepSeek Harness session log as a cost record — where the numbers come from.
Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →
FAQ
How do subagents work in DeepSeek Harness?
Subagents are a capability seam registered by name in ctx.subagents, with multiple providers coexisting. Two modes exist: one-shot delegations that create a child, deliver a prompt, await completion and dispose, and continuable children that persist as durable background sessions.
What subagent transports does DeepSeek Harness support?
Providers include in-process spawn and fork backends that create ordinary agents through the parent context, an ACP bridge for remote deployment, and Codex, Claude Code, and SDK-based implementations.
How does DeepSeek Harness limit delegation depth?
Delegation depth is persisted in the session header and tracked at runtime. Cold resume cannot lower depth, and a start is rejected if the derived depth exceeds the maxDepth cap or safe-integer bounds.
Why does delegation depth matter for AI cost?
Each level of delegation multiplies the number of model calls made per user request. A parent that spawns three children, each of which spawns three more, has turned one request into a tree of billable work. Depth caps convert an unbounded fan-out into a bounded one.