Pro weekly usage limit depletes unusually fast on 5.5, worsened by unstable context compaction

[GGBondBlueWhale]

What version of Codex is running?

Codex app version: 26.422.30944 (2080)

What subscription do you have?

Pro $200

What issue are you seeing?

The weekly usage limit for Pro users appears to be depleting much faster than expected when using Codex with 5.5.

Even without an especially heavy workload, I exhausted almost the entire weekly Pro usage allowance within about two days. Previously, when using 5.4, the weekly allowance was almost never depleted for me, even when my workload was significantly heavier. This makes me suspect that the 5.5 usage accounting / billing behavior may have a problem, or that the current usage cost is not reasonable for Pro users.

As a $200/month Pro subscriber, the weekly limit currently does not feel sufficient to support even two days of normal usage.

Additional related issue: context compaction wastes a large amount of usage

There is also a severe context compaction problem that makes the usage drain worse:

• Context compaction currently takes a very long time.
• It is unstable and sometimes fails.
• When compaction fails, the current session can effectively become unusable.
• I then have to start a new session and rerun or re-explain the same task.
• This wastes a large amount of tokens/usage on top of the already-fast depletion.

So the problem is not only the actual coding work consuming usage. Failed or slow context compaction and forced session restarts are also consuming a lot of the Pro weekly allowance.

Expected behavior

• Pro weekly usage should last a reasonable amount of time for normal Codex usage, especially on a $200/month plan.
• Usage accounting for 5.5 should be transparent and comparable to previous model behavior, or clearly documented if it is much more expensive.
• Failed context compaction should not make a whole session unusable or force users to waste large amounts of usage by restarting tasks.

Actual behavior

• My Pro weekly allowance was almost fully depleted in about two days under normal usage.
• This was very different from my previous 5.4 usage experience, where the weekly limit was almost never exhausted even under heavier work.
• Context compaction instability creates additional large usage waste.

Request

Please investigate whether 5.5 usage accounting / rate-limit consumption for Pro users is working as intended, and whether failed/slow context compaction is causing unnecessary usage loss. It would also help to provide more detailed usage breakdowns so Pro users can understand what is consuming the weekly allowance.

[github-actions]

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

• Pro plan 5-hour usage limit depleted in ~20 minutes under light Codex workload #19571
• Severe Performance Degradation and Excessive Token Consumption in Codex 5.5 (VS Code Extension) #19361
• Codex Desktop GPT-5.5 remote compaction fails and leaves thread unusable #19558
• [P0 / Blocker] Remote compact task fails 100% with "tools.defer_loading requires tools.tool_search" — GPT-5.5 unusable at context limit, no client-side workaround #19486
• GPT-5.5 Codex session hits unrecoverable compaction failure around ~220k tokens despite advertised 400k context #19386

Powered by Codex Action

[GGBondBlueWhale]

Thanks for pointing out the related issues. I’m aware there are similar reports, but I don’t think this should be dismissed without investigation.

This problem has been happening for quite a while. I’ve seen many other developers report similar issues around unusually fast usage depletion, excessive token consumption, and unstable context compaction, but it still has not been resolved. Today, my own Pro weekly limit was exhausted because of these issues, so I felt I had to explicitly raise it here.

The key point is that this is not just a duplicate report of rate limits or context compaction in isolation. For Pro users, unstable or failed context compaction directly causes wasted sessions, repeated work, and additional usage drain, which makes the weekly limit deplete much faster than expected.

[Gelurban]

I have the same exact issues.

[raederhans]

same issue found here, codex running like 3-4 times higher usage than the time I used 5.4

[carlos-naranjo-aa]

I found out because openai send twice today email recharging the account , when i saw the comsumption from gpt 5.5 in codex i went back to 5.4 . Iti a drag because the model appears to behave better than 5.4. I am using codex cli in wsl 0.125.0

[hilyfux]

I think this issue is really two separate costs that are getting blended together:

1. model usage cost for 5.5 itself, and
2. compaction tax caused by long sessions, failed compactions, and having to restate work after recovery.

If OpenAI only looks at aggregate weekly depletion, it is hard to tell which side is actually responsible. The most helpful product fix would be better attribution, not just a bigger quota.

Concretely, Codex should surface a small breakdown for each session:

• tokens spent on normal turns
• tokens spent on compaction / summarization
• whether compaction succeeded, partially failed, or forced a restart
• how much context had to be replayed after recovery

That would make the bug measurable instead of anecdotal.

On the mitigation side, I think the real win is to make compaction less lossy by persisting a durable external task/memory ledger outside the volatile session. Then when compaction goes sideways, the user is not paying again to reconstruct project facts, decisions, and next steps from scratch.

That is basically the pattern we ended up using in knowledge-graph: keep structured memory in git, keep it zero-dependency, and make it readable by both Claude Code and Codex so context recovery is not trapped inside one fragile session. Not saying that should be Codex's architecture, but it is a concrete proof that externalized memory can reduce the "failed compaction means re-explain everything" tax people are feeling here.

So +1 to the bug. I would explicitly investigate compaction as a separately metered failure domain, not just as a side effect of normal model usage.

[GGBondBlueWhale]

same issue found here, codex running like 3-4 times higher usage than the time I used 5.4

Yes, this is a very serious issue. I’m seeing the same pattern as well. The 5.5 usage increase does not feel like a normal 1.5–2x increase over 5.4; in my case it looks closer to an exaggerated 4–5x increase.
I’m not sure what is causing it — whether it is the model itself, context compaction/recovery, retries, or some usage accounting issue — but the current consumption rate feels unreasonable and hard to justify.

[GGBondBlueWhale]

I think this issue is really two separate costs that are getting blended together:

1. model usage cost for 5.5 itself, and
2. compaction tax caused by long sessions, failed compactions, and having to restate work after recovery.

If OpenAI only looks at aggregate weekly depletion, it is hard to tell which side is actually responsible. The most helpful product fix would be better attribution, not just a bigger quota.

Concretely, Codex should surface a small breakdown for each session:

• tokens spent on normal turns
• tokens spent on compaction / summarization
• whether compaction succeeded, partially failed, or forced a restart
• how much context had to be replayed after recovery

That would make the bug measurable instead of anecdotal.

On the mitigation side, I think the real win is to make compaction less lossy by persisting a durable external task/memory ledger outside the volatile session. Then when compaction goes sideways, the user is not paying again to reconstruct project facts, decisions, and next steps from scratch.

That is basically the pattern we ended up using in knowledge-graph: keep structured memory in git, keep it zero-dependency, and make it readable by both Claude Code and Codex so context recovery is not trapped inside one fragile session. Not saying that should be Codex's architecture, but it is a concrete proof that externalized memory can reduce the "failed compaction means re-explain everything" tax people are feeling here.

So +1 to the bug. I would explicitly investigate compaction as a separately metered failure domain, not just as a side effect of normal model usage.

I agree with this framing. From the user side, this really feels like a Codex-side issue, not just normal model usage or a generic quota/rate-limit complaint.

The problem is not only that 5.5 may consume more than 5.4. The bigger issue is that during real Codex sessions, the usage drain becomes unexpectedly high, especially when context compaction, recovery, or repeated reconstruction of the same project state is involved.

In those cases, users end up paying again for work that should not need to be repeated. That makes the problem feel much more serious than a simple “new model uses more tokens” explanation.

So I agree that this should be investigated as a Codex context-management and usage-accounting problem. Better attribution between normal turns, compaction, recovery, and replayed context would make it much easier to prove where the excessive usage is coming from.