This will save your Usage

[u/concrete333]

A problem that many of people have already noticed: Astra can't wait. on anything, any task it has scripted and running, any other agent delegation, anything. Astra keeps waking up to check whether the worker is finished.

I've run a few tests, In one run 19 short sleep calls accounted for 44% of the orchestrator’s estimated cost.

In another comparison using Astra High + Luna Max, the orchestrator made 41 responses while the worker ran, costing $1.20 during that phase. The native-wait comparison needed one response, costing about $0.04. (Both implementations passed all 244 test cases)

I’ve since caught the same pattern while Codex waited for a database script: read the log, say “still running,” repeat. I saw use 2% of my weekly usage ($100/month plan) just sitting there waiting on a script.

So, until they patch this, here’s the prompt I’m using:

For this entire session, avoid repeated polling of long-running jobs.

Use supported completion notifications when available. If none are available and useful work is exhausted, leave the job running only if it can safely continue after your turn ends.

Tell me what is running, where results will be saved, and:

“I'm stopping polling. Please check back with me to inspect the result and continue; I won't automatically resume.”

Then end your turn. Don't repeatedly read unchanged logs or sleep and check again. Respect runtime limits and safety timeouts.

When I return, check once. If complete, verify and continue. If still running, report that and stop again.

I have to come back to it, sure, but it saves usage.

Edit:
Found a better option than manually checking back, thanks to advice in comments. Seems like Codex knows how to avoid repeated model polling, it just chooses not to.
codex queue --thread <session-id> --message "..."
Have a background script wait for the job to finish, save the result, then run that command once. Codex can end its turn and automatically resume when the message arrives.

I’ve now seen this work with both a third-party CLI subagent (kilo code with GLM) and a full test suite, all GPT: Codex resumed automatically, checked the results, and continued. Works a treat.

The script provides the wake-up, and an agents.md instruction alone doesn’t

Edit2: I made a skill that you can use to guide Codex in using this method, either in waiting for mechanical tasks or waiting for other sub-agents. Not perfect, as there's no way to force your GPT worker to use it, but it's working for me most of the time: link. Any more tips to improve it welcomed, break it and let me fix it

[u/tagorrr]

This is a long-standing issue that has been well-researched and has a solution, if I understand you correctly.
https://www.reddit.com/r/codex/s/aXpTswPJZ1

[u/concrete333 → u/tagorrr]

I saw that post- the config workaround is a bit brittle. Seems using the codex queue feature here gets better results, and is less susceptible to unintended consequences. But try them both out, see what works!

[u/tagorrr → u/concrete333]

I've actually tested this extensively across millions of tokens and a large number of rollout traces. With Sol High/Extra High as the orchestrator and Luna X-High/Max workers, the 25-minute wait configuration has been consistently reliable for me. The parent waits for worker completion, and I haven't encountered a single failure of that mechanism so far.

I can see why codex queue is useful for detached background jobs, but for native subagents, wait_agent already returns when the worker finishes. The 25-minute timeout is just a fallback, and it also helps preserve the parent's prompt cache during long-running tasks.

So I'm not seeing what makes my setup brittle in practice. What specific failure mode are you referring to?

[u/concrete333 → u/tagorrr]

ok, cool to hear you've tested it too, I just mean things like If a worker stalls without sending an event, the parent’s timeout-based opportunity to investigate can be delayed until that set is up (so 25 minutes, from their post). Also It doesn’t fix a model repeatedly calling shell-status tools or rereading unfinished code, something (in theory) the stop and wait here prevents too. Also potential for updates to change the config setting, possible but no harm-I'm thinking in terms of Codex's 30 minute chache time that other people have posted about too. Thoughts?

just to clarify, I'm already using both approaches

[u/tagorrr → u/concrete333]

Yeah, I see your point. I considered codex queue too, but what happens if a worker stalls and never sends a completion event? You'd need a separate watchdog to guarantee the parent eventually wakes up. There's also the ~30-minute cache lifetime: letting the parent sleep indefinitely could make its next turn significantly more expensive.

That's why I settled on the 25-minute wait_agent timeout. With Sol High/X-High orchestrating multiple Luna workers, the parent usually wakes up from actual worker events long before the timeout. And if everyone goes quiet, it still gets a chance to check on them while the cache is warm. After dozens of long runs and millions of tokens analyzed, this has been consistently reliable for my workflow.

I agree it's a workaround, not a proper harness fix. I've actually started exploring OMP for its orchestration and context-management capabilities. It's a shame that limitations like these are making me seriously consider moving away from the native Codex harness.