Repository navigation
Weekly usage % jumps 18pp when plan_type flips pro -> prolite despite only 26M tokens #21216
Description
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?
- Observe the hourly usage table for a day with significant API activity
- Compare the weekly usage % column against the cumulative token count column at each hour
- 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
- 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
Activity
github-actions commentedon May 5, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
gsusI commentedon May 5, 2026
Additional data from the same local
.codexlogs, grouped byEurope/Londonhour. Weekly usage comes frompayload.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 BSTwithplan_type: pro, 5h used1%, weekly used9%. First post-jump snapshot is2026-05-05 16:45:12 BSTwithplan_type: prolite, 5h used13%, weekly used27%, and the same weekly reset timestamp (2026-05-12 05:02:46 BST). Later, at2026-05-05 17:46:50 BST, weekly used returns to0%with a new weekly reset (2026-05-12 17:45:25 BST).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:00has token usage but no weekly snapshot in the local logs.12:00has no token events / no row in the hourly breakdown.gsusI commentedon May 5, 2026
5-minute split for the anomalous 16:00 hour (
Europe/London). Weekly usage is the last observedrate_limits.secondary.used_percentinside each bucket.Recheck: the exact pivot is between
16:44:41and16:45:12. At16:44:41, metadata isplan_type: pro, 5h used1%, weekly used9%. At16:45:12, metadata isplan_type: prolite, 5h used13%, weekly used27%, same weekly reset timestamp. The table below uses the last observed snapshot inside each 5-minute bucket, so the16:45-16:49row shows snapshot16:49:58.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 thepro->prolitetier/denominator change, not the recorded token volume.[-]Weekly usage % jumps 18pp at 17:00 despite only 26M tokens — impossible math[/-][+]Weekly usage % jumps 18pp at 16:00 despite only 26M tokens — impossible math[/+][-]Weekly usage % jumps 18pp at 16:00 despite only 26M tokens — impossible math[/-][+]Weekly usage % jumps 18pp when plan_type flips pro -> prolite despite only 26M tokens[/+]gsusI commentedon May 5, 2026
Rechecked after account/subscription correction. The issue now looks like a tier/window denominator problem.
Observed local
.codexrate-limit snapshots (Europe/London):plan_typeproproliteproliteUser-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 commentedon Aug 2, 2026
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
/statusnevertheless reports the account asPro Lite.prolitedirectly to the displayed namePro Lite; this is therefore not a user-entered label.Workload evidence
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_typechanges fromprotoprolite.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
protoprolite.Requested remediation:
pro/ Pro 20x Codex entitlement until the actual downgrade date.proliterepresents Pro 5x and why it is being returned for an active Pro 20x subscription.I can provide billing evidence and unredacted account details privately. They are intentionally omitted from this public report.