Usage limits normalized this morning but regressed by evening, draining ~5x faster again #31322

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   on Jul 7, 2026
2. github-actions commented on Jul 7, 2026

   

   github-actionsbot

   on Jul 7, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Usage limits draining 5-10x too fast for 2 weeks, one message eats 46% of the 5h window #30939
   • Usage hit 0% with zero messages sent, quota draining with no activity at all #30943
   • Codex Pro 5x quota drops 2-3% for a single normal prompt, equivalent to 10-15% of Plus 5-hour quota #30909
   • Plus: quota hits 100% after idle period with zero sessions; Jul 2 single-prompt drain 1%→100% in 6 min (session logs) #31174
   • Pro 5x subscription ended early and quota is draining while idle after renewal #30081

   Powered by Codex Action
3. in0vik commented on Jul 7, 2026

   

   in0vik

   on Jul 7, 2026

   Author

   More actions

   Additional observation: in parallel with the limit-drain regression, I am also seeing noticeably slower inference / response generation. Sometimes I have to wait several minutes for a response, and subjectively the generation speed feels around ~0.5 tokens/sec.

   This started showing up around the same time as the renewed fast limit drain, so it may be related to the same routing / rate-limiter / anti-abuse state rather than just usage accounting.
4. nabinpkl commented on Jul 7, 2026

   

   nabinpkl

   on Jul 7, 2026

   More actions

   +1 Same observation for me max 5x limits draining 5x in mere about 4-5 messages. feedback id: 019f368b-a811-7343-9f3c-3184ef094dd0
5. liufangyuan247 commented on Jul 7, 2026

   

   liufangyuan247

   on Jul 7, 2026

   Last edited by liufangyuan247

   More actions

   Same here，i switched from pro 5x plan to pro 20x plan yesterday, and it seems 20x is drained as fast as 5x to me.
6. Howchie commented on Jul 7, 2026

   

   Howchie

   on Jul 7, 2026

   Last edited by Howchie

   More actions

   I've hit my 5h limits multiple mornings now on very light work using 5.4. I'm on the plus plan and usually never hit 5h limits. So, adding my voice, usage is totally messed up. The circled days are the two I have hit the 5hr cap and it is clearly nowhere near the usage of previous days (I only work 9-5, but it's very obvious even stacking 5x perfectly complete usage of every 5hr cap couldn't reach some of the other days usage).

   

   It's also not because I'm using a high model as these days I was using lighter models predominantly because the tasks I ran were straightforward and not using big contexts.
   
7. midnighter90 commented on Jul 8, 2026

   

   midnighter90

   on Jul 8, 2026

   More actions

   Just the same here, my usage has gone down but I reach my limit even with the easiest prompts using GPT5.5 on medium
8. Howchie commented on Jul 8, 2026

   

   Howchie

   on Jul 8, 2026

   More actions

   

   These are the days I've hit 5hr usage. Literally my lowest usage working days in the month, and using lower quality models. How is this still not resolved or acknowledged?!
9. midnighter90 commented on Jul 9, 2026

   

   midnighter90

   on Jul 9, 2026

   More actions

   Some very strange things are going on, my usage keeps switching between:

   

   and:

   

   👍React with 👍1Reacted by zrt219
10. zrt219 commented on Jul 12, 2026

    

    zrt219

    on Jul 12, 2026

    More actions

    Same problem for me its insane Feedback ID: 019f53b9-e40d-7930-9014-7fea72713e7a
11. jeffer1312 commented on Sep 7, 2026

    

    jeffer1312

    on Sep 7, 2026

    More actions

    Adding measured data from a single session, in case it helps narrow this down. All figures come from the rate_limits payload the server returned in each token_count event of the local rollout, not from my own estimates.

    Codex CLI 0.153.4, ChatGPT Plus, 2026-09-07. The 5h window was clean at session start (used_percent 0.0, resets_at 15:16:22Z), so everything below happened inside one window.

    Three models used in the same session, same work, cost per 1% of the window:

    model	requests	tokens	tokens per 1%
    gpt-5.6-luna	11	912,873	456,436
    gpt-5.6-sol (low)	20	3,900,265	260,017
    gpt-6-astra (low)	29	6,074,471	77,878

    Two observations that seem more useful than the raw ratio:

    1. The charge looks flat per request, not per token. Two consecutive calls, both gpt-6-astra at low effort:

    13:31:10.908Z — 280,654 tokens — counter 50% -> 53%
    13:31:37.787Z —  45,963 tokens — counter 56% -> 59%
    

    6x difference in payload, same 3-point charge. Across the whole astra phase the cost was a flat ~3 points per request from 17% to 95%, with no correlation to request size.

    2. Cache hits produced no discount. 5,635,200 of 6,061,110 input tokens (93.0%) were cache reads, and the window still drained at full rate. This does not fit the explanation that degraded cache hit rates are what make usage drain faster — my cache hit rate was high and the drain was maximal anyway.

    Net effect: 29 requests exhausted a 5-hour window while producing 13,361 output tokens in total (16 shell commands, 22 assistant messages, one patch). That works out to a ceiling of roughly 33 requests per 5 hours on gpt-6-astra at low effort, regardless of how small each request is.

    Happy to share the full token_count series if it is useful.
12. in0vik commented on Sep 7, 2026

    

    in0vik

    on Sep 7, 2026

    Last edited by in0vik

    Author

    More actions

    try turning off memories
