Feature hasn't been suggested before.
Describe the enhancement you want to request
Summary
In subagent mode, there seem to be two scheduling / interaction issues:
While subagents are running, the main session cannot accept new user input.
When multiple subagents are launched in parallel with a concurrency limit, if one subagent finishes early, the next queued subagent does not start automatically. It appears the system waits until all currently running subagents finish before dispatching the next batch.
This makes subagent execution behave more like batch barriers instead of a rolling worker pool.
Environment
opencode
subagent mode
parallel subagents with max_concurrent_agents set (example: 5)
OS: Windows
Model shown in UI: gpt-5.4
Screenshot attached
Reproduction Steps
Start a task that uses subagent mode.
Dispatch multiple subagents in parallel, with a concurrency cap such as:
max_concurrent_agents: 5
Queue more work than the concurrency limit allows.
Example: first run ch01–ch05, then expect ch06–ch09 to start as slots free up.
Observe that:
some subagents finish earlier than others,
but queued subagents are not started immediately when a slot becomes available.
Also try sending a new user message while subagent mode is active.
Observe that the session does not accept / process the new user message.
Expected Behavior
-
User input handling
The main session should still be able to receive and process new user messages while subagents are running, or at least provide a clear interaction model for interruption / enqueue / cancellation.
-
Rolling subagent scheduling
With max_concurrent_agents: 5, subagents should behave like a worker pool:
if 5 are running and 1 finishes,
the next queued subagent should start immediately,
without waiting for the other 4 to finish.
In other words, scheduling should be rolling / slot-based, not batch-based.
Actual Behavior
The main session cannot accept new user input during subagent execution.
Finished subagents do not release their slot for the next queued subagent immediately.
The next queued subagents only start after the whole current parallel batch finishes.
Why this is a problem
This reduces throughput significantly for uneven task durations.
Example:
ch01 finishes in 1 min
ch02 finishes in 3 min
ch03 finishes in 2 min
ch04 finishes in 5 min
ch05 finishes in 4 min
If ch01 finishes early, ch06 should start right away.
Instead, the queue waits until ch02–ch05 all finish, leaving available capacity idle.
This also makes long-running subagent workflows less interactive because the user cannot send follow-up instructions during execution.
Suspected Root Cause
Possibly the scheduler is currently implemented as:
dispatch one batch up to max_concurrent_agents
wait for the whole batch to settle
dispatch the next batch
instead of:
maintain a live pool
whenever any subagent completes, pull the next queued task immediately
There may also be an input lock / session lock while subagent mode is active.
Suggested Fix
Change subagent scheduling from batch barrier to rolling queue / worker pool.
Release a concurrency slot immediately when a subagent completes.
Automatically dispatch the next queued subagent as soon as a slot is free.
Allow the main session to continue accepting user input while subagents are running, or expose a clear policy:
allow message interrupt,
enqueue message,
or offer cancel / pause / reprioritize controls.
Additional Context
In my case, after some subagents completed, the UI still showed the follow-up task as queued instead of starting immediately.
Example expectation:
start ch01–ch05
if ch01 completes first, immediately start ch06
if ch03 completes next, immediately start ch07
etc.
Current behavior seems to wait for the entire first wave to finish before starting the next wave.
Feature hasn't been suggested before.
Describe the enhancement you want to request
Summary
In subagent mode, there seem to be two scheduling / interaction issues:
While subagents are running, the main session cannot accept new user input.
When multiple subagents are launched in parallel with a concurrency limit, if one subagent finishes early, the next queued subagent does not start automatically. It appears the system waits until all currently running subagents finish before dispatching the next batch.
This makes subagent execution behave more like batch barriers instead of a rolling worker pool.
Environment
opencode
subagent mode
parallel subagents with max_concurrent_agents set (example: 5)
OS: Windows
Model shown in UI: gpt-5.4
Screenshot attached
Reproduction Steps
Start a task that uses subagent mode.
Dispatch multiple subagents in parallel, with a concurrency cap such as:
max_concurrent_agents: 5
Queue more work than the concurrency limit allows.
Example: first run ch01–ch05, then expect ch06–ch09 to start as slots free up.
Observe that:
some subagents finish earlier than others,
but queued subagents are not started immediately when a slot becomes available.
Also try sending a new user message while subagent mode is active.
Observe that the session does not accept / process the new user message.
Expected Behavior
User input handling
The main session should still be able to receive and process new user messages while subagents are running, or at least provide a clear interaction model for interruption / enqueue / cancellation.
Rolling subagent scheduling
With max_concurrent_agents: 5, subagents should behave like a worker pool:
if 5 are running and 1 finishes,
the next queued subagent should start immediately,
without waiting for the other 4 to finish.
In other words, scheduling should be rolling / slot-based, not batch-based.
Actual Behavior
The main session cannot accept new user input during subagent execution.
Finished subagents do not release their slot for the next queued subagent immediately.
The next queued subagents only start after the whole current parallel batch finishes.
Why this is a problem
This reduces throughput significantly for uneven task durations.
Example:
ch01 finishes in 1 min
ch02 finishes in 3 min
ch03 finishes in 2 min
ch04 finishes in 5 min
ch05 finishes in 4 min
If ch01 finishes early, ch06 should start right away.
Instead, the queue waits until ch02–ch05 all finish, leaving available capacity idle.
This also makes long-running subagent workflows less interactive because the user cannot send follow-up instructions during execution.
Suspected Root Cause
Possibly the scheduler is currently implemented as:
dispatch one batch up to max_concurrent_agents
wait for the whole batch to settle
dispatch the next batch
instead of:
maintain a live pool
whenever any subagent completes, pull the next queued task immediately
There may also be an input lock / session lock while subagent mode is active.
Suggested Fix
Change subagent scheduling from batch barrier to rolling queue / worker pool.
Release a concurrency slot immediately when a subagent completes.
Automatically dispatch the next queued subagent as soon as a slot is free.
Allow the main session to continue accepting user input while subagents are running, or expose a clear policy:
allow message interrupt,
enqueue message,
or offer cancel / pause / reprioritize controls.
Additional Context
In my case, after some subagents completed, the UI still showed the follow-up task as queued instead of starting immediately.
Example expectation:
start ch01–ch05
if ch01 completes first, immediately start ch06
if ch03 completes next, immediately start ch07
etc.
Current behavior seems to wait for the entire first wave to finish before starting the next wave.