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

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

• #19571
• #19361
• #19558
• #19486
• #19386

Powered by Codex Action

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.

I have the same exact issues.

<img width="464" height="77" alt="Image" src="https://github.com/user-attachments/assets/b038a8b2-0b87-417b-b834-47174ba8bcaf" />

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

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

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.

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.

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.

Although I'm Plus user, I also found the 5.5 model consumes the usage so quickly compared to 5.4 model.

same

I'm pretty sure this issue is related to the very aggressive write_stdin polling that 5.5 uses:
https://github.com/openai/codex/issues/13733#issuecomment-4322785225

I'm pretty sure this issue is related to the very aggressive write_stdin polling that 5.5 uses: #13733 (comment)

Hi, so the current solution is to only use the 5.4 model?
Edit:
I rolled back to the 5.4 model with effort high, but I still found the consumption to be much higher than before.
There might be some issues.
I only use 2 prompts and it takes 20% of my usage. wtf
As the agent takes more time to wait, the more tokens it consumes.

I dont know I am using Codex 5.4 Medium but still the Consumption is Very High

I have the same exact issues tooooo

Codex 5.5 low - 140k tokens run out of 5h usage. - that's crazy.

120k tokens in 5.5 medium reset the 5-hour limit. This is disgusting.

It might be a combination of 5.5 being more aggressive with requesting polling, but at same time maybe the harness changed in a manner where it is more wasteful with cached tokens. Clearly if you are running this without any concern for limits or cost then this is optimal from end user perspective (aka how you would run it inside OAI or in preview mode).

I’m seeing the same issue on the Plus plan. My weekly limit dropped to 25% (5h usage limit is 0%), after roughly 10 xhigh prompts. By contrast, I never ran into any limits on version 5.4.

Older models also showing the same fault pattern now (maybe just on more recent versions of Codex?)
Managed to use about 20% of my 5h usage in 5 minutes on 5.4-high with 2 straightforward prompts (Business plan), whereas I could use this model almost continuously for debugging previously.

I have the same exact issues. <img alt="Image" width="464" height="77" src="https://private-user-images.githubusercontent.com/1841569/583809866-b038a8b2-0b87-417b-b834-47174ba8bcaf.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Nzc1OTczOTIsIm5iZiI6MTc3NzU5NzA5MiwicGF0aCI6Ii8xODQxNTY5LzU4MzgwOTg2Ni1iMDM4YThiMi0wYjg3LTQxN2ItYjgzNC00NzE3NGJhOGJjYWYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI2MDUwMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNjA1MDFUMDA1ODEyWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NDMyYzMyMGM0MjJhNjQyYzg1ZGY0YzYxMzZlYTQ2NzVkMDQ3MjkyZDAxMzljYTIzMGU0OTY4ZmQ5YjBhMmJmZSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmcmVzcG9uc2UtY29udGVudC10eXBlPWltYWdlJTJGcG5nIn0.z27E494gfsXfUzQIgxiSusoH6RYq0Ra-sJxSO_T3T_8">

