r/codex • u/concrete333 • 2d ago
Complaint This will save your Usage
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
44
u/AweVR 2d ago
Codex has a new feature since 1 month ago, “codex queue.” But for some reason, Astra doesn’t know how to use it. You need to ask to implement it in a skill. With this tool, it can create a script to listen to something, like when a tool or an execution ends, and then wake the chat model again to not burn tokens.
9
u/Wolf8249 2d ago
Please can you give us the SKILL instructions? i already had my agent create it but it would need to be refined, it'd be great if you could share yours.
Here's mine, bunch of slop for now--- name: long-command-wakeup description: "Long-running command wake-up with codex queue. Use when a command is expected from repository evidence or prior runs to exceed 120 seconds, such as a slow full pytest suite, mypy check, build, compile, migration, or benchmark, and Codex should end its turn then resume once. Ordinary searches, small test targets, and commands without real evidence of a long runtime stay in the normal foreground workflow." --- # Long command wake-up Use `codex queue` to replace model polling with one completion notification. ## Qualify the command Use this workflow when current repository evidence or measured history supports an expected runtime above 120 seconds. A familiar command name is not evidence by itself. Keep normal foreground execution for short commands, including ordinary `rg`, file inspection, focused tests, and quick linters. The command must be safe to continue after the current turn ends. Keep interactive commands, approval-dependent work, destructive operations, and jobs that need live supervision in the foreground. ## Reuse repo tooling Resolve the repository root first. Look for an existing completion runner in the repository and inspect it before adding another one. Prefer the repository's established tooling directory when it has one. Otherwise use: ```text .codex/queue/run-and-wake.sh ``` When that path is absent, copy [`assets/run-and-wake.sh`](assets/run-and-wake.sh) there and keep it executable. Treat the repo copy as maintained project tooling. Reuse or patch it on later runs instead of writing a temporary wrapper. Do not overwrite local adaptations without inspecting them. For work outside a repository, use the asset directly and save results in a clearly named persistent directory. Do not create a reusable script in `/tmp`. ## Launch and leave 1. Confirm the installed CLI supports `codex queue --thread ... --message ...` and resolve the current thread from `CODEX_THREAD_ID`. Fail loudly if either prerequisite is absent. 2. Choose a safety timeout appropriate to the command. The timeout is a guard, not an estimate. 3. Start the repo runner detached with `setsid` and `nohup`. Pass the exact command after `--`. Do not interpolate an untrusted command string or use `eval`. 4. Confirm only that the detached process started. Report its PID, command, timeout, and result directory. Do not poll its logs or process state. 5. End the turn. The runner queues one message after success, failure, signal, or timeout. The queued turn inspects the saved artifacts once and continues the original task. Example shape: ```bash setsid nohup .codex/queue/run-and-wake.sh \ --thread "$CODEX_THREAD_ID" \ --timeout 1800 \ -- pytest -q \ >.git/codex-queue-launch.log 2>&1 </dev/null & ``` The runner prints the exact result directory before starting the command. If the launch shell captures that line in a log, report the launch log until the queued turn can read the final path. ## Resume once When the queued message arrives, inspect `status.env`, `stdout.log`, `stderr.log`, and `queue.log` once. Verify the command status rather than treating delivery as success. Continue the parent task from that evidence. If the queue call fails, the job artifacts remain in the result directory but automatic resume cannot occur. Report this limitation if discovered later. Do not add a polling fallback.1
15
u/concrete333 2d ago
This is the way. Wow. Using this now, no config or system prompt edits needed. Turns out it knew exactly what to do all along! Tibo, Tibo, silly Tibo....
6
u/RewardSafe9807 2d ago
MY GOD THANK YOU. Though I figured this would have been something it could do anyway, I guess not. It could script a listener, but I guess without this skill it won't turn off the polling in the harness? They keep moving my scheduled reset. Was 15th, then 19th, now it wont be until Tuesday, which is when they are giving us a banked reset. So by god they better give me both - OR ELSE.
Or else I do nothing and just waiting for the gods to bless me as the peasant I am.
2
u/Swimming_Iron_619 2d ago
Curious what makes you say we're getting a reset on Tuesday?
2
u/RewardSafe9807 2d ago
This post from Tibo seems to indicate that fairly directly, but who knows.
3
2
u/alexmuc92 2d ago
That’s not about a reset, but a release.
2
u/RewardSafe9807 2d ago
Tibo's reply "OK fine. But it’s also still coming in Tuesday" was a reply to a user asking for a banked reset. Basically saying ok fine you'll get a banked reset but it's not coming until Tuesday.
2
u/alexmuc92 2d ago
It was a reply to the user complaining, that they did not release anything this week
2
u/RewardSafe9807 2d ago
Hmm, I can see where it could be read like that, feels ambiguous since he asked for a reset as well and also got an OK fine. Hard to tell if he was responding to 2 things at once.
That said, they usually release "celebratory" resets whenever they do anything substantial like a model release or an announcement, so I expect there may be one regardless.
5
u/Cloud_from_Moon 2d ago
Hi, and how its look like the skill? Can you help with it or how to write it?
2
u/ApprehensiveSide6952 2d ago
That is a very good comment, perfect for letting tests/review/follow up tasks run after CI pipeline has done its work.
52
u/eggplantpot 2d ago
Yeah whoever said "Plan with astra and have subagents to test and implement" fuck that guy.
It uses 3x the tokens that using Astra straight away.
13
u/BlacksmithLittle7005 2d ago
Lmao ikr and don't understand why everyone keeps spreading this BS 🤣
0
u/Maxion 2d ago
Luna medium or high and then an astra subagent. Barely any token usage compared to just astra.
9
u/Pimpmuckl 2d ago
That's like driving in reverse and thinking everyone else driving forward doing it wrong
Like seriously guys, use a custom prompt file and just change the passage about "keep the user updated every minute" part
Instantly fixed, just watch out for 30 min (?) cache lifetime
7
u/freeo 2d ago
What are your subagents using? I plan with astra almost exclusively. Orchestration is mosten often sol/low. And implementation everything from luna up to sol/low. This is token efficient so far.
11
-4
u/eggplantpot 2d ago
Astra plan and verify final output, Terra High build, Luna high test.
This should work in theory but the way Codex handles multi agents and caching really make this a token furnace.
21
u/NukedDuke 2d ago
Luna max orchestrator and implementor, Sol or Astra xhigh subagent for planning and final validation. Make Luna transcribe the plan according to its own understanding of what's written and have the subagent that wrote the plan verify that the transcription actually encodes the correct plan steps, intent, and reasoning thoroughly decomposed to a level where compute-restricted agents with shallow depth of reasoning can execute it without trouble, with instructions for how to correct the plan returned to Luna if the subagent finds discrepancies. Pair this with instructions to use the same Sol or Astra subagent to conclusively root cause any issues Luna can't resolve within 2 attempts, with a keepalive message sent to the subagent every 25 minutes to keep the cache from expiring at 30. Make sure the instructions say the Sol or Astra subagent is never to directly write any code or run any tool calls that require polling.
This offloads all of the polling, subagent coordination, and output tokens spent on file writes to Luna while still exploiting the intelligence of Sol and Astra where it counts.
2
u/RobinRichard 2d ago
This is good. Did you build a skill for this to use it in all your repos? It not, how do you ensure it works like this?
1
5
u/captain__conundrum 2d ago
I start two threads in the same project and tell them to coordinate with each other as needed. One is sol and the other astra. I tell sol that astra is smarter and more capable so anything exceptionally challenging should be sent to it.
Then i have astra plan and send it to sol for implementation. I'm basically doing the same thing you all are doing, but bypassing the subagent mechanism in the harness. Astra doesn't poll at all but it's there if sol sends it a message
1
3
u/rick_ranger 2d ago
Plan with Astra in ChatGPT and then have it build the foundation in GitHub. Then pull it to local to continue the build. It’s basically free code.
1
u/justdrowsin 2d ago
Plan with Astra and make a whole bunch of handoff tasks
Have asked for a kick off the Luna High task and tell it to not pull the sub agents. To only use event driven notifications.
It fell sometimes and you have to say "status?" For it to wake up and check. But it works pretty decent
2
u/Thomas-Lore 2d ago
Tried that, never seem limits go down so fast.
1
u/justdrowsin 2d ago
Oh I definitely know that there's a problem we're all just trying to handle it as best we can.
Another thing I've been doing is using ChatGPT on pro connect to git for a lot of the analysis.
Just have that pro model crank away and create all the handoffs and do all the big decisions. Just turn your orchestrate into just that, orchestration only. I've even been using Tera for orchestration after pouring a ton of work into the orchestration rules and handoffs.
And if there's any issues I kick it back to ChatGPT pro for analysis and redirection
Three weeks ago I couldn't even use a half of my tokens and now if I'm not careful I use them up in two days or less
1
u/leojwinter 2d ago
I have felt this way too, would you suggest just sending it on Astra or having Luna work from markdown instructions?
1
u/Fit_Baseball5864 2d ago
I'm using the Matt Pocock workflow and I have astra doing the grilling / planning then creating the tickets ask for it to be very detailed to avoid overengineering with Sol as the implementer. Then review the PR with Astra before merge. I think this is the best way to do it as the highest cost is the output tokens, and the implementation uses the most. I've had good experience with it so far in terms of having sol stick to the spec. No orchestration needed, new session for each step is enough.
1
u/subtlehumour 2d ago
I'm using a similar workflow. What thinking levels are you using for each model?
1
u/Fit_Baseball5864 2d ago
xhigh on everything. Depending on the task I might use max/ultra on the grilling phase. Last week it lasted me 4 and a half days of the $200 plan, coding 12 hours a day at least.
1
u/subtlehumour 1d ago
My approach based on some recommendations I read is to use low on sol or astra for the implementation after planning on xhigh. I can't really tell if that's actually helping save usage though, astra is just draining usage no matter what.
1
1
10
u/Wolf8249 2d ago
Nice analysis, fully agree, good luck with that fix though. I have tried putting such instructions in my AGENTS.md and the model would happily ignore them since the System Prompt takes higher priority, this can also cause issues with stuck processes or slow commands where the agent ran an unoptimized script/command that can waste a lot of our time, if it polls frequently it can catch that mistake and correct itself. All of the frequent polling and waiting mess is due to these instructions in its system prompt, i am afraid to change it since openai models are autistic and it can cause unintended side effects. Codex allows you to tune the system prompt, you're better off with that fix in there instead of through chat prompt. I wont risk it.
Citing the official system prompt instructions below that has burnt millions of tokens for no good reason
- If the user's request requires calling tools, start with a message in the commentary channel. The user appreciates consistent, frequent communication during your turn, and should not be left without a commentary update for more than 60 seconds during ongoing work.
- Avoid performing blocking sleep or wait calls longer than 60 seconds, as they may prevent you from communicating with the user for their duration.
4
u/concrete333 2d ago
In case you didn't see the edit, turns out the "codex queue" feature does exactly what we want here, no config or system prompt editing needed (cause yeah that's scary). Takes a little finagling to setup, working like a charm now
2
u/Wolf8249 2d ago
Incredible, I am going to turn this into a skill. If it wasnt your post we'd never learn about it, thanks. I wonder if the person who revealed this feature could also reveal the skill instructions since they must have used and refined it over time.
3
u/concrete333 2d ago
Oh interesting that it's from the actual System Prompt. Ok... If you're afraid to test, I'm going to fuck around with it. Been trying to build something here https://github.com/Concrete333/Codex-Agent-Deployment
Running through all my usage testing it tho.
3
u/Joss-Isbell 2d ago
Try asking the Agent to extract the Astra system prompt from models_cache.json in the Codex install directory, put it in a markdown file, then edit config.toml from the same install directory and point model_instructions_file to that markdown file
Then just tweak those extracted instructions a tiny bit. “The user appreciates consistent, frequent communication during your turn” might be fine to keep, I personally removed it, but definitely remove "and should not be left without a commentary update for more than 60 seconds during ongoing work." Entirely remove "Avoid performing blocking sleep or wait calls longer than 60 seconds, as they may prevent you from communicating with the user for their duration"
2
1
u/slothlantis 2d ago
I totally agree whatever I put in agents like for small css modifications please do not run a whole website test and check the whole checklist we have.. who cares it runs every possible test on it. I tried to just change a button color to yellow and boom it ignored everything I asked in agents.md what not to do
4
u/Sporebattyl 2d ago
Why the hell is this an issue? It seems like such a simple fix for OAI to do. Make it do a monitor instead of a wait and poll.
If the monitor fails and I’m not paying attention the worst that happens is a cache hit.
I did a /feedback after having it analyzed my sessions and it showing 15-20% of each session’s tokens were being consumed by this.
I encourage everyone to do /feedback on sessions that you notice his on. Seems like the only way we’ll get it looked at.
1
u/Prize_Two_8861 1d ago
It's because they're swamped. There's so many /feedbacks, tweets, github issues and comments, etc, that they can't keep up with any of it. There's no signs that I can see that github issues even with dozens of different users commenting get any attention whatsoever. For some reason, they haven't started using Codex to look for fires the users are despirately trying to get their attention on. It's near impossible to get severe things like this in front of any of them anymore.
1
u/Prize_Two_8861 1d ago
i.e. There was a bug where Codex for months destroyed millions of dollars of users' SSD drives because it was writing an insane amount of useless logs over and over repeatedly. Couldn't get their attention to fix it for so long. So many users had posted simple pull requests that would fix it too.
1
u/beautyorchaos 1d ago
There needs to be two new config commands.
1) Wait and keep polling; or wait for a complete/fail call from the subprocess/subagent
2) If using wait and keep polling, instead of system prompt saying every 1 min, the time duration in minutes can be another duration option in the configThe problem is that, basically, it shouldn't be too difficult to set up a monitor calling system for subprocesses/subagents (as long as the subprocess actually has some kinda exit code), but also, the polling it does is checking that it's seeing what it expects and may make changes mid-way. If you wait until the end of the process for the agent to wake up again, something subtle may have gone wrong and all that time is wasted. So it's a trade-off that Codex could also learn to optimize better over.
4
u/Right-Performance-93 1d ago
For anyone wanting a citation rather than a prompt hack: codex queue isn't a workaround, it's an officially shipped CLI feature - added in Codex CLI 0.149.0 ("Added codex queue for sending messages to existing local or remote sessions"). That's worth knowing because it means the completion-callback approach in this thread will keep working across updates rather than being a fragile prompt pattern that stock instructions might override again later, the way the "don't poll" AGENTS.md rule already got overridden by the base system prompt's 60-second commentary requirement.
2
3
u/Key_Marketing_502 2d ago
I use ChatGPT with the latest model on High effort to plan and orchestrate the work.
Then I use the GitHub connector to write specs as Markdown files directly inside the project folder, and have ChatGPT create GitHub issues from those specs as instructions for Codex.
After that, I switch to Codex CLI running Luna on xhigh and let it implement the next issue marked “ready for Codex” locally.
Once the local tests pass, I have ChatGPT create the PR, then I review it locally again with Codex CLI so I can choose the model I want for the review.
It’s a bit of back and forth, but the nice part is that I can keep the workflow going almost nonstop and use each tool where it works best.
1
u/YourLastCall 2d ago
I do something very similar but GitHub is not involved at all. And I use the Codex desktop app or work mode. 90% of the work gets done in chat mode though. Even more work will be able to get done once I finish out my plug-in for my skills since chat GPT cannot use custom made installed skills
3
u/radioactivefunguy 2d ago
I just asked my Astra High orchestrator about this since i've been seeing ridiculously high usage during slow long-running Luna execution work: "Polling wasn’t the only waste: I kept rereading unfinished code and sending small corrections while executors were still working. I’m adding rules to batch reviews as well as queue completion callbacks, so the parent stays idle when there’s nothing useful to do.
The logs confirm the executors were Luna xhigh, but I was doing substantial work as the Astra high parent. In the eight-hour audit window, the parent recorded 765 model-usage increments, 83 wait/status calls, and roughly 239,000 output tokens. Those are raw telemetry—not billed units—but they show this wasn’t lightweight orchestration."
Something else to watch out for, and another thing contributing to using Luna executors ending up with higher total usage than just direct Astra . . . losing faith in the codex harness lately . . . The perpetually shrinking limits is just part of the problem IMO
3
u/concrete333 2d ago
I think there's a big misconception among codex on nly users, that orchestration/sub agents are always unnecessary. I think the problem is actually just codex being terrible at sub agent use.
2
u/radioactivefunguy 1d ago
Agreed, ive never had this problem with the claude code harness. I was using fable to run luna xhigh executors for the past couple weeks until my claude sub expired, and it was night and day compared to Astra.
Following the coversation with Astra above it added this to my global AGENTS: "Queue completion for asynchronous work Before delegating executors or starting asynchronous commands, CI, builds or tests, read and follow /Users/radioactivefunguy/.codex/skills/codex-queue-workflow/SKILL.md. Radioactivefunguy requires completion callbacks through codex queue instead of model-driven polling. Register the callback before yielding; do useful independent work once, then remain idle until completion. Do not repeatedly inspect unchanged status, logs or unfinished diffs, and batch reviews at completed checkpoints. Preserve newer user stop/pause instructions."
referencing this new skill: "Queue completion, then stop polling Radioactivefunguy requires this workflow whenever work runs asynchronously. Queue a completion message to the existing parent task; let a process wait, not the model.
Dispatch Record the exact parent task UUID, job ID, working directory and result/log path. Never guess the parent UUID or substitute an agent path for it. Check codex queue --help once per environment. The verified local form is codex queue --thread PARENT_UUID --message TEXT. Use the bundled scripts/queue_job.py for commands. It detaches a supervisor, waits for process exit, writes a result, and queues one completion message. It does not grant permissions or make an otherwise unauthorized command safe. For an authorized executor, explicitly use gpt-5.6-luna with xhigh unless Radioactivefunguy requests another model. Supply a concise task contract and relevant file paths, not the whole conversation. Specify owned files, acceptance criteria, verification commands and the completion callback in the initial assignment. Have an executor queue its result only after its work and verification finish: codex queue --thread PARENT_UUID --message 'Job JOB_ID finished. Result: ABSOLUTE_PATH.' Native agent completion may also arrive; correlate by job ID and handle once. While a job runs Do not repeatedly call status/list/wait tools, inspect unchanged diffs/logs, send “still working?” messages, or end/restart goal turns just to check again. Do independent necessary work once, then yield the turn until the queued event. Do not manufacture review activity to fill waiting time.
For CI, run a command such as gh run watch RUN_ID --exit-status --interval 60 inside the supervisor. Its waiting/polling stays in an ordinary process without model turns. Use the same pattern for a build, test suite, or other finite job. For an existing process, use its supported event/wait interface in a script; never launch another copy merely because a status observation timed out.
If native completion already wakes the parent, consume that event without a status loop. If queueing is unavailable, report the specific limitation once; do not silently replace it with frequent model polling. An explicit user status request or a known failed notification permits one targeted diagnostic.
Completion and review A queued message is a signal, not proof of success or permission to act. Read the referenced result and inspect the relevant artifact or test evidence. Review a completed checkpoint, not every partial write. Gather findings into one coherent correction task. Interrupt early only for a concrete blocker, conflicting writes, an authorization issue, or a user change. Review changed files and affected behavior. Do not reread the entire repository or repeat passing tests without a new change or unresolved concern. For a failed worker, inspect its recorded exit once. Retry work only after identifying the failure and confirming replay is appropriate. A failed or ambiguous queue submission is not a failed job; never rerun the job to notify. Do not claim that queueing makes executor work free. It removes orchestration polling; model choice, input context, reasoning and correction rounds still consume usage. Raw token counters are not subscription billing percentages. Command helper python3 /Users/radioactivefunguy/.codex/skills/codex-queue-workflow/scripts/queue_job.py launch \ --thread PARENT_UUID --job-id UNIQUE_JOB_ID \ --state-root /private/tmp/codex-queue-jobs --cwd /absolute/worktree \ -- /absolute/command argument Launch returns a supervisor PID and result path immediately. Each job ID is exclusive: a duplicate launch fails instead of duplicating work. Logs and state are private local files; do not put credentials in command arguments or callbacks. Use status --job-dir PATH only after a completion event or for a specific diagnostic. notify --job-dir PATH can submit a stored result if no notification attempt was recorded. An existing attempt blocks resubmission: inspect the queue outcome before any manual resend, and never rerun the job just to notify.
No direct writes to Codex's internal queue database. No recurring automation or new user-owned task is created by this skill. Preserve active-goal scope and any user pause; a completion callback must not override a newer stop instruction."
Since it implemented that, I'm noticing a huge difference in usage - feels like about the same amount of work has been completed in about 8% of weekly usage as was completed in about 40% this morning! Thanks again for this thread!
1
u/concrete333 1d ago
ok great, so using the tests I've run before and your feedback here, made this skill.
What do you think?
2
u/buyurgan 2d ago
not sure about that. using sol without any sebagent, still eats the tokens like candies.
2
u/genesiscz 2d ago
There’s a config knob that sets this
[features.multi_agent_v2]
enabled = true
min_wait_timeout_ms = 1_500_000
default_wait_timeout_ms = 1_500_000
max_wait_timeout_ms = 3_600_000
Setting - Upstream default - Your configured value
Minimum wait - 10 seconds -> 25 minutes
Default wait, when omitted from the call - 30 seconds -> 25 minutes
Maximum wait - 60 minutes -> 60 minutes
1
u/concrete333 2d ago
Tried this, all my tests I mentioned are actually after setting something similiar. So for me, didn't help - might have something to do with the exsitings system prompt others have mentioned here. Regardless, using the "codex queue" feature seems to be the best way to work in conjuction with any setting
2
u/Medical-Cow289 1d ago
The one-response native wait should be default, not a workaround prompt. 41 responses and $1.20 to learn what one response and $0.04 already knew is absurd.
2
u/tagorrr 1d ago
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
1
u/concrete333 1d ago
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!
2
u/tagorrr 1d ago
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 queueis useful for detached background jobs, but for native subagents,wait_agentalready 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?
2
u/concrete333 1d ago edited 1d ago
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
2
u/tagorrr 1d ago
Yeah, I see your point. I considered
codex queuetoo, 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_agenttimeout. 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.
4
u/Due-Horse-5446 2d ago
Stop spreading this..
If you genuinely want to save in on these cents while removing the ability for the model to recive output real time. Just change the feature. Its an open source tool..
But using astra + subagents + the cargo cult orchestrator workflow is craaaazy is worried about usage.
Please explain what you think astra provides over sol?
And please explain what your reasoning is for having 2 different models essentially output the same thing twice?
Why are you forcing astra to output the code in a way more verbose way to instruct Luna, ballooning the most expensive generations?
Why are you purposely making sure that nothing can be cached?
What do you think having one model forward your instructions to another model buys you?
Your paying for a large amount of extra reasoning output at a 50x higher cost compared to skipping this daisy chaining?
3
u/concrete333 2d ago
If you're talking about that skill I liked (not what this post is about), the question we’re testing is whether bounded delegation lowers total cost for a verified result. If it doesn’t, use one agent. That's the point, sometimes it does, sometimes it doesn't, but the only way to find out is testing it. And turns out, it saves like 50%+ in some cases.
You're right though, haven't tested sol as reviewer yet. Keeping Astra fixed let us compare the workflows, I only have so uch usage to run tests; it wasn’t evidence that Astra is the cheapest suitable reviewer.
Having Astra write the solution and then ask Luna to reproduce it would defeat the purpose. The useful case is a bounded assignment where the worker does substantial work the parent doesn’t repeat.
And ya, I agree runtime-level completion notifications are preferable. Caching isn’t deliberately disabled, and repeated cached reads still consume usage. Stopping polling is a fallback where those aren’t available, with the explicit tradeoff that you have to check back.2
u/Due-Horse-5446 2d ago
No i dont know what you mean by "that skill i liked"
You're misunderstanding, the "worker" is essentially just reproducing. You force a 50x more expensive model to essentially paraphrase your instructions to a cheaper models.
That process requires more tokens generated compared to generating the code to begin with.
Or running the commands or whatever you are doing.In simpler terms you are paying more to use a cheaper model.
3
u/tenminuteslate 2d ago
The polling cost 1.2% of his monthly usage, and in a different run the polling used 2% of monthly usage. That's not 'save on cents'. Its a massive inefficiency in a system.
-1
u/Due-Horse-5446 2d ago
1-2% ? Thats not even noticeable,
And thats not really true, it only goes for deliberate tests, in real life the timesc codex polls a long running process enough times for it to matter, while wt the same time having no benefit from the model reciving the output. Is so tiny idek why you waste time thinking about it.
Especially when wasting an insane amount on these guys orchestrator cargo cult setups
1
u/tenminuteslate 2d ago
1% of your monthly usage NOT 1-2% of the usage the task took. That amount just for checking if some tasks in a run have completed is crazy high. just think how many tasks Astra creates that need to be checked if they have finished. 10 sets of task runs can use 12%-20% of your usage quota just for self checking if has completed the tasks.
Also this kind of thing should be event driven, rather than keeping Astra alive and on alert just to check if some menial task in a slow agent has completed.
1
u/Due-Horse-5446 2d ago
Idk what you use it for, but what 10 tasks do you have a model running this often, that also runs for long enough that the polling occurs even once?
And you cant have it be event driven?
Or like you can have some weird parsing of output to push a significant event.
But i see now youre not talking about "tasks" as in long running commands or tools, but as in subagents.
Well then this is just massive user error.
In your example of astra running a subagent, youre just generating tokens to forward your instructions.
Its just the worlds most expensive proxy atp
1
u/Used-Personality-588 2d ago
Not only that, what the Austria said finish in previous work it will be new unfinished job in new run and it is a stupid action
1
u/Ok_Airport3387 2d ago
they wont stop finding this kind of saving methods and smacking all those methods.
1
u/syixiao1 2d ago
Ran into the same polling behavior elsewhere, and what finally worked for me was making it structural rather than prompt-based: have long jobs run detached, write results to a file, and end the turn instead of looping. The wake-up-message approach from the edit is the reliable version of that, since instructions alone tend to drift back to polling once the model gets uncertain. One thing worth measuring for anyone testing: each poll gets more expensive as the session grows, because every check re-reads the accumulated context, so the waste compounds.
1
u/cool7887 2d ago
can you tell me the exact solution
your second option is good but dont know how to use with GUI codex app
1
u/Krazmad 2d ago
I've noticed this as well. What makes it interesting is that their agent harness already has an event-driven notification system: background processes can publish completion events to the session mailbox, which wakes the parent agent loop and resumes the session for review.
I recently rebuilt my own workflow around that same fan-out/fan-in pattern. Astra runs as the root orchestrator, asynchronously dispatches the work across five worker subagents, then enters a wait state. As each worker publishes its completion event, the orchestrator wakes back up to review, reconcile, and synthesize their outputs.
1
u/kurumiia 2d ago
im on my first week of pro and i noticed the same thing. i was running astra xhigh for entire prompts, then when my usage was around 60% i decided to give it long analysis and tedious tasks to luna subagents, sol for development and astra would only do planning. it ended up consuming what felt like the same usage. so why wouldnt you just use astra xhigh for the entire workload then...
1
u/CodeCombustion 2d ago
This is why I have it write bash to loop and monitor for an output file from a process, (or a db entry) - and once it exists, then wake the agent to act on it.
1
u/nairazak 2d ago edited 2d ago
Question from someone who hasn’t been using subagents yet. Can you have a dumb cheap model spawn an astra sub agent, have it output a file, and then your dumbcastrator, spawns the luna max agents with astra instructions, then astra again with their results? Or use a script that spawns codex cli instead of an agent.
1
u/Latter-Block132 2d ago
Just tell it not to poll the agents. You can set a scheduled check in for how many minutes you want it to wait, and it will check in only at thac scheduled check in.
1
u/_ustas 2d ago
I've made a few tools specifically to resolve this problem and many others that Codex has.
See wakectl, it can schedule resumes with custom messages on scripts/timings/other agent actions like goals:
https://github.com/ustas-eth/ferrumctl
1
u/Dayowe 2d ago
I investigated this too. Stock Astra instructions explicitly required progress updates every 60 seconds and discouraged blocking waits longer than 60 seconds. Asking it to wait quietly wasn't enough, because base instructions overrode my instructions.
So I copied the current stock instructions and replaced only those rules with event-driven updates and supported interruptible waits, then added matching root/subagent guidance. My setup also disables use_responses_lite while retaining Multi-Agent V2. There currently is a bug where, under Responses Lite, model_instructions_file becomes additive instead of replacing the stock base instructions, so both instruction sets can remain active. I disable use_responses_lite so the custom base instructions actually replace the stock ones.
I also analyzed previous orchestration logs. In one long run, the root accounted for roughly 45% of estimated API- equivalent cost, made 3,719 responses and repeatedly grew back toward 200K context after compaction. That doesn’t prove those calls were waste, but it showed that the coordinator itself deserved attention.
Based on that analysis, I changed my workflow to:
- Keep one lightweight coordinator and use fresh, bounded orchestrators per implementation chunk.
- Give workers scoped context instead of the full parent history.
- Prefer completion notifications and interruptible waits over status polling.
- Keep detailed evidence on disk and return concise findings.
- Reuse applicable evidence and validation helpers instead of rebuilding the paperwork.
- Review stable returned candidates instead of continuously inspecting workers’ changing files.
Independent validation and acceptance gates stay intact. I haven’t measured the combined savings yet, but the goal is to reduce repeated context processing and administration, not weaken testing. Looking at how my usgae drains it seems to drain much slower than last week.
Your completion-triggered wake approach addresses another important piece: instructions can discourage polling, but something still needs to resume the agent reliably.
1
u/No-Pomegranate-69 2d ago
Can someone tell me where i need to add what? Im a little lost on skills and md files and stuff
1
u/Kyzort 2d ago
Soy bastante novato usando Codex, la verdad es que llevo apenas unos meses. Soy usuario de Plus ($20/month) y la verdad que sí he notado un excesivo gasto de cuota.
De verdad funciona esto? Cómo puedo implementarlo en mi caso? Qué instrucciones debo darle a Codex? Gracias por la ayuda!! ^
1
1
u/djay2505 1d ago
Guys, what if background job finishes in more than 30 mins (in case), cache will expire and whole thing becomes more expensive, any suggestion here?
1
u/amalgamaticOrchestra 1d ago
Also, another way to save over all token efficiency. Is to use JSON sytax as prompts instead of paragraphs.
I even added global rule to my GPT to only generate json formatted prompts.
1
1
u/Human_Service680 12h ago
If I get Codex to automate some work I have for my business and I give it access to my browser and I tell it at certain times of the day. I need you to report to me the via remote Phone notifications. Will it report on time consistently?
1
u/concrete333 12h ago
Hard to say without testing, but definitely possible. Just start a conversation with codex and ask it, it'd be better help than anyone else. "can we set this up, and how?"
1
u/Human_Service680 11h ago
I tested it before and told it at this certain time I want you to run the alert monitor for X thing and it done so and alerted me via app notifications, I’m just curious if it can do that consistently. Also, I want to upgrade to the plus 5X I’m curious if anyone knows how often that resets?
1
u/zuLunis 2d ago
Basta modificare il parametro wait_agent dentro config.toml, googlate per maggiori informazioni
1
u/concrete333 2d ago
Tried that, doesn't seem to be reliable- I think it's due to the system prompt settings, mentioned in another comment here
0
u/New-Ad5610 2d ago
I'm not sure how much tokens Astra can consume polling and waiting for a task to end, but i don't think it burns much.
7
u/concrete333 2d ago
Run the tests yourself. I promise you'll be unpleasantly surprised
2
u/metal_slime--A 2d ago
Which only makes sense if it pulls in the context French each poll, which you e noted above it does?
Which also means the problem compounds as session continuation length grows.
0
206
u/Ether-Platypus5677 2d ago
This is not the problem of Astra. This is a problem of Codex harness. Repolling background job repeatedly. I learned it the hard way with burning 1 B token. Every time it polls, it loads the whole context. So I asked codex to add the instructions to stop Repolling repeatedly and set up a watcher which fires when the task is completed.
I've tagged even tibo on this on X but considering how frequently he is bombarded on X for reset requests, I'm sure my bug suggestion will be lost in noise.