I'm running DeepSeek TUI v0.8.39 on Windows. I attempted to use parallel sub-agents (agent_open) to convert a 280-line Chinese biobanking standard into SOP documents — exactly the kind of parallel task offload that sub-agents are advertised for. All 5 sub-agents failed identically:
status: Failed: "API call timed out after 120s"
duration_ms: 731,203 (actual runtime: 12+ minutes)
steps_taken: 0
result: null
What's happening: The sub-agent does the work — it runs for 12 minutes — but the DeepSeek API terminates the response stream at 120s. Since sub-agents have allowed_tools: [] (no write access) and must return all output through the API response body, any task requiring more than ~30 seconds of generation is silently killed. The sub-agent has no way to checkpoint intermediate results or write them to disk.
Reproduction (trivial): Launch any sub-agent with a prompt that requires generating more than a few hundred words of output. It will time out. Lightweight tasks (read a file, return one line — ~30s) succeed. Anything substantive fails.
Impact: Sub-agents in their current form are limited to parallel read-only reconnaissance — grep, count, one-line summaries. They cannot be used for document generation, multi-step reasoning, code refactoring, or any task where output exceeds what fits in 120s of generation. This defeats the primary value proposition of sub-agent task offload.
Comparison with other tools in the same TUI:
Tool Timeout Configurable Can write files
─────────────────────────────────────────────────────────────────────────────────
task_shell_start user-defined (up to 600s) Yes Yes
rlm_eval sub-query configurable via rlm_configure Yes Yes (Python)
agent_open hardcoded 120s No No
What's needed:
-
Configurable sub-agent API timeout — expose in config.toml under [subagents] (suggested: default 600s, max 1800s). This is the minimum fix.
-
Write-tool access for sub-agents — let sub-agents use write_file so large results can be persisted to disk instead of squeezed through the API response pipe. Combined with the parent reading the file, this bypasses the response-size constraint entirely.
-
Streaming or intermediate checkpoint support — sub-agents should be able to report partial results before the final response, or the parent should be able to poll intermediate state.
Without at least #1, sub-agents are a demo feature, not a production tool. With a 120s ceiling, they add parallelism overhead (spawn + context transfer) to tasks that are faster to run sequentially in the parent session.
Summary: The current agent_open implementation is bottlenecked by a server-side 120s API response limit with no local escape hatch. This makes sub-agents useless for any real workload. Please prioritize exposing the timeout configuration and granting sub-agents write-tool access.
I'm running DeepSeek TUI v0.8.39 on Windows. I attempted to use parallel sub-agents (agent_open) to convert a 280-line Chinese biobanking standard into SOP documents — exactly the kind of parallel task offload that sub-agents are advertised for. All 5 sub-agents failed identically:
What's happening: The sub-agent does the work — it runs for 12 minutes — but the DeepSeek API terminates the response stream at 120s. Since sub-agents have allowed_tools: [] (no write access) and must return all output through the API response body, any task requiring more than ~30 seconds of generation is silently killed. The sub-agent has no way to checkpoint intermediate results or write them to disk.
Reproduction (trivial): Launch any sub-agent with a prompt that requires generating more than a few hundred words of output. It will time out. Lightweight tasks (read a file, return one line — ~30s) succeed. Anything substantive fails.
Impact: Sub-agents in their current form are limited to parallel read-only reconnaissance — grep, count, one-line summaries. They cannot be used for document generation, multi-step reasoning, code refactoring, or any task where output exceeds what fits in 120s of generation. This defeats the primary value proposition of sub-agent task offload.
Comparison with other tools in the same TUI:
What's needed:
Configurable sub-agent API timeout — expose in config.toml under [subagents] (suggested: default 600s, max 1800s). This is the minimum fix.
Write-tool access for sub-agents — let sub-agents use write_file so large results can be persisted to disk instead of squeezed through the API response pipe. Combined with the parent reading the file, this bypasses the response-size constraint entirely.
Streaming or intermediate checkpoint support — sub-agents should be able to report partial results before the final response, or the parent should be able to poll intermediate state.
Without at least #1, sub-agents are a demo feature, not a production tool. With a 120s ceiling, they add parallelism overhead (spawn + context transfer) to tasks that are faster to run sequentially in the parent session.
Summary: The current agent_open implementation is bottlenecked by a server-side 120s API response limit with no local escape hatch. This makes sub-agents useless for any real workload. Please prioritize exposing the timeout configuration and granting sub-agents write-tool access.