Summary

Multi-agent workflows hit the sub-agent cap even when most slots are held by completed agents. The model is then forced to manually agent_cancel finished work to free slots — busywork the runtime should handle. The default cap of 5 is also too low for any serious parallel workflow.

Symptom from a real run

Workflow: explore B1–B5 in parallel → start implementation in parallel as each exploration finishes. Transcript shows:

1. B1 Exploration — Beluga (Completed)
2. B2 Exploration — North Atlantic Right (Completed)
3. B3 Exploration — North Pacific Right (Completed)
4. B1 Implementation — Narwhal (Running)
5. B2 Implementation — Orca (Running)
6. B3 Implementation — Pilot (Running)

Failed to spawn sub-agent: Sub-agent limit reached (max 5, running 5).

Three agents are Completed but counted as running 5. The model then agent_cancels completed agents to free slots — pure ceremony.

Likely root cause

crates/tui/src/tools/subagent/mod.rs:767-781 — running_count() is supposed to exclude finished agents, but the filter relies on task_handle.is_finished(). Failure modes:

• The status update to Completed races with the next running_count() check.
• Persisted/resumed agents have task_handle: None, so a Running status with no handle counts as alive forever.

Two things to fix

1. Completed agents must stop counting toward the cap. After a sub-agent's task finishes, the manager transitions status before the next caller observes the count. Persisted agents with no live task are not counted as currently running.
2. Raise the default cap and make it configurable: default 10, override via [subagents] max_concurrent in ~/.deepseek/config.toml.

Related

Pair with #510 (lock contention) and #511 (summarize sub-agent output) — all three needed for multi-agent to actually work.