codex - 💡(How to fix) Fix Weekly usage % jumps 18pp when plan_type flips pro -> prolite despite only 26M tokens [4 comments, 2 participants]

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.

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

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