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

[gsusI]

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

[github-actions]

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

• Weekly limits dropping too quickly #20169
• Remaining limits and credits suddenly drop to zero #19536
• Weekly quota draining insanely fast #21050
• Pro weekly usage limit depletes unusually fast on 5.5, worsened by unstable context compaction #19585
• High token usage on Codex #20796

Powered by Codex Action

[gsusI]

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]

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]

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.