Raise the default wait_agent deadline from 30 seconds to 5 minutes
What feature would you like to see?
Raise the default wait_agent deadline from 30 seconds to 5 minutes:
- MultiAgentV2: change
DEFAULT_MULTI_AGENT_V2_DEFAULT_WAIT_TIMEOUT_MSfrom30_000to300_000. - Legacy multi-agent, while supported: change
DEFAULT_WAIT_TIMEOUT_MSfrom30_000to300_000, or document why its default should intentionally differ.
This is the default used when the model omits timeout_ms; explicit values and the existing configurable min/max bounds should continue to work.
Why?
Thirty seconds is much shorter than many normal delegated coding, research, build, and test tasks. When the child is still running, the timeout returns control to the parent model, which commonly issues another wait. Each expiry can therefore create another model sampling turn over a large parent context.
The timeout is not needed for completion responsiveness. Both implementations already wait on notifications:
- V1 subscribes to each child status receiver and returns when a terminal status arrives.
- V2 subscribes to parent mailbox activity and returns when completion, another agent message, or steered user input arrives.
A child that completes after two minutes therefore wakes an active five-minute wait at approximately two minutes. Five minutes is only the no-activity deadline.
This would reduce timeout-only model re-entry by roughly 10x for long subagent tasks while preserving immediate event-driven completion delivery.
Expected behavior
- Calling
wait_agentwithouttimeout_mswaits for up to 300,000 ms. - Child completion still returns immediately, well before that deadline.
- V2 mailbox activity and steered user input still return immediately.
- Explicit
timeout_mscontinues to override the default within configured bounds. - The tool schema, configuration defaults, and documentation report the same five-minute default.
Regression coverage
Please add tests establishing that:
- a child or mailbox completion before the deadline wakes
wait_agentimmediately; - no activity produces
timed_out: trueonly at the configured/default deadline; - a wait timeout does not change or terminate the child status;
- the model-visible tool schema advertises 300,000 ms as the default.
Tradeoff
A longer deadline delays parent reconsideration when a child is genuinely stuck or a notification is lost. Five minutes remains bounded, explicit shorter waits remain available, and V2 user steering interrupts the wait. The normal successful path should not become slower because it is notification-driven.
Related issues
- #18394 requests configurability. Current
mainnow exposesfeatures.multi_agent_v2.default_wait_timeout_ms, but the built-in default remains 30 seconds. - #34468 and #35259 cover repeated model-mediated status polling and token usage.
- #33276 reports a wait loop exhausting usage.
- #35108 covers nested code-mode wait boundaries.
Raising the default is a small defense-in-depth improvement and does not replace the stronger runtime fix proposed in #35259: re-arm unchanged waits inside the harness without returning to the model.
Source version checked
Current main at b7a61066081644e0d8b2c0b4dbfd7408ac1514df.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Closing because I filed this against the wrong repository. The intended implementation work belongs in downstream project repositories.