13. jeffer1312 commented on Sep 7, 2026

    

    jeffer1312

    on Sep 7, 2026

    More actions

    @in0vik Thanks — I checked, and memories are already off here, so that is not the cause in my case.

    $ codex features list | grep -i memor
    external_agent_memory_import             under development  false
    memories                                 stable             false
    

    The local store exists but is empty: ~/.codex/memories_1.sqlite has 0 rows in both stage1_outputs and jobs. Grepping every rollout in ~/.codex/sessions/2026/09/ turns up no injected memory content either.

    On the mechanism, I don't think memories could explain this shape anyway. Memories would add input tokens, and the drain in my logs does not track input size at all — a 45,963-token request and a 280,654-token request both moved the counter exactly 3 points. Sending less context does not reduce a charge that is flat per request.

    Since my first comment the 5h window reset and the same pattern reproduced immediately, which rules out it being a one-off:

    15:20:21Z   0%   (window reset, fresh context)
    15:22:32Z  43%
    

    43 points in 2 minutes 11 seconds across 17 requests — 13 from the main session plus 4 from a sub-agent drawing on the same counter — which is 2.5 points per request. That matches the ~3 points per request I measured in the previous window, on a different context, with a different cache state. Every one of those requests carried ~312,000 input tokens at 99.7% cache hit rate and returned between 30 and 260 output tokens.

    So across two independent windows the charge stays flat per request and correlates with nothing: not input size, not cache hit rate, not output size, not reasoning tokens.

    For anyone else measuring this: the numbers are in the token_count events of ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl, under payload.rate_limits.primary.used_percent and payload.info.last_token_usage. That is the server's own accounting, not a local estimate, so it is worth comparing across models before concluding anything about your own usage.
14. jeffer1312 commented on Sep 7, 2026

    

    jeffer1312

    on Sep 7, 2026

    Last edited by jeffer1312

    More actions

    Correction (see follow-up comment): the claim below that there is "no published per-model request ceiling" for Plus is not accurate. A third-party limits tracker publishes 5-45 local messages per 5-hour window for Astra on Plus, and my 29 requests fall inside that range. The per-request charging and cache-discount findings are unaffected.

    Third data point from the same account, a couple of hours after the previous one. I left the session idle for about 100 minutes, then told it to continue. Five requests later:

    15:22:32Z  43%   (end of the previous burst)
    17:03:30Z  47%   <- first request after resuming
    17:03:38Z  50%
    17:03:45Z  53%
    17:03:55Z  56%
    17:04:08Z  60%
    

    17 percentage points in 38 seconds across 5 requests, all gpt-6-astra at low reasoning effort. Per-request input was 312,576 / 313,043 / 316,070 / 316,212 / 325,510 tokens, cache hit rate above 99% on every one, and output was 94 / 53 / 86 / 153 / 200 tokens. So five requests produced 586 output tokens in total and cost roughly a sixth of a 5-hour window.

    That is now three separate bursts in one day, across two windows, with different contexts and different cache states:

    burst	requests	duration	points	points per request
    window 1, 17% -> 95%	29	17 min	78	2.7
    window 2, 0% -> 43%	17	2 min 11 s	43	2.5
    window 2, 43% -> 60%	5	38 s	17	3.4

    I want to be precise about what this does and does not show, because I think it matters for anyone else reporting here.

    It does not show a spike or an erratic counter. The rate is remarkably stable - about 3 points per request no matter what the request contains. What it shows is that the charge is flat per request and correlates with nothing measurable: not input size (45,963 and 280,654 token requests both cost 3 points), not cache hit rate (22% and 99.7% both cost 3 points), not output size, not reasoning tokens.

    The practical consequence is a ceiling of roughly 33 requests per 5-hour window on this model at low effort, regardless of how trivial each request is. OpenAI support has confirmed to me in writing that for Plus there is no published per-model request ceiling, and that neither the per-request-versus-per-token behaviour nor the cache treatment is documented for included limits. So the issue is not that the accounting misbehaves - it is that the rate is both very low and entirely unpublished, which makes it impossible to plan around.

    If others in this thread want to check their own numbers rather than going by the banner, they are in payload.rate_limits.primary.used_percent and payload.info.last_token_usage in ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl. Comparing points-per-request across models in a single session is the measurement that made this legible for me.
15. jeffer1312 commented on Sep 7, 2026

    

    jeffer1312

    on Sep 7, 2026

    More actions

    Correction to my previous comment.

    I wrote that "for Plus there is no published per-model request ceiling." That was based on what OpenAI support told me in the chat, and it is not accurate enough to stand.

    A widely-cited limits tracker publishes a figure for exactly this: 5 to 45 local messages per 5-hour window for GPT-6 Astra on ChatGPT Plus, labelled there as an "official estimate" (codexusage.dev/limits/astra). Several outlets repeat the same range. My 29 requests fall inside it.

    Two caveats I want to be precise about, because the distinction matters for anyone else reporting here:

    1. That tracker is a third party, not OpenAI. I could not find the 5-45 range on OpenAI's own Help Center - article 11369540 ("Using Codex with your ChatGPT plan") carries no per-model message counts at all and defers to the pricing page. So the number is published somewhere and repeated widely, but I cannot point at a first-party OpenAI page stating it.

    2. OpenAI support, in my escalated ticket, told me the 5-45 figure was a ChatGPT Business seat number that does not apply to Plus, and that for Plus they see no published per-model message-count ranges. That contradicts the tracker. One of the two is wrong and I do not know which.

    What my measurements still show, and what the tracker explicitly does not cover: it says nothing about whether subscription allowance is charged per request or per token, and nothing about cache treatment. That is the part my data speaks to - a 45,963-token request and a 280,654-token request both cost 3 points, and a 93% cache hit rate produced no discount. Those two findings are unaffected by the correction above.

    So the accurate framing of my report is narrower than what I wrote before: the request ceiling appears to be published (third-party, unverified against OpenAI's own docs), while the charging model behind it is not.