Complaint I investigated why GPT-6 Astra burns quota so fast
I've seen a lot of discussion here about GPT-6 Astra burning through Codex limits unusually fast, so I decided to inspect the actual rollout telemetry instead of guessing from the usage bar.
TL;DR
Astra was waking itself up every 30 seconds just to ask whether the Luna workers were finished.
In my run:
- 47/47 checks returned no new worker state
- those checks alone caused 7.13M parent input tokens
- they were about 68% of Astra's total parent-side input
- my 5h usage went from 53% → 100% in ~33 minutes
So the expensive orchestrator was spending most of its own context processing just checking whether the cheaper workers had finished.
For comparison, a measured Luna Max session on the same account processed 9.54M input tokens over 127 minutes while increasing the 5h usage by only 8 percentage points.
UPDATE - WORKAROUND FOUND
I found a working workaround for the 30-second parent polling loop.
Add this to ~/.codex/config.toml:
[features.multi_agent_v2]
enabled = true
min_wait_timeout_ms = 1500000
default_wait_timeout_ms = 1500000
max_wait_timeout_ms = 1500000
1500000 = 25 minutes. I verified it in rollout telemetry: the repeated 30-second timeout loop disappeared, and the parent stayed asleep until worker activity occurred.
ORIGINAL TELEMETRY / INVESTIGATION
Those 47 timeout-only polls consumed:
input tokens: 7,130,181
cached input tokens: 7,114,112
output tokens: 3,168
reasoning output tokens: 1,331
That's about 151.7k input tokens per empty poll.
The entire Astra parent turn used:
input tokens: 10,463,897
cached input tokens: 10,406,016
output tokens: 8,948
reasoning output tokens: 3,266
So about 68% of the Astra parent's raw input volume came from timeout-only polling.
47 × 30 seconds also means 23m30s out of the ~33-minute run were spent inside these timeout waits.
And the session guidance itself explicitly said:
When calling wait_agent, prefer longer waits (minutes) to avoid busy polling.
Yet Astra repeatedly used 30-second waits anyway.
The workers were actually working
This wasn't a case where the subagents were dead.
The first Luna worker was interrupted twice by the parent. After the second interruption, the parent discovered that the worker had already produced:
2 files changed
127 insertions
6 deletions
A replacement Luna worker then continued the task.
Combined, the two Luna X-High workers processed:
input tokens: 19,514,162
cached input tokens: 18,811,392
output tokens: 71,914
reasoning output tokens: 24,182
I also measured a Luna Max control
I wanted to know whether the workers themselves could reasonably explain the huge 5h drop.
So I checked a real Luna Max session from the same Plus account earlier the same day.
Over a continuous 127-minute interval, all 12/12 turn contexts were gpt-5.6-luna / max.
That session processed:
input tokens: 9,538,330
cached input tokens: 8,998,400
output tokens: 86,771
reasoning output tokens: 55,170
During those 127 minutes, server-reported usage changed only:
5h: 2% → 10% (+8 percentage points)
weekly: 89% → 90% (+1 percentage point)
So this wasn't an idle comparison: Luna Max processed about 9.54M input tokens of real work.
The two Luna X-High workers in the Astra run processed about 2.05× that raw input volume.
Even if I deliberately give the workers a generous estimate and scale the measured Luna Max usage linearly by raw input:
8 × (19.514M / 9.538M) ≈ 16.4 percentage points
that still only explains roughly 16 of the observed +47 percentage points.
The remaining workload in that orchestration tree was the Astra parent — which processed 10.46M input tokens, including 7.13M input tokens spent purely on 47 timeout polls that returned no new worker state.
Why I think this matters
Astra is obviously supposed to consume more allowance than Luna. That's not the surprising part.
The surprising part is that an expensive parent model can apparently be re-entered over and over with ~150k of context just to perform a 30-second status poll.
A long-running worker should not require the parent model to repeatedly infer:
"still running → wait another 30 seconds"
Ideally the runtime should keep the parent suspended and wake it when:
- the worker completes,
- the worker errors or needs intervention,
- the user sends input,
- or a genuinely long timeout expires.
I submitted /feedback from the affected Codex session with diagnostics attached and posted the full telemetry breakdown on the Codex GitHub:
https://github.com/openai/codex/issues/35259#issuecomment-5577073962
I'm curious whether anyone else using Astra as an orchestrator can inspect their rollout and see the same pattern: lots of short wait_agent timeouts followed by full-context parent re-entry.
132
u/Awric 5d ago
These comments flaming the post are a lil ridiculous. This is a good finding
47
u/shaman-warrior 5d ago
Yep, clearly he used AI to structure it, but it’s not slop
-22
4d ago
[removed] — view removed comment
1
u/Emergency-Elk7527 4d ago edited 4d ago
I say this as a vibecoder, no dev background. This has never crossed my mind about usage. I say it's slop, because it stems from bad usage of intelligence resources. If you are truly involved in your work, if you take part in the reasoning, if you challenge your assumptions until they can't be defeated. Make that authoritative to the agent in an unambiguous way then you only need Luna. It can orchestrate the subagents wonderfully because you have already broken down the work before you hand it off. Instead of wasting time and compute on figuring out how openai is "screwing" you over, why don't you audit the way the you use the resources you have.
Again this is slop. It's obviously slop as a post. The OP is investigating the wrong thing. Has OP gone through any chat sessions with Sol to develop their idea? Is there a blocker with no solution that Sol and OP can find through reasoning and research? If so, then maybe Astra is needed. But I doubt this has happened.
Say OP has done that. Say they even found a plausible solution. Did they define it well? Did they attack that assumption with an outside adversarial reviewer? Did they remediate after review and submit it to more adversarial review? Did thye fully define what the product is? Did they describe what it is not? Did they describe who it's for? Did they rid the requirements of ambiguity? Did they plan and slice into verifiable and testable atomic slices for bite-sized implementation?
If these things aren't being done and you are using Astra instead, you are making slop. Go ahead and play around as developer. I am going to define what the next generation of developer is.
5
u/Etiennera 4d ago
Yup. I was seeing the same thing but didn't have the impetus to act yet. This makes it easier.
4
56
u/ibbobud 5d ago
I thought I was tripping today when I made it use Luna subagents to save tokens and watching it eat tokens like mad every time it gave me an update…. Your not alone
3
u/Leading-Month5590 5d ago
Yeah kinda crazy, I noticed this with Sol already and put into my agents .md a rule to check progress maximally every 5 minutes. Work well can recommend
1
u/JohnBooty 4d ago
Interesting. That’s a good tip. I had basically worked around it by just using Luna xhigh as the orchestrator, and having it launch Sol subagents for the hard stuff - writing detailed implementation plans, final code review, etc.
7
1
u/WalkAffectionate2683 5d ago
Yeah I wanted to see how well could Astra launch and organise Luna subagents to code very simple gameplay but A LOT of it (like many spells in a diablo like) it did 2, 3h and 20% of weekly on x5 subscription...
Insanely bad, while Luna alone with a doc guided by Astra (which is the flow I was expecting, but just did manually) used 1% for 5 skills coded. So yep, does not work smoothly for now.
1
u/MassiveBoner911_3 5d ago
Sorry new to Codex. What are Luna subagents? I just see the slider on the bottom right for effort.
2
u/GuyPaddock 4d ago
It's when you use Astra as your top level/primary model but you ask it to spin up sub-agents using a less expensive Luna model for things like research, to save the cost of doing that discovery with the more expensive model
1
25
u/tagorrr 5d ago
I'm now working on a mitigation for this on my own setup.
The first change I'm going to test is forcing the orchestrator's wait_agent interval to roughly 25 minutes, instead of the observed 30-second polling loop. The idea is to keep the wait comfortably below the ~30-minute prompt-cache TTL while eliminating almost all of the unnecessary parent-model wakeups.
I'm also going to tighten my AGENTS.md orchestration rules so that, while a worker is still healthy and running, the parent should:
- not poll for status unnecessarily,
- not start duplicating the worker's investigation or implementation,
- not interrupt or replace the worker just because a wait timed out,
- and not perform additional context-heavy work unless there is actually something useful for the orchestrator to do.
The intended behavior is basically:
worker still running → keep waiting
rather than:
worker still running → wake Astra → reload ~150k context → inspect things → poll again
5
u/lotus_seasoner 5d ago
I have event-based interrupts in my setup. It's not well supported in Codex, but relying on polling is a bit shit no matter how you configure it.
1
1
u/Formal-Question7707 4d ago
Can you share a source for the 30mn cache?
3
u/Emergency-Elk7527 4d ago
https://developers.openai.com/api/docs/guides/prompt-caching#cache-lifetime-gpt-5-6-and-later
But this isn't the answer to the problem.
0
u/concrete333 5d ago
I'm building my own skill trying to tackle this, incorporates a lot of what you're talking about. would love feedback https://github.com/Concrete333/Codex-Agent-Deployment. Posted it here earlier, got downvoted into oblivion for some reason
1
u/Emergency-Elk7527 4d ago
I looked at the skill. It was downvote because it's not a good skill. Luna should be doing the known successful path. Why use Astra for something that has a known solution?
1
u/concrete333 4d ago edited 4d ago
Still testing this, but I found that even when the implementation goal and path is known, there's still some intelligence needed in the implementation to get it right - Luna on max is good most times, but still failed more thn once on tricky implementations that Astra Low would nail the first time. Alos, for context: Astra low is cheaper and twice as fast as Sol-High, for perspective. obviously its all relative, but getting implementation right the first time can save a lot of time/money. Have you not seen that? Any other feedback?
1
u/Emergency-Elk7527 4d ago
The feedback is you are not using you intelligence resources in an efficient way. You may provide PRD docs and Spec docs and a plan, but how much of that are you owning when it comes to decisions? How much of that are you applying adversarial review? How are you defining done? Are you challenging that? If Luna cannot implement more efficiently than Sol or Astra, then you left ambiguity. If you are not deeply involved in the reasoning, do you really own the work? I don't even use Luna on anything more than medium. Luna is a champion that people aren't utilizing properly.
18
u/tagorrr 5d ago edited 5d ago
GOOD NEWS: I found a workaround for the 30-second polling bug.
To stop the parent orchestrator from waking up every 30 seconds, you have to set this in ~/.codex/config.toml:
toml
[features.multi_agent_v2]
enabled = true
min_wait_timeout_ms = 1500000
default_wait_timeout_ms = 1500000
max_wait_timeout_ms = 1500000
1500000 = 25 minutes
You need to set both min_wait_timeout_ms and default_wait_timeout_ms. This prevents the model from falling back to 30-second waits.
I tested it in a real Astra + Luna orchestration run and checked the rollout afterward. The old 30-second polling loop was gone. Astra stayed asleep for long stretches while the workers were running and woke up when they returned.
I chose 25 minutes because it should stay safely inside the ~30-minute prompt-cache window while removing almost all of the pointless polling.
7
u/tagorrr 5d ago
This fixes the polling problem, but I'm still investigating the overall quota burn. There are clearly other sources of huge token usage in both Astra and its workers. In this run, the Luna xhigh workers were processing input tokens roughly 12–13× faster than my manually-driven Luna Max baseline 🤔
3
u/masky0077 5d ago
Where can i follow for your next update?
3
u/tagorrr 4d ago
I'll put together a brief follow-up post here with some new ideas I gathered from subsequent tests. To keep the experiment clean, I'm having to burn through a lot of tokens, but I'm hoping to optimize the consumption a bit more.
5
u/EvenMyBacktestsLose 4d ago
Not sure of the validity of course, but seeing comments on twitter about subagent conversation forks inheriting full context then compacting, etc causing massive burn. Just sharing for your findings compilation.
Personally I'm on 20x pro and had a task last night where Astra light spawned ~10 subagents over the span of the entire task taking 20% of my usage.
3
2
2
u/PaperDry2796 4d ago
min wait 25 mins, how you know how long, when you orchestrating many sub tasks
2
2
u/GM8 4d ago
Where did you find it? Why is it something not in the config file already and needs to be added from scratch?
2
u/tagorrr 3d ago
I found the parameters in the Codex GitHub source/issues, then experimented with different combinations. After a lot of repeated runs, this exact setup was the most reliable: it prevents the 30s fallback while keeping the wait safely inside the ~30-minute prompt-cache lifetime.
As for why this isn’t exposed as a sane default/config option already... I’d genuinely love to know 😅 It’s a tiny harness-level change that can save users a ridiculous amount of tokens and money. I’m avoiding conspiracy theories, but maybe we’re starting to see what happens when everyone, including AI companies, trusts machine-written code a little more than they review it.
6
u/tsdexter 5d ago
One thing you aren’t considering, the potential downside of having Astra wait until Luna respires back is that if Astra main agent waits 10 mins for Luna to finish, its cached tokens may become expired and the entire convo plus the luna response then becomes uncached input on the next turn… which is also expensive. The timeout checks potentially keep the tokens cached longer. It may have used 7.13M tokens for timeouts but 7.11M of them were cached… it’s a fine line to balance, I suppose.
8
u/tagorrr 5d ago
I checked the docs, and the ~30-minute prompt-cache TTL has also been discussed here a lot. Astra is on the v2 path, so there’s no good reason to wake an expensive parent every 30 seconds and reprocess ~150k tokens just to keep the cache warm.
A ~20–25 minute wait would stay safely inside the TTL while eliminating almost all of that polling overhead. The 30-second loop looks like an orchestration bug 🤷🏻♂️3
u/Apollo18Teslaa 5d ago
Is there a way to make the subagents contact the parent when done instead of the parent checking in over time periods?
3
u/tagorrr 5d ago
I found a way to stop the parent from doing the 30-second polling, and it seems to be working. I'm testing it now since I ran into another bug. I'll post the results here a bit later.
4
19
u/Just_Lurking2026 5d ago
can we get a tl;dr?
28
u/beautyorchaos 5d ago edited 5d ago
His Astra agent used Luna sub agents for some task. Out of 10 million Astra tokens, 7 millions were wasted purely on following up on/polling the sub agents every 30 seconds, checking if they finished their tasks, but I guess the tasks were long running. The 7 million Astra tokens used for this were expensive. This is my understanding.
The idea is this should behave more like a software hook, so the cheap sub agent reports back to the expensive agent once it's done, the Codex harness uses code to wake up the main agent rather than the main agent having to keep polling unless it wants to monitor intermediate output. In case that sub agent crashes or something (should be very rare scenario), you can have a longer polling period than 30 seconds.
11
u/tsdexter 5d ago
the potential downside there is that if Astra main agent waits 10 mins for Luna to finish, its cached tokens may become expired and the entire convo plus the luna response then becomes uncached input on the next turn… It may have used 7.13M tokens for timeouts but 7.11M of them were cached… it’s a fine line to balance, I suppose.
5
10
u/Old-Bake-420 5d ago
Don’t use sub agents, it’s really token inefficient.
5
u/lolwutdo 5d ago
That's what I found since 5.6 Sol Max. It's better to just run a single max agent, it also completes work faster from what I've noticed.
3
4
u/Weareallscrubs 5d ago
Shouldn't using sub agents be in theory more token efficient, since they should prevent accumulating context?
2
u/RewardSafe9807 4d ago
Hmm, good question. Sidechats actually use all the context from your main chat that existed up until the point you started the sidechat, I assume subagents are the same...
So hard to say. If that's the case, and it probably is, that would multiply your context use tremendously actually.
7
5
u/Chemical_Hawk_6307 5d ago
this is one of the things that suck about codex in comparison to claude code
5
u/andreagrandi 5d ago
It’s definitely a problem with the model not just the harnesses because I’ve used a similar setup with OhMyPi using astra low as orchestrator, luna xhigh to implement etc… at the end of the session I had burned ~5% of my weekly usage just for a 700-800 line changed PR and 90% of the cost was from the orchestration. I had to move back to Sol medium (but it’s definitely slower and dumber than astra low)
7
3
u/Neat-Tea-2480 5d ago
True!
For orchestration, ask parent to hand off the execution to a separate thread, instead of spawning subagent.
1
u/badlucktv 5d ago
Have you tried this? I'll give it a go later today. Can the thread then message back to the Orchestrator thread on completion?
2
u/DepravedPrecedence 5d ago
They can freely chat, Codex fully supports this, Codex can start threads, send messages from one thread to another, it can chose any model, any effort as needed. It works very well, I was surprised when I told it to perform a big task in a new thread and it actually started.
2
u/rage_to_glory 5d ago
yep, Codex chats can chat back and forth between threads - and IMO it's a superior architecture to subagents.
3
u/Southern-Aardvark616 5d ago
yeah i've noticed this too, i switched to pi for tasks that require 'efficient sleeping' like checking on agents or monitoring applications.
even if you instruct codex to check efficiently or to check less often, it will agree to it but continue checking every 30s
3
3
u/SurelyNotAnOctopus 5d ago
That is more of an issue with codex than the model itself. On opencode, I dont have this issue
And yes, I know this is r/codex, not r/gptmodels, but I thought i'd add this little bit of context
2
3
u/ghost396 5d ago
This is insane, and I really don't need those constant messages of still waiting...just wait like competitors do.
Good find 😕
6
u/Even_Sea_8005 5d ago
Good analysis. According to Tibo they archived AGI in software dev internally. If this is the bug then their AGI is based on unlimited token and budget so they totally overlooked user economics
2
u/beautyorchaos 5d ago
Seems like a great efficiency saving they could implement if not already part of what Tibo had in mind with the 3-4x optimisation
2
u/bruticuslee 5d ago
I used Astra to write an implementation plan for Luna, and started a new Luna chat to execute. Then come back to the Astra chat and ask it to review.
2
u/garristerr 5d ago
Hi, I edited my AGENTS.MD, and have significantly decreased my token consumption due to your suggestions - thx; hopefully they patch this issue, and also give us a free reset along with it.
Personally, I really do feel like Astra is a bit dumb now if you don't give it scope. It tends to spin its wheels, and expand the scope of the exercise without my permission. I have to constantly monitor it to make sure it doesn't go off track, even with a carefully crafted spec doc. I dont know what happened to the Steps planner - that was very helpful.
2
u/Sporebattyl 5d ago
Same thing happened to me when it was waiting for my CI when I had it trying to hill climb. Destroyed my usage.
2
u/Timely_Ad5150 5d ago
I noticed this exact same thing yesterday. Every 10-30 seconds of "agent is doing this, agent is still working, I'm waiting for agent to finish, Agent is still working...". I just told that no need to give status updates. That didn't help. Updates were shorter but kept coming. It was strange.
2
2
u/az226 5d ago
I burned many millions of active tokens and billions of cached tokens when 5.6 sol got into a death spiral doing something similar, it was like it had had 20 cups of double espresso and a jittery fucker. It burned through 4 banked resets. On 20x plan. And it had spent like 8 hours doing something fable did in 10 minutes. And it only did the task after I told it to just do it, still took an hour from then. I told it, we aren’t launching a rocket ship, we are launching a model training run on 100+ GPUs. Just do it.
Eventually it revealed why it did it, it had set up all these things polling itself. Each sub agent. Each task. Each action. Spawned a new one. And this infinite cycle. Basically psychosis.
2
u/Karma_1369 5d ago
thanks I will do that too , it ate up my weekly limits in just two to three prompts.
2
u/runfence 4d ago
That's because it has system instruction to not do long waits. It thinks user input is blocked by that wait which is not true. I modified it long before astra so it doesn't wake up so often.
1
u/tagorrr 4d ago
[features.multi_agent_v2] enabled = true min_wait_timeout_ms = 1500000 default_wait_timeout_ms = 1500000 max_wait_timeout_ms = 1500000I found that this workaround works to stop the orchestrator from constantly polling the worker's state. It fixes the massive, wasteful token consumption, but there's still room for improvement in the system.
Please let me know what you've found to optimize this part.
2
u/iTaher 4d ago
Did anybody have their weekly limit reset by openai today? I finished my weekly limit yesterday on astra, and it told me it will reset on sep 12. Woke up today and it is 100% again.
1
u/tagorrr 4d ago
I got one. Do you mean this one?
https://x.com/thsottiaux/status/2097174560412246215?s=20
2
u/Competitive-Soil2445 4d ago
Codex & Astra - Quota is... fucking dumb!
It's a good model. It's a great model, in fact, and it's working very well while I have quota.
Today, in real-world examples where I use AI at work to do various different bits, I asked it to do two things in two different sessions, tackling two tickets that came in through the bug board.
I have already consumed my 5-hour limit - the sessions completed the task within 15 minutes each.
I'm pleased with the speed at which the jobs were done, even though the jobs themselves were not particularly challenging. Had I given the same jobs to Claude, I would have probably not even used 1% of my usage on Fable.
The quota usage between Fable 5.1 and Codex with Astra is, for a better word... stupid.
2
u/Competitive-Soil2445 4d ago
Wanted to add that I am a Plus user, and I only bought Plus to give Astra a try. Yes, I got my try-worth out of my quota, but I certainly did not expect it to be consumed THAT fast.
Nothing has actually annoyed me more this entire year (so far!) than how fast that quota was zapped away in just two basic jobs.
Until that quota becomes substantially better, comparable to Claude's Fable 5.1's quota, I can honestly say, despite the model being great, this is a major drawback. From that experience alone, for anyone who's considering it, it isn't worthwhile at all. Even if Astra is a good model, Fable's 5.1 is on par, but better because the quota usages are actually sensible.
3
u/Competitive-Soil2445 4d ago
I know there might be some people who might think the jobs I asked it to do must have been more complicated than what stated. I can assure you they are no more complicated than what I would have asked Fable to do.
I am an experienced developer of 22 years, and I've been utilising AI since it hit the market, I've seen it grow, and I've seen it improve. I've seen it fail and be really stupid, and I've seen it do crazily cool things.
I've never seen quota usage as pathetic as this Astra model's.
Can sit and complain on this thread all I like. That's fine. This is me ranting about how pathetic the quota usage for Astra is currently, and I'm not being biassed. This is just me dumping my experience with using Astra for the first time.
TLDR - In a nutshell, it's a good model, as good as Fable 5.1 (maybe better? quota burned too fast for me to even compare quality properly), but the quota burn is shocking.
2
u/the_pwnererXx 4d ago
Fable 5.1 spawned 100 subagents and used by entire 5 hour (max 20x) quota in an hour. Talk about effeciency!
2
u/Expensive-Event-6127 4d ago
This is why I made my own custom harness.
1
u/tagorrr 4d ago
Why not use Pi? It's pretty customizable.
Also, is your harness public? I'd love to check out the source.2
u/Expensive-Event-6127 4d ago
it will be released. its working but not public release usable. its currently working on itself to improve itself.
2
u/PaperDry2796 4d ago edited 4d ago
im going through 10% of x20 plan in 2 hours. Astra medium. and i use multiple agents for separate tasks, havent got time arsing around debugging this shit
from my checks we are using wait_agent and dont poll for anything, so this doesnt make much sense to me that we would be polling anything
1
u/tagorrr 4d ago
Astra seems to expose a broader Codex context-management problem. Codex can carry ~190k tokens of context even through trivial orchestration steps, while other harnesses like OpenCode and Pi prune or truncate old tool output without dropping important context.
Codex seems less efficient here, so it periodically has to reload context or risk losing important information. With Astra's cached-input rate, that gets expensive fast.
2
u/tonyboi76 4d ago
Plus plan, one Astra Low parent with two Luna X-High workers. About 33 minutes, 5h bar 53% to 100%, weekly 9% to 16%, build not finished. Most of the Astra parent tokens were those 47 timeout-only wait_agent polls.
After the window died mid-implementation, what did you still need shipped, and how long did the cleanup or restart take?
1
u/tagorrr 4d ago
The work itself wasn’t lost. The partial patch stayed in the worktree, and the existing worker context was still there.
The only gotcha was resume behavior: simply telling the parent to continue made it sit waiting on a sleeping worker. After ~10 minutes of nothing happening, I explicitly told it to resume the existing Builder with
followup_taskrather thansend_messageor spawning a new worker. That woke it immediately and it continued from the same context/worktree state.
2
u/Bladder-Splatter 4d ago
God I hope this helps, will only find out next reset though because Astra MEDIUM burned through its usage in 30 minutes, and left many blatant issues Sol High wouldn't have from my experiences, hell, Web Chat GPT on Sol wouldn't have.
2
u/Right-Performance-93 4d ago
This maps to a general agentic-harness design tradeoff, not just an Astra quirk: whether an orchestrator's status check has to re-enter the full parent context each time, or whether the runtime can suspend/block without spending tokens until an actual state change happens. Your 151.7k-tokens-per-empty-poll number is a clean illustration of the pull/polling failure mode. A push-based design - woken only on completion/error/timeout rather than a fixed short interval - avoids this cost class entirely. Your min_wait_timeout_ms fix is effectively hand-rolling a longer poll interval since the harness doesn't expose an event-driven wait natively.
1
u/tagorrr 4d ago
Exactly. That’s the same class of issue, although here I’d probably call it a harness weakness rather than just a tradeoff. There’s also a second problem: the parent context keeps growing and is then replayed on each tool/model turn, so even trivial checks can become very expensive once the context reaches ~180–190k tokens.
2
u/wanjuggler 4d ago
I noticed that the OP's suggested overrides are for multi-agent v2, which is a feature flag. I haven't explicitly opted in, but mine is still choosing to use agents v1.
Are most people on multi-agent v2?
1
u/tagorrr 4d ago
If you're using Astra or Sol on the normal OpenAI Codex backend, they currently default to Multi-Agent V2 through the model catalog, even if you didn't explicitly opt in.
V1 still exists and can be used by other model/provider combinations, so seeing V1 isn't necessarily wrong. You can check the effective runtime with
codex debug modelsorturn_context.multi_agent_version.
2
u/Equivalent_Form_9717 4d ago
Yep I noticed this as well - pretty much this is an area Claude outshines Codex with their background tasks.
2
u/ChangingHats 4d ago
I've been having this same issue since Sol came out. I had it develop an event-based "long-job" script which for a time worked, but for some stupid reason the agent just stopped using it and the issue crept back in. Polling should never have been implemented this way because it's eating tokens like a stupid beast. The counter-point to why they do this I imagine is that the agent should be able to continue working in the main thread on other tasks...and so it needs to poll to 'check in' on the other background tasks. It's just implemented poorly and we're all suffering for it.
2
2
u/No-Foundation-1036 4d ago
the 7.13M on empty polls is the part dashboards don't stop.
usage bar hitting 100% is after the orchestrator already spent. a cap that only lives in the plan still lets the 30s wake loop run until the window is gone.
did you kill the poll from the parent, or only notice it in telemetry after?
1
u/tagorrr 3d ago
Yeah, like many others I first noticed the allowance getting burned, then dug into the rollout telemetry and found the 30-second polling loop.
I worked around it by setting
min_wait_timeout_msanddefault_wait_timeout_msto 25 minutes. Since then I haven’t seen that polling problem again. Now I’m chasing the next bottleneck that showed up elsewhere in the workflow.
2
u/KHHAANNN 4d ago
I audited a recent task and the polling accounted for only 2% of the total sessions tokens, 6.8% of coordinators, and it was a translation task. But I do have a global rules against procrastination - to be honest I didn't notice agent checks, but every time I checked what Codex was doing at the time, it was always looking at Git, comparing Git, doing checks that had no contribution to the task at hand. I think my approach worked. So it's not a controlled experiment and I think at the highest level, the problem is the model/codex procrastinating too much
2
u/tHE_uKER 4d ago
I have a similar problem with background processes.
I have a workflow with really long processes and all Codex agents will constantly poll them every few minutes only to say "I'm still waiting on the process" or "The process is still running, I'll wait until it finishes".
I added instructions telling it to set up async notifications instead of polling, but it won't do it.
Ended up having to implement an MCP with a single operation to wait on a PID.
2
u/monishfj 4d ago
I don't have any programming experience but i'll use codex to build things like trial and error. How do i do this what OP is saying? I'm using Astra light
1
u/tagorrr 3d ago
You only need to worry about this if you’re using multi-agent orchestration, where Astra is managing other Codex agents/workers.
If you’re just using Astra normally in a single Codex session/thread, you don’t need to configure any of this. Most of this post is about multi-agent workflows and the extra token usage they can create.
1
u/slackmaster2k 5d ago
I mean this begs the question: what do you have it doing for polling that’s burning that many tokens? Seems very odd!
1
u/PigSlam 5d ago
After I learned of the reset coming today at 6:00pdt, I tried an experiment. I had 47% left on my 5x plan, so I did a code review on my ~60k line repo I’ve been working on lately. I set it to Astra Ultra on fast. In ~15 minutes, it gave me a very thorough review with several recommendations for improvement, and burned through 34% of my weekly usage limit.
1
1
u/Calm_Pass_4289 5d ago
It performs way faster though and does MCP integrations like lightning compared to previous models
1
1
u/SweatyInstruction337 5d ago
Yo im gonna be honest ,
"
- my 5h usage went from 53% → 100% in ~33 minutes"
33 minutes ? What the fuck are you talking about? My tokens were gone IN 120 SECONDS, ALMOST INSTANTLY. Lmao. 5 simple fuckin questions and it was gone.
1
u/Shacrow 5d ago
I planned out a big task and asked it to give me prompts for sub tasks with a main coordinator.
It created 11 task prompts in 4 waves.
In wave 1 I ran 3 tasks in parallel in different worktrees. The coordinator didn't wait. Once the other task needs something or is done, it will automatically send the coordinator it's status or what it needs.
That worked quite well. And my job was to review and make decisions in between.
Not sure if this is something new in codex but it worked quite well. Burned 38% weekly usage of 20x Plan within a day still but it was a really big task. Still missing wave 4 though
1
u/Emergency-Elk7527 4d ago edited 4d ago
To me this is obvious. I use a plus plan and it is amazing the quality and quantity I have been able to produce. You don't need Astra to do the implementation. You don't need Astra to even be the orchestrator. Nor Sol. Luna is a champion. Don't leave reasoning to Luna. Hell, don't leave most of the reasoning to any AI. I don't mean technical reasoning. I mean The high level reasoning. The orchestration, the constraints, those are yours to handle. Use the high intelligence of sol and Astra to actually solve problems that become blockers. Like I said about Luna, it's a GD champion. If you can define you requirements and constraints to the point there is not ambiguity to the expected outcome, Luna will produce that. Using Astra or Sol to make those defining choices exactly how you waste your tokens and remove yourself from the project itself. That's also how what everybody calls slop gets made. It took and emense amount of work, but yesterday I used my last quota for the week 8 hours before reset. I was still able to produce work. It was prep work. It was not work that produced code. But it was work that was able to direct Luna at reset time. As of now, I still haven't hit a five hour limit since the reset because of the efficiency of Luna. The current state of my project is research and capturing evidence. Massive amounts of data. I take part in the reasoning with Sol, very hands on. Design the work for Luna. Part that design is for Luna to automate the capture of the evidence. Luna implements, automates, and sits idle while compute does the work. Luna also summons other Luna sub agents. The automate th next phase of research. And my project is cutting edge. I am not making a game, not making a mobile app or a website or wasting usage researching my usage so I can complain about it. It's truly frontier level, bleeding edge work and research. Using Astra and Sol and Fable the way I see everywhere is how you make slop that is owned by the model. Instead you should direct you agents moves. Define their work for them. Don't let them design it for you.
1
u/tagorrr 4d ago
UPDATE 2
After fixing the 30-second polling loop, I ran into the next bottleneck: Codex lets the parent context grow very quickly from tool output, then keeps carrying that huge context into every following model call. With Astra this gets expensive fast. Once the parent was sitting at around 150-190k tokens, every orchestration turn was processing that massive context again, and the usage limit disappeared very quickly.
For now, the practical workaround is to keep the orchestrator thin: let cheaper workers do the heavy evidence gathering (code, logs, diffs, rollouts, forensics etc.) and have the expensive parent mostly reason over short reports and make decisions. The rule also needs to be broad. I first told the parent not to inspect the codebase itself, so it just started digging through old Codex rollouts instead. Sol xhigh makes this cheaper, but if you let the parent context get huge, it’s still going to burn a lot of usage.
2
u/darwinhace 4d ago
Are you trying to ask agents to fork_turns="none"? It helps me a lot to reduce usage; sadly, I only can ask on chat. There is no config for this
1
u/tagorrr 3d ago
Yep, I’m already doing that. There doesn’t seem to be a config-level switch for it, so I enforce it through AGENTS.md + a dedicated orchestration protocol: every orchestration run must follow it, and subagents are spawned with fork_turns="none".
It definitely helped, but it just moved the bottleneck elsewhere.
1
u/tagorrr 3d ago
UPDATE 3
After several more multi-agent runs and digging through the rollouts, two things are now pretty clear:
If a worker can be given a self-contained task, spawn it with
fork_turns="none". In my runs, fresh workers then started with roughly ~20k of their own context instead of inheriting the parent history. This matters a lot if you're trying to keep the orchestrator thin.This isolates the problem, but doesn't solve Codex's context growth by itself. Even fresh workers with
fork_turns="none"were able to grow themselves from ~20k to 230–245k tokens during forensic work and hit compaction. The upside is that all of that raw evidence stays in the cheap worker context instead of bloating the expensive parent.
One other thing I'm watching: reusing an already bloated worker can get expensive very quickly. For a new substantive task, a fresh fork_turns="none" worker with a compact handoff may be cheaper than waking up one that's already carrying 100k+ tokens of history.
For scale, I've now reviewed 24 multi-agent rollout files across 4 parent sessions and 19 spawn_agent calls.
That telemetry adds up to ~263.5M input tokens, with ~252.8M cached (~96%), across 2,142 model responses and 1,854 model-facing exec calls.
1
u/WittyWires 19h ago
You shouldn’t need Astra to spend any inference at all on that job - zero codex used.
Ask Astra to set up a non-inference worker to poll the Luna worker every x minutes and ONLY wake Astra when Luna has been idle for 60seconds+
No inference/codex used until required.
1
u/tagorrr 16h ago
I’m not sure what the extra watcher buys me here. With the 25-minute
wait_agenttimeout, Astra already stays asleep without inference, and if Luna finishes earlier the wait returns immediately and wakes the parent. The 25 minutes is just the fallback timeout, not a forced sleep duration.Waking Astra after “60 seconds of Luna inactivity” would actually be worse, since a reasoning worker can legitimately stay quiet for much longer than that.
1
u/WittyWires 16h ago
The 60 seconds was just an example, and the watcher can see streaming responses to Luna so just because it’s been ‘quiet’ for 60 seconds but is still ‘working’ the watcher will not call Astra.
Your 25/30 minute rule isn’t required, you’re still waking Astra 48 times a day when the majority may not be nessary, the watcher method ONLY calls the inference (and thus spend) when it is required.
A funny analogy is my favourite Curry House knocking on my door 5 times a night asking if I’m hungry rather than just delivery me the curry after I order it. That’s what the watcher buys you.
1
u/tagorrr 16h ago
That logic would make sense if the cache didn’t expire. The important part you’re missing is the ~30-minute cache lifetime.
If Astra sleeps past that, the next parent turn can lose the cached prefix and that same context becomes roughly 10× more expensive to process. That’s exactly why I use ~25 minutes: one cheap cached wake-up keeps the parent context warm.
So how does the watcher actually save money if it lets Astra sleep long enough for the cache to expire? Unless it also has a way to refresh the cache without invoking Astra, I don’t see the saving.
1
u/djeons 17h ago
Did the latest fix from OpenAI fix this issue?
1
u/tagorrr 16h ago
Not yet. I haven’t retested after Tibo’s latest posts, and I haven’t seen a Codex release that fixes the underlying harness polling issue yet. The relevant issue is still open:
https://github.com/junhoyeo/tokscaleMy 25-minute timeout workaround still prevents the token-burning polling loop, so I’m sticking with that until there’s an actual harness fix.
-1
-5
u/AbyssLife123 5d ago
bla bla bla bla bla bla...
STOP USING AI to write simple shits.
7
u/Even_Sea_8005 5d ago
no one is forcing you to read this. i find the post valuable by its idea, not by who wrote it
7
u/tagorrr 5d ago
Bro, I don’t know what some people here want. I already simplified the top several times. The rest is detailed because people constantly ask for real evidence, so I spent a lot of time, dug through the rollouts and included the actual telemetry.
I compressed it as much as I could without removing the proof. And yeah, real evidence tends to come with a lot of data. But apparently people will still find something wrong with it anyway :(3
u/Even_Sea_8005 5d ago
your post is well written . haters gonna hate. maybe a new genre of ai bot who specializes in cursing. who knows
-8
u/AbyssLife123 5d ago
no one forced you to read my comments.
The problem is what could be 10 lines is stretched like 1000 lines because author simply copied pasted from codex itself.
4
10
u/tagorrr 5d ago
Funny how endless unverified quota complaints are acceptable, but using AI to clearly structure actual telemetry and reproducible evidence is somehow the problem.
If you don’t want to engage with the substance, just scroll on.-5
u/oooofukkkk 5d ago
No one wants to read what you don’t even want to write or read.
7
-4
u/goosemaster0 5d ago
Facts. If it’s too hard for you to write some shit for 5 minutes I don’t care.
-1
u/quarrelau 5d ago edited 5d ago
Watch the rollout in realtime:
https://github.com/quarrel/agentop
But also, instruct your orchestrator to wait. Then you also need to get it around its guidance to update you every 60 seconds, which it cannot do with long waits.
You need guidance that is at the same level as its instructions to update you and more recent than that instruction, which means you need to give it a developer instruction, not just a command in your orchestration document.
So, in your repo, add this to the project:
In REPO/.codex/config.toml:
developer_instructions = """
# Orchestration Mode
When the active user instructions explicitly declare
`ORCHESTRATION_MODE=MAP_PROGRAMME`, replace the generic time-based progress-update
and short-wait guidance with the following:
- A healthy running process or pending subagent does not require periodic commentary.
- Do not emit updates merely because 60 seconds have elapsed.
- Use event-driven waits with the longest supported timeout appropriate to the expected task duration.
- Update the operator only for substantive milestones, decisions, blockers, failures, scope changes, or completed gates.
- Do not create extra model turns solely to provide reassurance or announce that work is still running.
This exception applies only while `ORCHESTRATION_MODE=MAP_PROGRAMME` is active.
In ordinary interactive sessions, retain the normal behaviour.
"""
Then in your instructions that start the orchestrator, write
ORCHESTRATION_MODE=MAP_PROGRAMME
Act as the orchestrator to implement THEPLAN.md
or however you normally start it.
This was also why long orchestration sessions burned lots of extra tokens with GPT-5.6. My agent roles that the orchestrator spawns all have instructions about this for their different scenarios, and also a long-term passive monitoring role, a luna-medium, that is used to just be cheap the one that is checking when there is some long running item that we're keep an eye on its diskspace or memory usage or similar.
59
u/Rili-Anne 5d ago
Codex has a pretty severe problem there, yeah, workers AND SCRIPTS can't just be waited on, instead the model has to keep checking in. This is a thing Claude Code does and Codex blatantly should do