You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For loop-like behavior where say an implementer and reviewer thread is spawned by a coorindator, there's a lot of time wasted when an implementer or reviewer finishes, and the coordiantor is doing something like 5min waits to check on progress. If you have too short of a wait, the coordinator burns a lot of tokens checking something that's in-progress, but if you have too long of a wait, there's a ton of wasted time where the coordinator is waiting for something that's already finished.
The better result would be a first-class wait mechanism that can be interrupted by events like steer messages or spawned threads completing. That would allow the sleep period to be more of a timeout so that blocking tool calls/out of control threads can be identified by the coordinator, but it can also iterate without delay when things complete running.
Activity
github-actions commentedon Jun 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
danthegoodman1 commentedon Jun 21, 2026
#28144 is similar, but seems specific to goals. I'm also specifically calling out threads as a signal.
[-]Sleep conditionals[/-][+]First-party sleep/wait with wake signals[/+]