Using subagents exponentially explodes "messages" usage

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #12488
• #12728
• #13167
• #12487

Powered by Codex Action

The only potential duplicate here is closed so false flag

Can you say a bit more about how you're using subagents? Are you issuing normal prompts, just like you would without enabling subagents, and relying on the model to invoke subagents as it sees fit, or are you specifically prompting the model to leverage subagents in a specific way? You mentioned "Turning off subagents destroys the entire agentic behavior of the application.", so I'm guessing that it's the latter.

If you make heavy use of subagents and keep six subagents and the primary agent busy, it follows that you will consume significantly more tokens in a given time period. One way to mitigate this is to use a smaller model or lower reasoning effort for subagents where possible. If you use the same model and reasoning effort for all subagents, you should see usage scale roughly linearly with the number of concurrent subagents. Does that match what you're seeing?

My prompts are fairly minimal (example Implement PLAN.md from end to end in CWD)
My Agents and Skills however are sometimes forcing to use certain paths (agent/skill) and, ask to do delegation to agents when an agent is available.
There is a Strict Delegation and Skill Activation section in the global AGENTS.md file, which tells it that in some cases certain agents are a MUST (because I want it to use them).

It is very important however to understand that all this was in place already last week, where PLUS got me through a full week.

As for Turning off subagents destroys the entire agentic behavior of the application. - when agents are explicitly turned off in the config.toml then codex simply refuses to use agents, with the statement that - Agents invoked: none (subagent execution interface not available in this runtime). It DOES invoke skills (where I have some) but it seems it does not want anymore to use Agents (also has been confirmed as a consequence of disabling agents by another power user in Discord)

---

The main problem here is not the number of subagents run - I am running these since now at least 8 days.
Several other users too.
The main issue is that _all of a sudden_, we consume 20% of messages allowance on a PRO plan within 50 minutes.
If the problem where number of agents, or complexity or enforcement of said agents, then this would be a issue since the start - but it isn't.

If you check in discord, there is a user who built his own agent spawning logic and he asserts that using his own method, he consumes roughly 2% hourly, whereas with codex's inbuilt method, it ramps to 20%

Of course I understand that more agents > more consumption. However, considering that tasks are not really faster the more agents we have, and the consumption of "messages" ramping up insanely (a PRO account 20% in 50 minutes is really making me reconsider the tool), I dont think this is "normal" or "expected"

Further, as mentioned I am not the only one seeing this problem as of recent.

In all frankness - if a 200 USD plan cannot bring me easily without fear through a week of 8hrs-per-day workload, it is not something I can continue.
And considering that I made it _easily_ through the better part of a week using PLUS, just a few days ago, I really can't help but suspecting there is something wrong with the counter.

Now, I would be saying "this is just me", if it where just me.
However, if you scan Reddit and the codex discussions discord threads, I definitely am not alone with this experience.

I think these two aspects, along with the fact that nothing much changed in my way of using codex, should warrant some deeper inspection.

In all frankness - if a 200 USD plan cannot bring me easily without fear through a week of 8hrs-per-day workload, it is not something I can continue.坦白说——如果一个200美元的计划不能让我轻松度过一周每天8小时的工作量，那我就无法继续下去。 And considering that I made it _easily_ through the better part of a week using PLUS, just a few days ago, I really can't help but suspecting there is something wrong with the counter.而且考虑到几天前我用 _PLUS 轻松_撑过了将近一周，我真的忍不住怀疑计数器出了问题。 Now, I would be saying "this is just me", if it where just me.如果只是我一个人，我会说“这只是我”。 However, if you scan Reddit and the codex discussions discord threads, I definitely am not alone with this experience.不过，如果你浏览 Reddit 和 Codex 讨论 Discord 的帖子，我绝对不是唯一有这种经历的人。 I think these two aspects, along with the fact that nothing much changed in my way of using codex, should warrant some deeper inspection.我认为这两个方面，加上我使用法典的方式没有太大变化，应该值得更深入地检查。

I’m experiencing the same issue and wanted to add another data point.

