›_ Codex Issues
Codex Issues / #39167

[Pro 20x] Weekly limit jumped 88% -> 100% with zero client activity overnight (Windows)

Resolved 💬 5 comments Opened Aug 18, 2026 by akivavh Closed Aug 19, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

26.814.41407 (CLI 0.148.0-alpha.15). The sessions before the jump ran CLI 0.148.0-alpha.9; the app auto-updated to alpha.15 at 2026-08-18 06:35Z, ~6 minutes before the first blocked turn.

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The weekly usage limit went from 88% used to 100% used across a window in which the client sent zero requests to the backend. All timestamps below are UTC; my local time is UTC+2.

Last observed reading (from a token_count event in the session rollout):

"rate_limits": {
  "limit_id": "codex",
  "primary": { "used_percent": 88.0, "window_minutes": 10080, "resets_at": 1787214518 },
  "secondary": null,
  "credits": { "has_credits": false, "unlimited": false, "balance": "0" },
  "plan_type": "pro"
}

Emitted at 2026-08-17T21:24:35Z. resets_at = Aug 20 2026 10:28 local.

The silent window (2026-08-17T21:25Z → 2026-08-18T06:41Z):

  • Last completed turn: 2026-08-17T21:24:40Z.
  • In those ~9 hours the app emitted 8 log lines total, all op: Shutdown (at 22:50Z and 2026-08-18T00:40Z). A single turn normally produces dozens of lines.
  • Zero HTTP requests to the backend. Last request before the gap: 2026-08-17T20:19:17Z (POST /codex/alpha/search, 200). Next request: 2026-08-18T04:50:33Z (GET /codex/models, 401).
  • A single app-server process stayed alive from 2026-08-17T20:20:55Z to 2026-08-18T06:35:44Z — the app was not restarted overnight, so this is not an app-launch or background-suggestion side effect (cf. #37445).

First turn after waking up (2026-08-18T06:41:53Z, session 01a0139a-bd99-7393-a631-1635d6cf8b94, single-word prompt "test"):

You've hit your usage limit. Visit https://chatgpt.com/codex/settings/usage
to purchase more credits or try again at Aug 20th, 2026 10:28 AM.
codex_error_info: usage_limit_exceeded

Dashboard now: Weekly usage limit 0% remaining, Credits remaining 0, GPT-5.3-Codex-Spark 100% remaining.

The reset date did NOT move. resets_at: 1787214518 is identical in the last good reading (Aug 17) and in the dashboard today (Aug 20 2026 10:28 local). This distinguishes my case from #38332 and #38901, where the window reset and the date shifted — here the window stayed put and only the counter jumped.

What steps can reproduce the bug?

No deterministic repro — reporting the observed timeline plus the arithmetic that makes accidental consumption implausible.

Rate arithmetic from my own account. The usage dashboard reports 334 turns on Aug 17 (Desktop 99 + CLI 235). Over that same day the meter moved 77% → 88%, i.e. ~11 percentage points for 334 turns, about 30 turns per point. Closing the remaining 12 points at that rate would require ~360 additional turns — more than my entire day's work — inside a window with no requests at all.

Comparison day: Aug 13 was my heaviest in this window at 431 turns (Desktop 130 + CLI 301).

The meter lags heavily, which is why the jump was invisible until it was too late. Completed turns cross-referenced against meter updates inside one session:

17:00Z  meter = 87%
17:02Z  turn completed
17:24Z  turn completed
18:29Z  turn completed
19:40Z  turn completed
20:17Z  turn completed
20:22Z  turn completed
20:25Z  turn completed
20:51Z  turn completed
21:20Z  meter = 88%

Eight completed turns, one point of movement. The value shown in the app is the last figure the server echoed back, not a live balance. Full-day series for Aug 17: 77% (07:21Z) → 82% (10:53Z) → 83% (11:19Z) → 85% (15:22Z) → 86% (16:38Z) → 87% (17:00Z) → 88% (21:20Z).

Three different limit_id values were observed on this account within 24h:

| limit_id | when | payload |
|---|---|---|
| codex | all of Aug 17 (819 events) | used_percent populated, window_minutes: 10080, plan_type: "pro" |
| codex_bengalfox | Aug 17 07:23Z (184 events) | used_percent: 0.0, same 10080 window |
| premium | Aug 18 06:41Z, with the rejection (1 event) | primary: null, no window_minutes, no plan_type |

The client read codex all day and was blocked by premium. I don't know whether these are the same counter under different names.

What is the expected behavior?

The weekly counter should not advance while the client is idle and issuing no requests. If the jump does represent real usage accounted for late, it should be attributable somewhere — the usage dashboard shows zero activity for Aug 18 across every surface (Desktop, CLI, Extension, Cloud, Mobile, Code review).

Additional information

Workload shape (may matter for how turns are priced):

  • All sessions ran gpt-5.6-sol at reasoning_effort: high. #38354 reports entitlement trouble with that model on ChatGPT accounts.
  • My usage is heavily subagent-based: of the August session rollouts on this machine, 510 are thread_spawn subagents vs 91 interactive vscode sessions and 16 exec. On Aug 17 the dashboard attributes 235 of 334 turns to "CLI" even though every rollout on disk carries originator: "Codex Desktop" — so subagent traffic appears to be billed as CLI.
  • Long-lived threads: the main thread of that day had accumulated ~503M cumulative tokens (with cache reads) by the evening.
  • Several threads that issue the internal "one-line activity" summaries produce turns that leave no rollout file at all, so local rollouts undercount real traffic. Total 7-day turns per the dashboard: 1,635. Plugins calls: 0.

Ruled out on my side:

  • Cloud, Mobile, Extension and Code review are at zero for the whole period (Code review: 0 PRs, 0 issues found).
  • Credits usage history shows no events since Aug 5; balance has been 0 since then, auto-reload not enabled.
  • No cron/scheduled Codex jobs on this machine.

Auth noise the same morning (probably unrelated, included for completeness): GET /codex/models returned 401 "Provided authentication token is expired" every ~3 minutes from 04:50Z to 06:32Z, with one 200 at 06:14Z, until a token refresh at 06:33:50Z (auth.json last_refresh). The usage rejection came after auth was healthy again.

Possibly related issues: #38335 (Pro 20x on Windows, disproportionate 7-day depletion; references a 48% → 23% jump in #38191), #21226 (weekly limit to 100% without usage, closed with no public cause), #26512 (quota drains passively when not using Codex), #37445 (fixed % consumed per background suggestion run), #38332 / #38901 (unexpected weekly reset moving the reset date — note mine did not move).

Happy to provide raw log extracts (logs_2.sqlite query output) or the session rollout on request.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 10 days ago

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

  • #38191
  • #38294

Powered by Codex Action

akivavh · 10 days ago

Not a duplicate of either, though #38294 is a close neighbour and worth linking.

vs #38191 (macOS, 48% → 23%): there the drain happens during real turns — an auto-injected context/memory payload inflating each new turn, and the reporter notes "very little intentional use", i.e. there was use. In my case there were zero HTTP requests to the backend across the whole 9-hour window (verified in the client's own request log: last request 2026-08-17T20:19:17Z, next request 2026-08-18T04:50:33Z), and my reset date did not move.

vs #38294: that one consumes org-assigned credits (5k/10k caps exceeded 4–7x without enforcement) from the VS Code extension. Mine is the weekly limit percentage on a personal Pro 20x account, with credits already at 0 since Aug 5 and no cap overrun — the allowance was exhausted, not exceeded.

What #38294 and this issue do share is the temporal signature: last task before sleeping, ~9 hours idle, consumption already accounted for on waking. Two different accounting mechanisms showing the same overnight pattern may be worth correlating during triage.

smsubaie · 9 days ago

Same profile here — Pro 20x, Windows, Codex desktop: #39260.

In my case the weekly limit also reached 100%, and separately the Credits usage history stopped writing entries on 8 August and has not resumed in ten days, while the balance kept decrementing to zero. 45,594 of 53,000 purchased credits have no record at any date.

If your limit jumped overnight with zero client activity, it may be worth checking Codex Settings, Analytics, Credits usage history to see whether your log has also frozen at a fixed date. Several of us in this cluster show the same pattern, and a shared freeze window would narrow it a lot.

Related: #38294, #38984, #19242.

akivavh · 9 days ago

Follow-up with additional checks, plus one correction and one triage note.

Alternative sources of consumption during the window — all ruled out

Since "something of yours must have been running" is the obvious objection, I checked each candidate on this machine:

  • No scheduled tasks. Windows Task Scheduler has zero entries invoking codex or any agent runner.
  • No exec sessions in August at all. The last codex_exec / source: exec rollouts on this machine are from July (12th, 22nd, 26th, 29th). Not one in August, including the incident window.
  • Single app-server process alive from 2026-08-17T20:20:55Z to 2026-08-18T06:35:44Z — no restart, so no app-launch or background-suggestion side effect.
  • No second machine or device. Other machines with Codex installed were idle; no mobile or web session.
  • Cloud, Mobile, Extension and Code review report zero for the whole period.

So for the 9-hour window the client made no requests, and nothing else on the account did either.

Triage note: the dashboard's "CLI" surface is not CLI

This confused my own diagnosis and may confuse yours. On Aug 17 the usage dashboard attributes 235 of 334 turns to "CLI" — but there was no CLI usage at all that day. Every rollout on disk carries originator: "Codex Desktop", and there were no exec sessions in August.

What generates that traffic is subagents. In August this account has 510 thread_spawn rollouts vs 91 interactive vscode sessions. They are billed like full turns, they don't always write a rollout file, and the Turns → By surface breakdown files them under "CLI". If the surface dimension distinguished subagent traffic from actual CLI invocations, accounting anomalies like this one would be much easier to localise.

Correction to the original report

I wrote that the Credits usage history showed no events since Aug 5. That was true at filing time; the account has since received and spent a separate credit grant on Aug 18, which now appears there. It does not affect the incident: during the reported window the credit balance was 0 and no credits were consumed.

On global resets — this is the opposite direction

For completeness, since resets came up in related issues: this account's weekly window was re-dated several times in July and August, matching the announced global resets (Jul 28–29, Aug 9, Aug 11, Aug 13 for the 15M milestone). Since the Aug 13 reset the window has been fixed at Aug 20 10:28 local and has not moved.

That matters because a reset lowers the counter. The event reported here happened with the window stationary and moved the counter up, from 88% to 100%, with no client activity. It is not a reset landing late or a window rollover.

akivavh · 9 days ago

Root cause found — this is not an accounting bug. Closing.

The jump was caused by a plan downgrade landing mid-window, on the same day.

Billing history:

2026-07-12   ChatGPT Pro 5x     (base plan)
2026-07-18   ChatGPT Pro 20x    (upgrade)
2026-08-18   ChatGPT Pro 5x     (renewed on the lower plan)

And what Codex itself recorded, independently, in the rollout rate_limits payloads:

plan_type "prolite"   Jul 07 → Jul 16     (= Pro 5x)
plan_type "pro"       Jul 18 → Aug 17     (= Pro 20x)

The two line up to the day: prolite → pro on Jul 18 when the 20x upgrade was billed, and the subscription renewed as Pro 5x on Aug 18 — the exact night of the reported jump.

Mechanism: the weekly window ran Aug 13 → Aug 20 with 88% consumed against the Pro 20x allowance. When the plan renewed at Pro 5x mid-window, the already-consumed usage was recalculated against a roughly 4x smaller allowance. 88% of 20x is far past 100% of 5x, so the counter pinned at 100%. Anything above ~25% consumed would have produced the same result.

So the "zero client activity" evidence in the original report was accurate — there genuinely were no requests that night — but the counter didn't move because of consumption. The denominator changed. That also explains the two loose ends I flagged: why limit_id switched from codex to premium, and why the rejection payload arrived with primary: null and no plan_type.

Apologies for the noise, and thanks to those who engaged.

---

Leaving three observations that are real, in case they're useful — none of them warrant this issue staying open:

  1. No warning at any point. The rejection message says "You've hit your usage limit" with no indication that the plan changed mid-window. The usage dashboard doesn't surface it either. A user in this situation has no way to connect the two events; it took a full billing-history check to find it.
  1. The in-app meter lags badly. In this account, eight completed turns across 4h20 moved the counter by a single point (87% → 88%). The figure shown is the last value the server echoed, not a live balance — so a user can be at effectively zero while the UI still shows headroom.
  1. The Turns → By surface breakdown files subagent traffic under "CLI". This account had 510 thread_spawn rollouts vs 91 interactive sessions in August and zero actual exec/CLI sessions, yet the dashboard attributed 235 of 334 turns on Aug 17 to "CLI". Separating subagent traffic from real CLI invocations would make usage anomalies much easier for users to localise themselves.

For anyone landing here from a search: if your weekly limit jumps to 100% with no activity, check whether your billing cycle renewed on a lower plan.