[Rate limits] Windows Desktop 26.721.4979: weekly usage fell from 16% to 3% remaining overnight with no local Codex token events
What version of the Codex App are you using (From “About Codex” dialog)?
26.721.4979.0
The previous installed build observed earlier the same evening was 26.721.3996.0. The 26.721.4979.0 package was installed at approximately 2026-07-25 10:57 Asia/Bangkok and launched at approximately 11:26.
Codex runtime: codex-cli 0.146.0-alpha.3.1.
What subscription do you have?
ChatGPT-authenticated paid plan. Local rate-limit telemetry reports plan_type: prolite; I am not treating that internal label as a public subscription-tier assertion.
What platform is your computer?
Microsoft Windows 11 Pro, version 10.0.26200, build 26200, 64-bit. The desktop app uses its bundled local app-server in WSL.
What issue are you seeing?
The seven-day Codex usage meter changed from 16% remaining to 3% remaining overnight, while local Codex telemetry contains no model-usage events or newly created Codex sessions during the interval.
All timestamps below are Asia/Bangkok (UTC+7).
| Event | Local time | Weekly used | Weekly remaining |
|---|---|---:|---:|
| Last snapshot before inactivity | 2026-07-24 23:12:37 | 84% | 16% |
| User returned and submitted the next prompt | 2026-07-25 11:29:32 | — | — |
| First refreshed quota snapshot | 2026-07-25 11:29:49 | 97% | 3% |
The interval between quota snapshots was about 12 hours 17 minutes.
Read-only scans across every local rollout file for that interval returned:
local token_count events: 0
new local session_meta events: 0
active automations: 0
local memories feature: false
At capture time, the only active Codex task was the diagnostic task resumed by the new prompt. Every other Codex task was idle or not loaded.
The same session's cumulative token telemetry was:
| Snapshot | Total tokens | Cached input | Output | Reasoning output |
|---|---:|---:|---:|---:|
| Before inactivity | 4,622,593 | 4,403,456 | 17,309 | 8,973 |
| First response after return | 4,804,948 | 4,403,456 | 17,942 | 9,465 |
The 182,355-token local increase occurred only after the user returned and resumed the diagnostic thread. Cached-input usage did not increase between these two snapshots, but the first refreshed server response reported the weekly meter 13 percentage points higher.
This is the second delayed movement observed around the same workload:
- a prior large GPT-5.6 Sol task ended with 21% remaining;
- the next diagnostic thread initially refreshed at 18% remaining;
- the diagnostic itself then legitimately moved the meter from 18% to 16% while accumulating about 4.62M local session tokens;
- the later 16% to 3% overnight change has no corresponding local Codex token or session events.
Desktop update/relaunch correlation
The newer desktop package was installed at approximately 10:57 and launched at 11:26. The first 3%-remaining server snapshot arrived at 11:29:49.
This is consistent with the updated/relaunched app fetching a server ledger that had reconciled while the local app was inactive. It does not prove that the update caused the charge.
Account-activity caveat
The unified desktop history records three completed kind=chatgpt conversations during the interval, at approximately 00:13, 04:56, and 07:30 local time. The available metadata does not identify whether those conversations used ordinary Chat or ChatGPT Work. No conversation content, titles, account identifiers, local paths, or thread IDs are included here.
If any conversation used Work, it is a possible account-level source. If they were ordinary Chat, they are only a confounding observation. Activity from another authenticated device would also be absent from local Codex rollouts.
What steps can reproduce the bug?
This appears to be an accounting-delay or account-attribution issue and is not intentionally reproducible.
Observed sequence:
- Run a large GPT-5.6 Sol/tool-heavy Codex task.
- Stop all visible Codex tasks.
- Record the weekly remaining percentage from a local
token_count.rate_limitssnapshot. - Leave Codex inactive for several hours.
- Update/restart Codex Desktop.
- Submit one small prompt or allow the usage view to refresh.
- Compare the first new server-provided rate-limit snapshot with all local rollout events during the idle interval.
What is the expected behavior?
If the account allowance changes while no local Codex task is executing, the UI should identify whether the delta came from:
- delayed reconciliation of a prior Codex task;
- ChatGPT Work;
- another device or cloud task;
- background memory/automation work;
- a retry or server adjustment; or
- corrected/stale client state.
At minimum, server-provided quota values should expose a last-updated time and an attribution or reconciliation event so users can distinguish delayed legitimate usage from hidden or incorrect activity.
Additional information
This closely matches:
- #32827 — delayed seven-day quota updates after heavy GPT-5.6 work
- #28908 — usage decreases without corresponding user activity
- #35186 — weekly quota and displayed token usage disagree
- #32410 — unstable quota display on Windows
It differs from #35259: that report contains many genuine local model turns during wait/status polling. In this overnight interval, there were zero local token events and zero new local sessions.
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action