›_ Codex Issues
Codex Issues / #21216

Weekly usage % jumps 18pp when plan_type flips pro -> prolite despite only 26M tokens

Open 💬 5 comments Opened May 5, 2026 by gsusI
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5 xhigh

What platform is your computer?

Darwin 25.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

VSCode

What issue are you seeing?

All times below are Europe/London (BST).

Update: likely tied to subscription tier flip

After rechecking the local .codex logs, the anomalous jump coincides exactly with the rate-limit metadata changing from plan_type: pro to plan_type: prolite.

| Snapshot (Europe/London) | plan_type | 5h used | Weekly used | Weekly reset |
|---|---|---:|---:|---|
| 2026-05-05 16:44:41 BST | pro | 1% | 9% | 2026-05-12 05:02:46 BST |
| 2026-05-05 16:45:12 BST | prolite | 13% | 27% | 2026-05-12 05:02:46 BST |
| 2026-05-05 17:46:50 BST | prolite | 1% | 0% | 2026-05-12 17:45:25 BST |

This changes the likely diagnosis: the anomaly appears related to an account/tier transition rather than a random arithmetic error in one hourly row. The account was reportedly downgraded from Pro 20x to Pro 5x and later restored to Pro 20x; after restoration, the weekly meter returned to 0% with a new weekly reset timestamp.

The original anomaly still looks real. During the prolite interval, the weekly meter behaved as if a much smaller quota/denominator was active. The local logs do not prove the exact denominator was Plus/1x, but the token math still rules out the observed 18pp jump being caused by the recorded token volume.

The Bug

Weekly usage spikes from 9% → 27% (an 18 percentage point jump) between 15:00 and 16:00, but the token count for that hour is only 26,338,028 — roughly 21× too small to explain the jump.

The Numbers Don't Add Up

| Time | Weekly Used | Tokens (cumulative) |
|------|-------------|----------------------|
| 15:00 | 9% | ~279,382,735 |
| 16:00 | 27% | ~279,382,735 + 26,338,028 |

If 279M tokens ≈ 9%, implied weekly quota ≈ 3.1B tokens.

An 18pp jump on that denominator requires ~558M tokens in one hour.

Actual tokens shown for that hour: 26.3M — a 20× discrepancy.

Secondary Anomalies

  • 12:00 — row missing entirely from hourly breakdown
  • 07:00 — has token count but no weekly usage snapshot

What steps can reproduce the bug?

  1. Observe the hourly usage table for a day with significant API activity
  2. Compare the weekly usage % column against the cumulative token count column at each hour
  3. Look at the 15:00 → 16:00 transition: usage jumps from 9% to 27%, but the delta token count for that hour is only ~26M
  4. Do the math: the jump implies ~558M tokens consumed in that hour — the table says 26M

Thread ID: 019df8ef-78e8-7620-bbc7-1e56fb1b9f7e

What is the expected behavior?

Weekly usage % should be strictly consistent with cumulative token counts at every hour. A 26M token hour on a ~3.1B token weekly quota should move the needle by ~0.8 percentage points, not 18.

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20169
  • #19536
  • #21050
  • #19585
  • #20796

Powered by Codex Action

gsusI · 3 months ago

Additional data from the same local .codex logs, grouped by Europe/London hour. Weekly usage comes from payload.rate_limits.secondary.used_percent (window_minutes: 10080, limit_id: codex). Remaining = 100 - used.

Update after recheck: this table spans a rate-limit metadata change. Last pre-jump snapshot is 2026-05-05 16:44:41 BST with plan_type: pro, 5h used 1%, weekly used 9%. First post-jump snapshot is 2026-05-05 16:45:12 BST with plan_type: prolite, 5h used 13%, weekly used 27%, and the same weekly reset timestamp (2026-05-12 05:02:46 BST). Later, at 2026-05-05 17:46:50 BST, weekly used returns to 0% with a new weekly reset (2026-05-12 17:45:25 BST).

