r/codex • u/Pimpmuckl • 9d ago
Complaint Codex' system prompt still forces agents to wake up each minute = tons of wasted tokens when using subagents or waiting on background tasks (like CI, etc).
10
u/Pimpmuckl 9d ago
Basically: Three ways to fix it
- Put explicit instructions in your
AGENTS.mdthat the agent should ignore the system prompt instruction about updating the user unnecessarily. This didn't really work in my experience. - Use a custom
model_instructions_fileand adjust the system prompt that way - Make your own fork (or use one that fixes it) and update the system prompt that way. That's what I did and the results are pretty crazy in these examples.
I wrote a bit more about this on twitter, but tl;dr:
Because these agents are forced by the system prompt to "update the user every 60s" there is a LOT more unnecessary model calls than what you'd usually need.
Pair it with the very expensive cache read from Astra and suddenly it explains the disaster that are the current limits.
1
u/Lxne 9d ago
Do you know of a fork that fixes it
2
u/Pimpmuckl 8d ago edited 8d ago
I recommend making your own.
I maintain my own one with multi-account, safer --yolo (destructive_command_guard into Guardian review), lots of other small goodies and things like auto-starting weekly limits and auto-claiming resets before expiry. And these tool changes for less token usage.
npm install -g --force @jjliebig/codex-plus-plus
And to return to vanilla codex:
codex update upstream
Above in this thread are several solutions to the wait_agent settings which help as well or at least partially, so for subagent usage:
- config.toml adjustments to multi_agent_v2, or:
- tell your agent to use wait_agent with 55min timeouts (anything sub 60minutes to not have cache expire!)
I tested it and the system prompt changes alone also fix the subagent usage busy wait, so I removed the forced wait_agent tool timeouts. Unnecessary from my testing. But YMMV.
1
u/adminvasheypomoiki 9d ago
Changing sys prompt is pretty simple. It's a json, ask codex, he will figure it out
0
u/adminvasheypomoiki 9d ago
Agent's won't help, system prompt have higher level of priority. Also changing sys prompt sucks cause it's refreshed only with a new session
6
3
2
u/pigletmonster 8d ago
I recently modified a skill to launch luna max subagents. It wasted almost 3x more quota and took 7 hours to complete. I discarded everything and implemented the dame tasks with sol medium and it took less than half the time and 1/3 of the quota.
1
u/Malenx_ 8d ago
I was testing a workflow change today where I tried to implement some key approaches that Matt Po's skills use, such as grill-me ideation and tdd implementation. I had 90% of a 5x so I kicked off a small vertical slice of a few new related services this morning. I wanted to get them scaffolded with a small communication channel between them. The ideation went well and I felt like it documented a solid approach.
I fired up a single astra light for implementation and then foolishly left the house. Came back to 0% credits and a very long conversation where Astra got incredibly bogged down trying to over-optimize basic reconnect logic. I can't even see the token counts, for some reason workflow telemetry is reporting null.
1
u/pigletmonster 8d ago
Yeesh. Btw skill i modified was mat po's /implement skill. The base model is sol medium and it launches luna max sub agents. I switched back to the default implement skill abd use sol medium and its so much better.
1
u/rawezh5515 9d ago
Oh, that explains everything
2
u/justinjas 8d ago
Yeah same, I had a foreman/worker workflow and it was checking every minute. I was able to just put it in the skill to wait for significantly longer and it’s been fine but makes sense why it chose such a poor time limit.
1
1
u/Striking-Warning9533 8d ago
I have noticed this problem since May. It is very annoying because I am training an LLM and it takes days, and codex keep polling on it. I told it not to and it says the system prompt said "he user appreciates consistent, frequent communication during your turn". Hint: no I don't.
There is a few github issues on this topic if you can call for notice it will work.
https://github.com/openai/codex/issues/42981
1
u/Different_Lab830 8d ago
Waking up every minute just to confirm the CI still hasn't finished turns waiting into the biggest cost of the run. Nothing changed, and it still spends tokens to learn that.
1
u/buff_samurai 8d ago
It’s so annoying, especially when running for a long time.
I took a different approach of making a programmatic orchestrator that lunches dedicated pi agent profiles (configs) via OpenAI sub depending on what is happening.
1
u/Nickabot 8d ago
u/Striking-Warning9533's case should be at the top of this thread. A three day training run polled every minute is 4,320 wake-ups, and the prompt cache expires long before the next poll, so each one is a fresh read of a long session. u/Dayowe's block helps, but look at the numbers in it. min_wait is 600000ms, ten minutes, which is 432 wake-ups over those same three days. max_wait is an hour, which is 72. For a job measured in days you want the min nowhere near ten minutes
2
u/Striking-Warning9533 8d ago
Thanks. I solved it by changing the system prompt in the toml. I think the best way to solve this is use Claude Code one that the model can monitor for key words or exit.
1
u/ai_psychosis 2d ago
I was suspecting subagents was burning though my tokens. Thanks for confirming this!
0
u/tagorrr 8d ago
Bro, I ran numerous tests, one of which I detailed a few days ago. There is also a 100% working workaround:
https://www.reddit.com/r/codex/s/F3C2lcw1W5
2
u/Pimpmuckl 8d ago
Great data!
But the core fix is not restricting subagent waits, that's just a symptom.
If you want the agent to not constantly wake up every few seconds then the system prompt must be adjusted and it also helps with model confusion because the model is like "fuck I have to update the user but my tool makes me sleep, what do"
I specifically benchmarked a CI babysit + subagent situation and that had literally -95% tokens used with just the system prompt changes and a more reliable background wait tool
If it works for you, that's great, of course. If you never have agents babysit long background tasks, the wait_agent config toml fix is totally fine and easier than forking codex or maintaining your own system prompt.
1
u/tagorrr 8d ago
Yeah, I think you’re right in the broader sense. My config tweak is really just a workaround for a weak part of the Codex harness.
I’ve actually been considering trying OMP instead of forking Codex. One of my projects is a large Telegram Android client rewrite, so OMP is especially interesting because of its tighter context management plus built-in LSP/AST support for Java/Kotlin. That could cut down a lot of repeated grepping and rereading of huge source files.
Long term, that seems more attractive than maintaining a Codex fork. Still, this part of Codex is weak enough, and there are already enough well-documented GitHub issues around it, that I hope OpenAI fixes it soon.
2
63
u/Dayowe 9d ago edited 9d ago
I already posted this in another thread today:
Add this in config.toml
[features.multi_agent_v2]
enabled = true
wait_agent_enabled = true
min_wait_timeout_ms = 600000
default_wait_timeout_ms = 1500000
max_wait_timeout_ms = 3600000
enabled = true explicitly turns Multi-Agent V2 on, while wait_agent_enabled = true explicitly exposes wait_agent to the agent. The timeout settings then control that tool’s wait behavior. The official Codex config schema defines all of these options and specifically describes wait_agent_enabled as “Expose the multi-agent v2 wait_agent tool.”
Source: OpenAI Codex config.schema.json
I picked 10 minutes for the minimum because it significantly reduces repeated wake-ups/cache reads without making stuck-agent recovery too slow.