Previously, my Plus plan usage could comfortably last an entire week under my normal workflow. Just yesterday, recently I only performed 3 relatively small tasks , and it already consumed about 30% of my weekly quota. Under similar usage patterns before, this would typically account for around 10% or less.

The change seemed to occur right after I updated Codex to the latest version (the version where the language selection no longer allows choosing English explicitly). At first, I suspected this might be a UI or display bug in the new Codex version. However, after checking the usage data on the web interface, the quota consumption was identical there, so it does not appear to be a client-side display issue.

Because of this, I’ve temporarily stopped using Codex for regular work. At the current consumption rate, what used to last a week could now be exhausted within just a few hours.

Additionally, I noticed another change after the update: execution time has become noticeably longer — roughly about 2× compared to before. In the IDE, after clicking “Send,” it sometimes shows “Retrying (1/5)… (2/5)… up to 5 times” before actually starting the task, whereas previously it would immediately show that it was working.

@zhenjiaWang - do you recall what version to what version?
I suspect 105 to 106

If you can confirm this too I’m going to try to revert versions and see if I can clean replicate this

I’m sure that the amounts of credits/messages chewed up here isn’t normal nor expected. And if it is, codex just got the by far most expensive ai out there for coding.

@zhenjiaWang - do you recall what version to what version? I suspect 105 to 106 If you can confirm this too I’m going to try to revert versions and see if I can clean replicate this I’m sure that the amounts of credits/messages chewed up here isn’t normal nor expected. And if it is, codex just got the by far most expensive ai out there for coding.

I’ve completed a clean rollback test and can confirm this does NOT appear to be a client-side issue.

Steps taken:

Downgraded Codex App from 26.228.1430(760)x to 26.224.1209(697) (kept the old DMG)

Fully uninstalled the current version

Deleted local cache (~/Library/Application Support/Codex and preferences)

Reinstalled the older version

Re-tested with a small task

Result:
The quota consumption behavior is identical.

For a task that:

Modified only 1 file (+36 / -2 lines)

Used ~60k context tokens (~23% of 258k window)

<img width="1710" height="548" alt="Image" src="https://github.com/user-attachments/assets/7e3657d9-4b98-4e07-be7c-c23bc1bf261c" />

No large refactor

High reasoning (not Extra High)

The 5h quota dropped from 100% to 90%.

<img width="520" height="202" alt="Image" src="https://github.com/user-attachments/assets/5b62a89e-fce3-4ee5-8bd1-6f32faf54959" />

Weekly quota dropped from 54% to 51%.

<img width="506" height="176" alt="Image" src="https://github.com/user-attachments/assets/70033ce0-4756-47a3-ad81-b5161f8b150a" />

This is clearly disproportionate to the task size.

At this point, it strongly suggests this is server-side metering behavior rather than client version related.

@smileBeda

@zhenjiaWang so your test proves that regardless of the version, the token burn is the same and therefore, an issue server-side? I was wondering if it was worth rolling down from codex cli 0.106.0 to 0.105.x

Here's my suspicion after all:
"they" counted the messages wrong. Realized it, fixed it, and now we see real counts (makes sense, because PLUS with 45/250 messages is a very narrow window, and so is PRO with a 250/1500 messages)

I think what we see now is actually what you get, and before we saw a wrong counter (indeed, sometimes I wondered how much I could do just with PLUS...)

It is unfortunate and very frustrating but I guess that is the harsh reality, and not one I can pay for :)

---

@etraut-openai - have you seen @zhenjiaWang's report? That matches exactly what I and many others see too.

So as I see it current counters are either wrong, or what I wrote just above is the case, in which case several users will not be able to proceed using the product due to an enormously high cost. In both cases not an ideal situation I think.

@smileBeda have you tried comparing results between versions 0.105 vs 0.106 ?

Apparently now they have some theories, see https://github.com/openai/codex/issues/13167#issuecomment-3991650002

I guess we can all follow that one ticket.

We've identified and fixed the issue. It was causing the 2X promotional increase in limits to not be applied for an estimated 9% of plus and pro users. We have now fixed this issue and are reseting the rate limit for all plus and pro users to compensate for the trouble. Thank you all for reporting.