| Hour | Total tokens | Input | Cached input | Output | Reasoning | Weekly used | Weekly remaining | Snapshot |
|---:|---:|---:|---:|---:|---:|---:|---:|---|
| 05:00 | 3,439,440 | 3,420,739 | 3,144,960 | 13,734 | 4,967 | 0% | 100% | 05:52:00 |
| 06:00 | 975,214 | 965,370 | 891,520 | 7,944 | 1,900 | 0% | 100% | 06:22:47 |
| 07:00 | 2,238,646 | 2,229,916 | 2,046,848 | 7,260 | 1,470 | n/a | n/a | n/a |
| 08:00 | 77,474,666 | 77,145,986 | 74,453,248 | 235,438 | 93,242 | 2% | 98% | 08:59:59 |
| 09:00 | 49,007,990 | 48,791,235 | 46,691,968 | 154,718 | 62,037 | 4% | 96% | 09:59:27 |
| 10:00 | 53,488,352 | 53,288,511 | 51,019,776 | 142,246 | 57,595 | 4% | 96% | 10:59:50 |
| 11:00 | 86,417,512 | 86,204,994 | 84,342,400 | 159,744 | 52,774 | 8% | 92% | 11:55:28 |
| 13:00 | 166,680 | 166,130 | 3,456 | 401 | 149 | 8% | 92% | 13:07:13 |
| 14:00 | 566,632 | 560,392 | 541,056 | 4,212 | 2,028 | 9% | 91% | 14:52:02 |
| 15:00 | 5,607,603 | 5,544,858 | 5,301,376 | 42,098 | 20,647 | 9% | 91% | 15:59:56 |
| 16:00 | 26,338,028 | 26,297,952 | 25,941,504 | 30,910 | 9,166 | 27% | 73% | 16:59:52 |
| 17:00 | 25,774,334 | 25,719,294 | 25,359,872 | 41,576 | 13,464 | 28% | 72% | 17:36:31 |

The 15:00 -> 16:00 hourly-row jump remains the clearest anomaly: weekly used moves 9% -> 27% while that hour has 26.34M total tokens. Of that, 25.94M is cached input, leaving only 356,448 uncached input tokens plus 40,076 output/reasoning tokens. So if the weekly meter is expected to track anything close to non-cached or billable token consumption, the mismatch is even larger than the raw-total comparison suggests.

The earlier secondary anomalies are still visible in this snapshot:

  • 07:00 has token usage but no weekly snapshot in the local logs.
  • 12:00 has no token events / no row in the hourly breakdown.
gsusI · 3 months ago

5-minute split for the anomalous 16:00 hour (Europe/London). Weekly usage is the last observed rate_limits.secondary.used_percent inside each bucket.

Recheck: the exact pivot is between 16:44:41 and 16:45:12. At 16:44:41, metadata is plan_type: pro, 5h used 1%, weekly used 9%. At 16:45:12, metadata is plan_type: prolite, 5h used 13%, weekly used 27%, same weekly reset timestamp. The table below uses the last observed snapshot inside each 5-minute bucket, so the 16:45-16:49 row shows snapshot 16:49:58.

| Period | Total | Input | Cached | Uncached | Output | Reasoning | Weekly used | Snapshot |
|---|---:|---:|---:|---:|---:|---:|---:|---|
| 16:00-16:04 | 4,259,450 | 4,256,252 | 4,240,640 | 15,612 | 2,601 | 597 | 9% | 16:04:52 |
| 16:05-16:09 | 3,857,352 | 3,854,913 | 3,841,408 | 13,505 | 2,134 | 305 | 9% | 16:09:36 |
| 16:10-16:14 | 1,444,255 | 1,443,211 | 1,438,208 | 5,003 | 963 | 81 | 9% | 16:14:49 |
| 16:15-16:19 | 1,490,037 | 1,487,328 | 1,417,344 | 69,984 | 2,101 | 608 | 9% | 16:19:32 |
| 16:20-16:24 | 1,444,982 | 1,443,058 | 1,433,472 | 9,586 | 1,544 | 380 | 9% | 16:24:28 |
| 16:25-16:29 | 1,390,439 | 1,389,692 | 1,385,088 | 4,604 | 696 | 51 | 9% | 16:29:50 |
| 16:30-16:34 | 1,277,605 | 1,276,943 | 1,273,088 | 3,855 | 624 | 38 | 9% | 16:34:38 |
| 16:35-16:39 | 1,272,731 | 1,272,065 | 1,174,784 | 97,281 | 620 | 46 | 9% | 16:39:46 |
| 16:40-16:44 | 1,214,623 | 1,213,990 | 1,210,112 | 3,878 | 604 | 29 | 9% | 16:44:41 |
| 16:45-16:49 | 2,577,600 | 2,569,441 | 2,508,416 | 61,025 | 5,777 | 2,382 | 27% | 16:49:58 |
| 16:50-16:54 | 4,551,999 | 4,535,178 | 4,468,096 | 67,082 | 12,248 | 4,573 | 27% | 16:54:31 |
| 16:55-16:59 | 1,556,955 | 1,555,881 | 1,550,848 | 5,033 | 998 | 76 | 27% | 16:59:52 |

Key point: the bucket where the meter jumps (16:45-16:49) has only 2.58M total tokens, of which 2.51M are cached input. It has only 61k uncached input and 8.2k output+reasoning, yet weekly usage jumps 18 percentage points. The newly checked metadata suggests the trigger is the pro -> prolite tier/denominator change, not the recorded token volume.

gsusI · 3 months ago

Rechecked after account/subscription correction. The issue now looks like a tier/window denominator problem.

Observed local .codex rate-limit snapshots (Europe/London):

| Snapshot | plan_type | 5h used | Weekly used | Weekly reset |
|---|---|---:|---:|---|
| 2026-05-05 16:44:41 BST | pro | 1% | 9% | 2026-05-12 05:02:46 BST |
| 2026-05-05 16:45:12 BST | prolite | 13% | 27% | 2026-05-12 05:02:46 BST |
| 2026-05-05 17:46:50 BST | prolite | 1% | 0% | 2026-05-12 17:45:25 BST |

User-side account context: subscription was unexpectedly downgraded from Pro 20x to Pro 5x, then restored to Pro 20x. After the restoration, the weekly meter returned to 0% and the weekly reset timestamp changed.

So the original anomaly still appears real, but the likely root cause is more specific: while the local logs reported plan_type: prolite, the weekly/5h percentages seem to have been computed against a much smaller effective quota/denominator than expected. The local logs do not prove the exact denominator was Plus/1x, but the observed token volume still cannot explain a 9% -> 27% weekly jump by itself.

agent-pipe-shared · 25 days ago

i am on pro 20x plan and paying so much but CLI says prolite and my weekly limit just deplets sooo fast. That such a bad experience and also support seems not to want to work :( canceled the plan already:

////////// AI slop input: ////

Additional reproduction on Codex CLI 0.146.0 and desktop

I am seeing a closely matching entitlement and quota-denominator mismatch.

Account and entitlement evidence

  • Billing confirms the highest individual ChatGPT Pro 20x tier.
  • The subscription remains active until a scheduled downgrade to Plus on August 13, 2026.
  • Codex CLI /status nevertheless reports the account as Pro Lite.
  • The public Codex source maps the backend value prolite directly to the displayed name Pro Lite; this is therefore not a user-entered label.
  • Both Codex CLI and the desktop usage page report the same general weekly state:
  • 17% remaining
  • reset on August 8
  • The previously displayed reset was approximately August 3 and moved before that date was reached.
  • An August 8 seven-day window implies that approximately 83% of the effective weekly allowance was consumed within roughly one day.

Workload evidence

  • Primary model: GPT-5.6 Terra
  • Reasoning: high
  • Fast Mode: disabled
  • The separate GPT-5.3-Codex-Spark weekly allowance remains at 100%.

This does not look like a CLI-only display problem because the desktop usage surface reports the same percentage and reset date. It appears consistent with the smaller effective quota denominator described in this issue when plan_type changes from pro to prolite.

Support failure and immediate impact

I submitted the complete evidence through OpenAI's support chat and explicitly requested escalation as an account-entitlement mismatch. The automated support flow only replied that the case had been escalated and that a specialist might respond “in the coming days”. It supplied no case number, no human acknowledgement, and no temporary remediation, and it stopped responding to follow-up messages.

That is not an adequate support path for the highest-priced individual plan when the potentially incorrect quota is already nearly exhausted. The account may lose access before a specialist responds, despite an active Pro 20x subscription.

Requested action

Please investigate whether the scheduled future downgrade caused the Codex entitlement to change prematurely from pro to prolite.

Requested remediation:

  1. Restore the effective pro / Pro 20x Codex entitlement until the actual downgrade date.
  2. Recalculate or reset the weekly quota against the correct denominator.
  3. Provide temporary usage restoration or credits while the entitlement mismatch is investigated.
  4. Clarify whether prolite represents Pro 5x and why it is being returned for an active Pro 20x subscription.
  5. Provide a support case reference or another working escalation route for account-specific correction.

I can provide billing evidence and unredacted account details privately. They are intentionally omitted from this public report.