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

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.

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

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.

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:

model usage cost for 5.5 itself, and
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:

model usage cost for 5.5 itself, and

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

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.

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)

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

Correction after tightening the child-rollout replay filter: my first
calculation for the second duplicated run was too low. Child rollouts can
contain copied historical task_started records as well as copied
TokenCount records, so “start after the first task_started” was not a valid
boundary.

Environment:

ChatGPT Pro
macOS arm64
ChatGPT desktop / Codex
incident runtime codex-cli 0.145.0-alpha.30
both duplicated roots used GPT-5.6 Sol / Ultra

The same prompt was executed twice after the earlier task became
undiscoverable in the desktop task list. Each root spawned three Sol/Ultra
child tasks.

Corrected local telemetry:

Run A: 358,514 uncached input + 4,109,312 cached input + 26,091 output =
4,493,917 raw tokens.
Run B: 288,138 uncached input + 2,589,184 cached input + 31,831 output =
2,909,153 raw tokens.
Combined duplicate work: 646,652 uncached input + 6,698,496 cached input +
57,922 output = 7,403,070 raw tokens.

Using the current public Sol rate card, those traces estimate to 115.75 +
92.26 = 208.00 credits. This is an estimate from local telemetry, not an
account billing ledger.

Method correction: the parser now starts at the first task_started whose
event timestamp agrees with its payload started_at, and ignores unchanged
cumulative token snapshots. Across these two runs it excluded 39 copied
prefix token records and seven duplicate snapshots.

The persisted copied records do not prove backend double-charging. They do
prove that local child rollout telemetry cannot be summed naively. The
corrected figures above count only genuine post-boundary model calls.

The separate harness-efficiency finding is now quantified in #34468: repeated
agent waits and status checks re-enter the model and can consume substantial
cached-context credits. Per-task usage attribution should distinguish useful
work, subagent coordination, terminal polling, compaction, retries, restored
history, and user-initiated reruns.

Navigation Menu

Repository navigation

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

What version of Codex is running?

What subscription do you have?

What issue are you seeing?

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

Expected behavior

Actual behavior

Request

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of Codex is running?

What subscription do you have?

What issue are you seeing?

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

Expected behavior

Actual behavior

Request

Activity

github-actions commented on Apr 25, 2026

GGBondBlueWhale commented on Apr 25, 2026

Gelurban commented on Apr 25, 2026

raederhans commented on Apr 25, 2026

carlos-naranjo-aa commented on Apr 26, 2026

hilyfux commented on Apr 26, 2026

GGBondBlueWhale commented on Apr 26, 2026

GGBondBlueWhale commented on Apr 26, 2026

young03600 commented on Apr 26, 2026

ForceofwiII commented on Apr 26, 2026

6 remaining items

jusava commented on Apr 27, 2026

Andrey7584 commented on Apr 27, 2026

b4rlw commented on Apr 28, 2026

fssrepository commented on May 1, 2026

fssrepository commented on May 1, 2026

fssrepository commented on May 1, 2026

fssrepository commented on May 1, 2026

capinfl commented on May 2, 2026

mderganc commented on May 3, 2026

mschulte-dev commented on Jun 5, 2026

fssrepository commented on Jun 5, 2026

Keesan12 commented on Jun 5, 2026

cowwoc commented on Jun 17, 2026

EternalRights commented on Jun 18, 2026

dimasyankauskas commented on Jul 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions