Usage limits draining abnormally fast on Plus: 70% to 100% in about 6 minutes on July 2, 2026

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

• #30909
• #30842
• #30694
• #30357
• #29587

Powered by Codex Action

I just gave codex a prompt and it ran for 30 minutes, used up all credits for the 5 hour window. Something is definitely broken.

I just gave codex a prompt and it ran for 30 minutes, used up all credits for the 5 hour window. Something is definitely broken.

019f14b6-e3eb-79c1-8e55-de86fe29e7fc

I'm also seeing my usage being consumed at a faster rate today than before today.

Have the same problem

• Codex 100 $ plan - 2x 3 hours session on 5.5 high/medium reasoning, 48 % of weekly limit gone.
• Enterprise plan - 4x 5h window = weekly usage gone
• Easy task - codex working 1 hour in loop, editing same files 10 times and didn't even fix it, eats half of 5 hour window, today this happened 4 times to me
• You write something in the prompt to do that that way - codex will decide to do it completely different, you try to prompt again to do it that way, again no success - this I saw in the last 2 weeks most.

I am working with codex 10-12 hours a day, so these are not things that I saw one or two times

same here. not able to progress my work properly.. its draining in less than 30 mins for 1-2 tasks.

I'm also seeing my usage being consumed at a faster rate today than before today.

Same here. 1 question and 2 code reviews hit the limit.

I am seeing same issues too.

Same pattern, with reproducible local trace — and a request for a usage API

+1 to this report. I hit the same thing on 2026-07-05 (two consecutive 5h windows exhausted) and was able to reproduce the invisible spend locally. Related cluster — paging their authors to consolidate evidence:
#31125, #29895, #30939, #28065, #26791, #22008.

TL;DR

• 2 consecutive 5h limits exhausted on 2026-07-05.
• The only local audit tool (ccusage, reads ~/.codex/sessions/) shows just $8.78 for that day — nowhere near enough to drain two windows.
• The actual spend is 10 hidden sessions that called the model (2,576 API calls, gpt-5.5 xhigh) but are invisible to every local source — no rollout file, no usage numbers anywhere on disk.
• Ground truth exists only on OpenAI's server (web dashboard, Exec category).

What happened

Using Claude Code with the codex-plugin-cc plugin, the orchestrator triggered /codex:adversarial-review runs. Each spawns codex app-server, which creates ephemeral threads that:

1. Are real — they call the model (confirmed by codex_api::sse trace entries in ~/.codex/logs_2.sqlite).
2. Are billable — accounted server-side, visible in the web dashboard.
3. Leave no local transcript — no rollout .jsonl in ~/.codex/sessions/, so ccusage and any local audit see $0 for them.
4. Are unregistered — absent from the thread catalog (~/.codex/sqlite/codex-dev.db, local_thread_catalog).

The only local artefact of these sessions is trace telemetry with no token counts — just span metadata (session_loop{...}:turn{...}).

The 10 hidden threads (paths anonymized)

All timestamps UTC. effort = reasoning_effort. "API calls" = codex_api::sse::responses trace entries per thread. None has a rollout file.

| thread_id | start UTC | end UTC | model | effort | API calls | log entries | rollout? |
|---|---|---|---|---|---|---|---|
| 019f2e5e-78b6-7b93-87d2-65db31b86f3c | 07-04 18:22 | 07-04 18:28 | gpt-5.4 | medium | 361 | 690 | none |
| 019f2e67-9498-7311-99d3-68a2fbade810 | 07-04 18:32 | 07-04 18:32 | codex-auto-review | low | 4 | 25 | none |
| 019f2e83-f7f1-7123-8d06-348c89ddf82f | 07-04 19:03 | 07-04 19:03 | gpt-5.4-mini | low | 4 | 50 | none |
| 019f3070-1a8b-75f2-a903-0228ae4cd9ca | 07-05 04:01 | 07-05 04:05 | gpt-5.5 | xhigh | 163 | 591 | none |
| 019f30c4-5f0e-75d2-8d67-100159a2f05e | 07-05 05:33 | 07-05 05:38 | gpt-5.5 | xhigh | 148 | 573 | none |
| 019f30d4-d8b2-7832-97fb-e3700290f873 | 07-05 05:51 | 07-05 05:54 | gpt-5.5 | xhigh | 90 | 467 | none |
| 019f31b5-fb8b-7443-8f62-f20e4f4a5f25 | 07-05 09:57 | 07-05 10:00 | gpt-5.5 | xhigh | 299 | 628 | none |
| 019f31c4-d67d-7573-a8db-4cf29afac20d | 07-05 10:13 | 07-05 10:16 | gpt-5.5 | xhigh | 628 | 1,000 | none |
| 019f31f3-0133-73c2-95fc-51cfed35ce7e | 07-05 11:03 | 07-05 11:05 | gpt-5.5 | xhigh | 261 | 526 | none |
| 019f31f8-a27d-7c32-9090-46d26ed2d400 | 07-05 11:10 | 07-05 11:15 | gpt-5.5 | xhigh | 618 | 1,000 | none |
| TOTAL | | | | | 2,576 | 5,550 | 0 rollout files |

(cwd values anonymized to ~/project-A..D; real project names/paths redacted. Thread IDs kept — OpenAI can join them to server-side usage.)

The limits that bracket them

Two plugin runs hit usage_limit_exceeded before reaching the model (legitimately 0-token, correctly absent everywhere — they prove the window was already drained):

| plugin run | time (local, +0800) | server reply |
|---|---|---|
| run 1 | 2026-07-05 21:08 | "try again at 10:07 PM" |
| run 2 | 2026-07-06 02:44 | "try again at 3:09 AM" |

Core problem: no local usage for app-server sessions

Verified exhaustively — none of these records usage for the hidden threads:

| local source | contains usage for these threads? |
|---|---|
| ~/.codex/sessions/**/*.jsonl (what ccusage reads) | no (no rollout files) |
| ~/.codex/logs_2.sqlite (telemetry) | no token counts — only trace span metadata |
| ~/.codex/sqlite/codex-dev.db (thread catalog) | threads not registered at all |
| ~/.codex/session_index.jsonl | not present |
| full-disk search by thread_id | 0 files |

So the only way to reconcile a mysteriously-drained 5h window is to eyeball the web dashboard. There is no programmatic path from a depleted window back to the specific sessions/turns that consumed it.

Request — two things that would unblock triage for the whole cluster

(a) A read-only API endpoint for per-thread usage, keyed by Codex thread_id (and ideally turn_id / submission_id), returning input_tokens / cached_input_tokens / output_tokens / reasoning_output_tokens and the billing category.

The join keys already exist in local telemetry (logs_2.sqlite.thread_id, turn{turn.id=...}) — only the numbers are server-side. One endpoint would let every affected user (and tools like ccusage) reconcile a depleted window against specific sessions instead of guessing. Please 👍 if you'd use this — it directly enables debugging the entire "limits draining faster than expected" cluster.

(b) Persist token usage locally for app-server sessions the way Codex Desktop does for interactive ones (rollout token_count events). Right now app-server sessions are bill in the cloud, log nothing locally — the exact opacity that makes these reports so hard to triage. Even one token_count-style event per app-server turn would make every existing audit tool correct by construction.

---

If anyone here has found a server-side usage export or an API path that exposes per-thread/per-turn tokens, please share — it would unblock triage for all of us. Happy to attach more anonymized telemetry if a maintainer wants it.

@jif-oai @anp-oai @pakrym-oai @rka-oai @bolinfest @etraut-openai @xl-openai @aibrahim-oai @cconger @sayan-oai @canvrno-oai @celia-oai @owenlin0 @richardopenai @tamird @charlesgong-openai @felixxia-oai @fcoury-oai @viyatb-oai @adaley-openai @apanasenko-oai @shijie-oai @iceweasel-oai @won-openai @guinness-oai @jameswt-oai @rhan-oai @wiltzius-openai @winston-openai @codex @ericning-o @stefanstokic-oai @abhinav-oai @alexsong-oai @dylan-hurd-oai @charliemarsh-oai @fjord-oai @mchen-oai @mzeng-openai @nornagon-openai @adrian-openai @fc-oai @marksteinbrick-oai @zanie-oai @ddr-oai @gpeal @rasmusrygaard @xli-oai

Related discussion: https://github.com/openai/codex/issues/31125#issuecomment-4889181698

I added a broader observation there because the reported 80% -> 0% limit drop looks related to the same class of issue: high Codex usage without enough local token/session audit data to identify the root cause.

What's the remedy to this issue???

What's the remedy to this issue???

Waiting for a response from the developers, I've already tagged them all here. We hope they quickly notice this problem and the problem with SSD degradation due to Codex and fix these critical, important issues for the entire community.

The problem is still ongoing... 😪

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

My graph shows this pretty clearly and also I have no "hidden" usage, the web portal is clearly showing much lower usage than other days yet my limits are exhausted consistently in the last 2-3 days.

I think they fixed it. Updated codex this morning and token consumption seems normal again. Are we going to get reimbursed for the lost tokens???

It's definitely become better but is it just me or has 5.5 High been nerfed? Would love to know what's changed from the open AI team

I'm in Australia so unfortunately i was affected all day, yesterday too.
Felt ok over the weekend but to be honest I was mostly burning my Fable
allocation so maybe I wouldn't have noticed.

On Tue, 7 July 2026, 5:52 pm klsmunds, @.***> wrote:

klsmunds left a comment (openai/codex#30918) <https://github.com/openai/codex/issues/30918#issuecomment-4902465180> I think they fixed it. Updated codex this morning and token consumption seems normal again. Are we going to get reimbursed for the lost tokens??? — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/30918?email_source=notifications&email_token=AC5SRY6ZD3EOXOU2XVXJAO35DTB5HA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGI2DMNJRHAYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4902465180>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5SRY4SWCHOQDUS3ETRV235DTB5HAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TINZZGM2DKNRUHAYKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AC5SRYZIWSQ3R7ER6UE37CL5DTB5HA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGI2DMNJRHAYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AC5SRY7ONZBS5PW6ISQ3KST5DTB5HA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGI2DMNJRHAYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

Probably the 516 token bug

On Tue, 7 July 2026, 6:11 pm gititya, @.***> wrote:

gititya left a comment (openai/codex#30918) <https://github.com/openai/codex/issues/30918#issuecomment-4902634487> It's definitely become better but is it just me or has 5.5 High been nerfed? Would love to know what's changed from the open AI team — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/30918?email_source=notifications&email_token=AC5SRYZNN3MFLPVINR3CZMD5DTED5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGI3DGNBUHA32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4902634487>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5SRY2FNIFMHSPKJ4CJ2ND5DTED5AVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TINZZGM2DKNRUHAYKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AC5SRYZSN2HV4GEUL67QKNL5DTED5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGI3DGNBUHA32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AC5SRY6C4Y2JMN65MFHQ5635DTED5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGI3DGNBUHA32M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

@jif-oai @anp-oai @pakrym-oai @rka-oai @bolinfest @etraut-openai @xl-openai @aibrahim-oai @cconger @sayan-oai @canvrno-oai @celia-oai @owenlin0 @richardopenai @tamird @charlesgong-openai @felixxia-oai @fcoury-oai @viyatb-oai @adaley-openai @apanasenko-oai @shijie-oai @iceweasel-oai @won-openai @guinness-oai @jameswt-oai @rhan-oai @wiltzius-openai @winston-openai @codex @ericning-o @stefanstokic-oai @abhinav-oai @alexsong-oai @dylan-hurd-oai @charliemarsh-oai @fjord-oai @mchen-oai @mzeng-openai @nornagon-openai @adrian-openai @fc-oai @marksteinbrick-oai @zanie-oai @ddr-oai @gpeal @rasmusrygaard @xli-oai Related discussion: #31125 (comment) I added a broader observation there because the reported 80% -> 0% limit drop looks related to the same class of issue: high Codex usage without enough local token/session audit data to identify the root cause.

How do I get my tokens back?

Cancelled for now until they fix this! Every time I ask what time is it, I'm 1% down on my 5hr usage limit :D !

One prompt just cost me 50%, clearly not fixed. I'm no joke getting more
fable usage than 5.4 in a 5hr block this is absolutely ridiculous.

On Wed, 8 July 2026, 8:56 pm Dranzd Viper, @.***> wrote:

dranzd left a comment (openai/codex#30918) <https://github.com/openai/codex/issues/30918#issuecomment-4914998622> Cancelled for now until they fix this! Every time I ask what time is it, I'm 1% down on my 5hr usage limit :D ! — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/30918?email_source=notifications&email_token=AC5SRY7R5U4NCH2PCQV5SAL5DZAIJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJRGQ4TSOBWGIZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4914998622>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC5SRY6FLIADV4F4GCMKQFL5DZAIJAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TINZZGM2DKNRUHAYKC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AC5SRY55GEY4Z6ACBI3CYFL5DZAIJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJRGQ4TSOBWGIZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AC5SRY5IEJXXH53BZVLSE6T5DZAIJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJRGQ4TSOBWGIZKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>

I just recently started using Codex for my new job. It worked fine until yesterday afternoon, but now it's unusable.
I never even came close to my 5 hour limit until then.
From one moment to the next, it just started eating up my usage limits extremely fast. Asking "Say hi" while in a completely empty directory and getting a "hi" back costs at least one percent. Asking the simple question why my usage is going down so fast on low reasoning took about one minute to answer and burned through 8%. And it did not provide a real answer, of course.
Starting any task in my (small) project basically immediately runs into the limit.
I started a task, ran into the limit, did use a reset (had 4, because I never had to use them before) and was left with 50%. The task itself took less than 10 minutes.
And the reasoning on the desktop app (Windows) always reverts to "Very High", even though I am always scaling it down to "Medium" or "Low".
I'll have to ask my employer now if I can use another model, or revert to doing anything by hand again (。_。)

I’m experiencing the same issue on ChatGPT Plus with the Codex desktop app on Windows. Today, July 11, 2026, my five-hour usage allowance was exhausted unusually quickly even though I had not used Codex heavily.
My activity was ordinary repository work: reading documentation, editing a README, running local verification commands, committing, pushing, and checking GitHub Actions. The amount of interactive work does not appear consistent with the speed at which the five-hour allowance was consumed.
I did not intentionally run long background tasks or extensive parallel agents. This makes me suspect abnormal usage accounting, hidden/background usage attribution, or unexpectedly high per-turn weighting.
Please investigate whether Windows desktop sessions or tool-heavy turns are being charged incorrectly. I can provide sanitized session timestamps and rate-limit events if the maintainers explain which diagnostics would be useful.