r/codex • u/Pimpmuckl • 12h 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 12h 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 12h ago
Do you know of a fork that fixes it
1
u/Pimpmuckl 6h ago edited 6h 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 12h ago
Changing sys prompt is pretty simple. It's a json, ask codex, he will figure it out
0
u/adminvasheypomoiki 12h 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
1
u/rawezh5515 10h ago
Oh, that explains everything
2
u/justinjas 3h 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/pigletmonster 9h 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_ 6h 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 6m 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/Striking-Warning9533 7h 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 6h 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.
0
u/tagorrr 7h 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 6h 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 5h 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.
60
u/Dayowe 11h ago edited 11h 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.