[ChatGPT Desktop] Weekly usage jumped from 16% to 75% after reset with no local requests during a 5-hour gap
What version of the Codex App are you using (From “About Codex” dialog)?
26.727.51351
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
My Codex weekly usage allowance in the ChatGPT desktop app was reset on August 1, 2026, at approximately 11:00 (UTC+8).
All affected activity was performed exclusively in ChatGPT — Powered by Codex & OWL, desktop app version 26.727.51351.
Local logs show the weekly usage value eventually resetting from 32% to 0%. Later, the server-reported usage jumped from 16% at 16:02 to 75% at 21:26, even though there were no local model requests during that five-hour interval.
The first request at 21:26 used only 23,833 raw tokens. It could not have directly caused a 59-percentage-point increase by itself. Its first response already contained the 75% value, indicating that the increase happened outside the locally observable request timeline or was reconciled only when the client next contacted the server.
Environment
- Product: ChatGPT desktop app
- Product label: Powered by Codex & OWL
- App version:
26.727.51351 - App build:
6119 - Plan: ChatGPT Plus
- Operating system: macOS 15.7.8 (
24G824) - Time zone: Asia/Shanghai (
UTC+8) - Primary model:
gpt-5.6-sol - Reasoning effort: mostly
medium - Weekly rate-limit window:
10080minutes
Relevant timeline
All times are August 1, 2026, in UTC+8.
| Time | Weekly usage | Observation |
|---|---:|---|
| 11:17 | 32% | Old weekly window still active |
| 11:48:34 | 0% | Reset first observed |
| 11:48:48 | 0% | New reset timestamp stabilized |
| 12:03 | 3% | Normal increase |
| 13:27 | 8% | Large task close to completion |
| 14:57 | 12% | Delayed increase |
| 16:02 | 16% | Last local model request |
| 16:02-21:26 | — | No local token_count events |
| 21:26 | 75% | First request after idle period |
| 21:27 | 74% | Percentage briefly moved backward |
| 21:39 | 75% | Returned to 75% |
| Later | 75-76% | Continued fluctuating between snapshots |
The server-reported weekly reset timestamp changed from 1786119217 to 1786160911. The latter corresponds to August 8, 2026, at 11:48:31 UTC+8.
Sanitized evidence
Last request before the idle period:
{
"timestamp": "2026-08-01T08:02:04.053Z",
"used_percent": 16.0,
"window_minutes": 10080,
"resets_at": 1786160911,
"last_total_tokens": 36048
}
First request after the idle period:
{
"timestamp": "2026-08-01T13:26:07.693Z",
"used_percent": 75.0,
"window_minutes": 10080,
"resets_at": 1786160911,
"last_total_tokens": 23833
}
Largest task after the reset
The largest task ran from approximately 13:01 to 13:29 using gpt-5.6-sol:
Model calls: 81
Command/tool calls: 67
Total raw tokens: 9,885,834
Input tokens: 9,857,878
Cached input tokens: 9,626,368
Uncached input: 231,510
Output tokens: 27,956
Maximum turn context: 174,064
Using the published GPT-5.6 Sol token rates, this represents approximately 170.24 credits. The task may explain much of the eventual usage, but the UI showed only 8% while it was running, 16% several hours later, and then 75% after another five-hour delay without indicating pending usage.
Four automatic codex-auto-review approval/guardian tasks also appeared in local records, with 1,159,722 combined raw tokens. Please confirm whether internal automatic tasks count against the weekly allowance.
Requested investigation
Please inspect the server-side usage ledger and:
- Identify the tasks, models, token categories, and credit amounts responsible for the change from 16% to 75%.
- Confirm whether the large 13:01 task was settled several hours after completion.
- Confirm whether internal
codex-auto-reviewapproval/guardian tasks consume the weekly allowance. - Explain why
used_percentbriefly moved backward from 75% to 74%. - Confirm why
resets_atchanged from 00:13 to 11:48. - Check for duplicate attribution or incorrect rate limiting.
- Restore any incorrectly consumed allowance if the ledger does not match legitimate activity.
- Consider exposing pending and per-task credit usage in the Usage panel.
Relevant task/thread ID:
019fbbb2-690d-7451-bc84-a76251cfe625
I can provide complete session logs privately. I have not attached them publicly because they contain prompts, local paths, command output, approval requests, and tool responses.
What steps can reproduce the bug?
This issue is not reliably reproducible on demand because the abnormal increase appears to involve delayed server-side usage reconciliation. These are the observed steps:
- Use ChatGPT — Powered by Codex & OWL, desktop app version
26.727.51351, with a ChatGPT Plus account. - Wait for the weekly Codex allowance to reset. The local logs first showed the reset at 11:48 UTC+8, changing from 32% used to 0% used.
- Run a long
gpt-5.6-soltask with repeated tool calls and a growing context. The relevant task ran from approximately 13:01 to 13:29 and recorded 9,885,834 raw tokens, mostly cached input. - Observe that weekly usage reaches 8% near task completion and later reaches 16% at 16:02.
- Leave the desktop app idle. In this case there were no local
token_countevents between 16:02 and 21:26. - Send one new request at 21:26. That request used 23,833 raw tokens, but its first server response reported 75% weekly usage.
- Observe that the reported value can briefly move backward, from 75% to 74%, before returning to 75%.
Expected result: completed-task usage should be reflected promptly and consistently, or the Usage panel should show that additional usage is pending reconciliation.
Actual result: weekly usage appeared to jump by 59 percentage points during a five-hour period with no local model activity, becoming visible only when the next request was sent.
What is the expected behavior?
After the weekly allowance resets, usage should return to approximately 0% and subsequent changes should correspond to completed activity from the account.
For long-running tasks, usage should be reflected promptly after task completion. If final usage is still being calculated or reconciled, the ChatGPT desktop app should clearly display that usage is pending instead of showing a substantially lower percentage for several hours.
The reported percentage should also be monotonic within the same weekly window. It should not move backward from 75% to 74% unless the service intentionally restores allowance and communicates that adjustment.
The Usage panel should provide enough detail to understand large changes, including:
- Task or session responsible for the usage
- Model used
- Uncached input, cached input, and output tokens
- Calculated credits
- Usage from internal automatic approval/guardian processes
- Usage contributed by other products sharing the same agentic allowance
- Pending or delayed usage that has not yet been reflected in the displayed percentage
Expected result for this incident: after the final local request at 16:02 showed 16% used, the displayed value should either have already included all completed-task usage or clearly indicated that additional usage was pending. The next small request at 21:26 should not have been the first point at which a 75% value became visible without an itemized explanation.
Additional information
Product information
- Product: ChatGPT — Powered by Codex & OWL
- Platform: ChatGPT desktop app
- App version:
26.727.51351 - App build:
6119 - Plan: ChatGPT Plus
- Operating system: macOS 15.7.8 (
24G824) - Time zone: Asia/Shanghai (
UTC+8) - Primary model:
gpt-5.6-sol - Reasoning effort: mostly
medium
All affected activity was performed exclusively in this desktop app.
Relevant identifiers
- Largest task/thread ID:
019fbbb2-690d-7451-bc84-a76251cfe625 - Stable new weekly
resets_at:1786160911 - Previous
resets_at:1786119217 - Rate-limit window:
10080minutes
The largest post-reset task recorded 9,885,834 raw tokens, including 9,626,368 cached input tokens. Using the published GPT-5.6 Sol token rates, its estimated weighted usage is approximately 170.24 credits.
Four automatic codex-auto-review approval/guardian tasks also appeared in local records, with 1,159,722 combined raw tokens. These were not user-created subagents. Please confirm whether their usage was charged to the weekly allowance.
I have sanitized rate-limit evidence available, including the 16% event at 16:02 and the 75% event at 21:26. I can provide complete JSONL session logs and local database evidence through a private OpenAI support channel if required.
I have intentionally not attached complete logs to this public issue because they contain prompts, local file paths, command output, approval requests, and tool responses.
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action