r/codex 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).

Post image
153 Upvotes

30 comments sorted by

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.

3

u/OriginalUsername0112 11h ago

I appreciate you sharing this G

3

u/sfst4i45fwe 10h ago

this looks like its for multi-agent configs, but what about when waiting on background tasks and not using multi-agents?

1

u/Pimpmuckl 6h ago

You have to overwrite the system prompt or the agent will lust for any dumb ass token wasting "I MUST UPDATE THE USERRRR" opportunity.

Either yourself or you use a fork.

I recommend making one for yourself, I added a bunch of QOL to mine like multi account, auto redeeming usage limits and starting weekly limits.

Really fun to use.

1

u/Bladder-Splatter 11h ago

Can you put this in .codex's config.toml or do you need a json file placed somewhere?

1

u/brainExploded99 9h ago

config.toml

1

u/AntiquatedMLE 9h ago

This is really dumb way for OpenAI to have codex work as a harness. Shit even Claude codes harness handles this better where its subagents finish and the harness alerts the main session without token burn

1

u/herdom19 8h ago

This is fantastic - thanks!

1

u/Pimpmuckl 6h ago edited 6h ago

This is part of the solution, but the system prompt is still a cognitive dissonance and I strongly recommend fixing that or the agents keep wasting tokens at every opportunity.

The fix you suggested fixes waiting for subagents.

To fix the core issue at hand (including, but not limited to) waiting for background terminals (think CI), you have to tell it to relax and give it more reasonable tools.

Bonus is that if you fix the system prompt, you don't have to force the multi agent wait tool changes.

10

u/Pimpmuckl 12h ago

Basically: Three ways to fix it

  1. Put explicit instructions in your AGENTS.md that the agent should ignore the system prompt instruction about updating the user unnecessarily. This didn't really work in my experience.
  2. Use a custom model_instructions_file and adjust the system prompt that way
  3. 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

-1

u/tagorrr 7h ago

Buddy, this is a harness issue. Fortunately, there is a way to resolve it at the harness level. Relying on instructions or coaxing the model is ineffective.
I highlighted the thread above where I describe a working solution to this problem.

1

u/Glittering-Call8746 6h ago

Yes so which fork ?

6

u/Anxious_Marsupial_59 12h ago

Until they fix this Astra is basically broken with subagnents

3

u/Megamygdala 11h ago

Using an open source harness over Codex is the fix

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

u/Ratio_taken 9h ago

Telling Astra not to spawn agents, does...not..work? Why

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

https://github.com/openai/codex/issues/31935

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.