that one happened with me only, when my mobile network is disconnected - it happens twice a day nowadays, never happened before. (don't think that is codex related - but maybe reconnecting is failing at some point - to me it was always non-codex related)

To me, what i have realized, that the model some times goes wild and going to be nocieable idiotic (does not depend on peak time or task or skills) - the 5.4 on extra high level picked my intent better than 5.5 extra high (overcomplicates, not doing obvious things) - on 100$ promo (2x) i didn't expect that deplate the weekly limit (it would be enough for 8-9 days on 5.5), even on real heavy 12-14h/day. 5.5 medium definitely better than 5.4 medium. Naturally if promo off, i wouldn't survive the week, but 5h limit i would probably never hit.

I’m seeing the same issue on the Plus plan. My weekly limit dropped to 25% (5h usage limit is 0%), after roughly 10 xhigh prompts. By contrast, I never ran into any limits on version 5.4.

To me i changed to pro promo, even on 5.4 the limit drastically has been reduced - 2.5 times then before 9th of april. (plus is not useable at all 1h work on every 5 hours or so - i don't think that go/business plan is viable option at all by now) - i think the pro+ (200$) is little bit much, the pro (100$) without pro is not enough for a week, for 5.5 definitely not. (i didn't notice that much difference on 5.5 vs 5.4 on token usage by the way.)

To me the context window on pro is really small. 3-4 messages and compacting, i have realitvely large app by now. (140K angular UI code + 30K spring backend with docker) I feel that the model is simply to aggressive to make minimal changes, which many times results to dirty hacks, intsead of making the most obvious thing. (probably the 5.6 -> should improve that part, as the AI i feel is more capable, the other problem is that on repetitive task, where you have the pattern in the code on other places, not the best friend, really trying to reinvent the wheel several times for the same pattern, where developer really expect far more from an AI)

I am experiencing same type of issue. Have a $200 plan, I think never reached 50% of my weekly limit before, and now I have 5% left when the weekly resets in 3 days. I have not increased my work hours. and have not changed nothing in my behavior. I have seen this kind of problem happening with antropic and it was never fixed, this is why I have moved to codex........

Same issue here - contacted support with no luck. The difference I'm seeing is large amounts of unattributed "Other" usage, even on days when I do not use Codex at all. I've logged out of all accounts, am using MFA, etc. - so it's not that.

I am seeing the same issue on the Pro / ~$200 plan.

My Codex weekly limit is exhausted after roughly 2 days of normal project work. This is a major regression from my previous experience: I was using GPT-5.5 heavily shortly after launch and did not come close to the weekly limit, so this does not seem explainable by GPT-5.5 pricing alone.

Current behavior:

• Plan: Pro / ~$200
• Model: GPT-5.5
• Usage pattern: comparable to or lighter than before
• Result: weekly Codex limit exhausted after about 2 days
• Previous behavior: I previously used GPT-5.5 without approaching the weekly limit

This feels like a later usage-accounting / backend / compaction regression rather than normal expected GPT-5.5 consumption. Please investigate the usage accounting for affected Pro users and consider restoring impacted weekly allowance.

I am seeing the same issue on the Pro / ~$200 plan. My Codex weekly limit is exhausted after roughly 2 days of normal project work. This is a major regression from my previous experience: I was using GPT-5.5 heavily shortly after launch and did not come close to the weekly limit, so this does not seem explainable by GPT-5.5 pricing alone. Current behavior: Plan: Pro / ~$200 Model: GPT-5.5 Usage pattern: comparable to or lighter than before Result: weekly Codex limit exhausted after about 2 days * Previous behavior: I previously used GPT-5.5 without approaching the weekly limit This feels like a later usage-accounting / backend / compaction regression rather than normal expected GPT-5.5 consumption. Please investigate the usage accounting for affected Pro users and consider restoring impacted weekly allowance.

I can imagine that you set up 1,5x speed, which drains it 2,5x of normal usage - based on my experience, even if i spend 15h a day, my 100$ can hold about 3 days on normal speed and not with promo month - if i set the 1,5x speed, it would take probably a day or less. if you max out 200$ with two parallel chat and 1,5x speed, that you might the two days (you are lucky enough to trust the 5.5 model that much - on a really complex project, it's a sabotage)

The thing that stands out here is that this is really two different costs getting blended together:

1. normal model usage
2. waste caused by retries, compaction, and session recovery

If those stay mixed, users will keep arguing about whether 5.5 is just "expensive" when the real bug may be that failed recovery paths are quietly buying more turns than people realize.

The most useful product change would be a per-session breakdown that separates:

• normal turns
• compaction / summarization turns
• recovery / replay after compaction fails
• retries triggered by tool or transport failures

Then a couple of simple guardrails:

• if compaction fails, stop and surface it once instead of limping forward in a half-broken state
• if a session has to replay a large prefix, show that cost before the next turn runs
• cap repeated recovery on the same failure signature

That would turn this from "Codex feels expensive" into something measurable.

This is exactly the class of boring failure that pushed us to build MartinLoop on our side: not smarter agents, just clearer stop conditions, receipts, and cost visibility around the run.

Adding another data point from a paid ChatGPT Pro / Pro 20x account.

Support case: 09851164

This looks like a current-week quota accounting regression, not just "5.5 is more expensive" or "500M tokens is large".

The account's visible weekly reset is June 13, so the relevant current weekly window is roughly June 6 to June 13.

Observed current-week behavior:

• By June 10, user-side observed usage was only about 0.5B to 0.7B tokens.
• The visible general Codex weekly quota was already around / above 80% consumed.
• Local Codex log parsing for June 6 02:40 CST to June 10 09:34 CST shows about 428,840,810 visible token increments.
• In that same window, cached input was about 398,521,856 tokens.
• The latest local rate_limits event showed general codex weekly used_percent at 83%.

The confusing part is the comparison against the same account and same current monthly Pro billing cycle:

• June 1: about 450M observed tokens
• June 2: about 200M
• June 3: about 200M
• June 4: about 500M
• June 5: about 100M
• June 6: about 200M

The user also had much heavier recent peak days, including around 840M on May 30 and 880M on May 31, without the same weekly-limit collapse.

So the problem is not the absolute token number. The problem is the relative accounting ratio: lighter usage in the June 6-June 13 weekly window is consuming quota much faster than heavier usage from the same account just days earlier.

Things that seem worth checking from the Codex side:

• Whether cached input tokens are being charged into the weekly quota at an abnormal/full weight.
• Whether the long-running session / compaction cache-hit issue has regressed.
• Whether Fast / Go mode usage is being classified into the wrong quota bucket.
• Whether general Codex quota and GPT-5.3-Codex-Spark quota are being split or reported inconsistently.
• Whether some account-level plan/risk/rollout classification is causing a paid Pro 20x account to behave like a much lower quota tier.

I understand account-specific support has to go through Support, and that has already been done under case 09851164. But this issue appears to be the same product/accounting class reported here by multiple Pro users, so I am adding the concrete numbers for engineering visibility.

---

Update, June 10 11:09 CST:

I generated a machine-readable aggregate local evidence package and sent it to Support under the same case. The corrected comparison is even clearer:

• Current weekly window, June 6 02:40 CST to June 10 10:16 CST: 834,191,839 visible token increments, about 834M.
• Current weekly cached input: 771,482,752 tokens, about 771M.
• Latest observed general Codex weekly used_percent: 84%.
• Prior reset-aligned week, May 30 02:40 CST to June 6 02:40 CST: 1,102,151,877 visible token increments, about 1.10B.
• Prior window max observed weekly used_percent: 14%.

That means the current window has lower visible token volume than the prior reset-aligned week, but far higher weekly quota burn.

Public escalation / tracking links:

• Developer Community topic: https://community.openai.com/t/codex-is-unfairly-deducting-credits-codex-pro-20x-weekly-quota-accounting-looks-broken-case-09851164/1383230
• X escalation: https://x.com/tngzhy658431902/status/2064543212161863985

The main engineering question is still: why does lower current-window usage burn the paid Pro 20x weekly quota faster than heavier usage in the immediately prior reset-aligned week?

One more escalation for Case 09851164.

After asking friends around me, including paid Pro users, this does not look isolated. Many users feel Codex quota is burning much faster recently. My own account feels especially severe: the effective total quota appears dramatically reduced compared with my previous Pro 20x experience.

This is now a public trust / PR issue, not just a single technical complaint. Users in China are discussing similar quota-drop experiences, and people on X/Twitter are also raising concerns. This has been unresolved for two to three days while paid Pro users rely on Codex for work.

OpenAI, what exactly is happening here? Please provide a concrete answer on whether this is a policy/accounting change, a bug, or abnormal quota deduction, and what will happen for affected Pro users.

Possible impact from #28736.

That bug reproduces stale SessionStart(source=compact) hooks firing on later turns when no new compaction actually occurred. If compact hooks inject context or trigger memory restoration, duplicate late replays would add avoidable token overhead and could contribute to usage drain in long sessions.

I hit the same context compaction death spiral. Compaction fails, session becomes
unusable, I start a new one and re-explain everything. That alone ate about 40% of
my quota last week — not the actual coding, just the session rebuilds.

When compaction fails, the system has to decide what to keep. With a dozen
SKILL.md files loaded, the compaction algorithm has no way to know which skills
are relevant to the current task and which are just noise. It either keeps
everything (bloated) or drops something you need (broken).

If skills were compiled into independent agents, each one would ship with its
own compact context — just enough to do its job. No guesswork about what to keep
or drop in the middle of a session.

We've been working on exactly that: https://github.com/agenthatch/agenthatch