Repository navigation
[Windows][Pro 20x] Weekly usage display jumped 60%→97% while reset timestamp changed #44210
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Exact app version was not captured in the bounded evidence collection yet. The account is using Codex on Windows; I can provide the exact version in a follow-up if needed.
What subscription do you have?
ChatGPT Pro (20x)
What platform is your computer?
Windows 11 Pro x64
What issue are you seeing?
On September 9, 2026, my displayed primary Codex weekly usage changed from 60% used to 97% used, a difference of 37 percentage points (40% remaining → 3% remaining).
Both observations were for limitId=codex with a 10,080-minute (7-day) window.
The later observation is timestamped exactly:
- 2026-09-09 19:03:50.718 Europe/Paris (CEST)
- 2026-09-09 17:03:50.718 UTC
- weekly usage: 97% used
- displayed reset: 2026-09-11 09:49:52 Europe/Paris
The earlier preserved observation shows:
- weekly usage: 60% used
- displayed reset: 2026-09-15 08:12:33 Europe/Paris
- exact timestamp of this earlier observation was not recovered during the bounded evidence search
The important additional anomaly is that the displayed weekly reset date/time also changed, from Sep 15 08:12:33 to Sep 11 09:49:52 Paris time.
Because both the percentage and the reset timestamp changed, I am reporting this conservatively as an unexpected weekly quota-state / reconciliation change. I am not claiming that my Codex workload necessarily consumed 37 percentage points during the interval.
No causal investigation or reproduction experiment was started after noticing the anomaly. Existing work was paused and only bounded collection of already-existing evidence was requested.
What steps can reproduce the bug?
I do not currently have a deterministic reproduction.
Observed sequence:
- A preserved Codex rate-limit response showed 60% weekly used,
limitId=codex, 10,080-minute window, with reset 2026-09-15 08:12:33 Europe/Paris. - Existing Codex work was active later on Sep 9. The documented activity near the anomaly was:
- CT01 Operator: six ticks between 18:42:51 and 18:55:21 Europe/Paris, consisting of reads and review preparation. Model not verified in the preserved evidence.
- CT02 Navigator: document preparation between 18:38:06 and 18:53:21 Europe/Paris, about 15 minutes. Model not verified in the preserved evidence.
- CSK4: review transfer refused; no new turn accepted. Model not verified.
- Correcteur T08: inactive; last admission ended at 18:22:45 Europe/Paris; model verified as
gpt-5.6-sol / high.
- No new candidate, corrector, or run was created during this documented activity. This does not exclude usage elsewhere on the same account.
- At 2026-09-09 19:03:50.718 Europe/Paris / 17:03:50.718 UTC, the same primary Codex weekly limit was observed at 97% used, with reset 2026-09-11 09:49:52 Europe/Paris.
- The workload was paused and evidence was preserved rather than attempting to reproduce the event.
The preserved record for the 97% observation is:
ctco_01a08720-37be-71d1-8a9f-39a4cd4e51c7
This identifier is included only as a local evidence reference. I can provide account/session-specific identifiers privately if maintainers need them.
What is the expected behavior?
The weekly usage state and its reset timestamp should be internally consistent and auditable.
If 37 percentage points of allowance were legitimately charged during the relevant interval, there should be enough server-side attribution to identify which product surface, tasks/models, background activity, retries, subagents, or other quota-bearing work produced that change.
If the change instead resulted from a reset event, window re-anchoring, entitlement transition, delayed reconciliation, UI/backend desynchronization, or another account-state change, that event should be visible and explain why both the percentage and reset timestamp changed.
Please reconcile the server-side usage/rate-limit ledger for this account and timestamp range. If the investigation finds incorrectly attributed or incorrectly reconciled usage, please restore the affected allowance.
Additional information
This is a ChatGPT Pro 20x account on Windows.
Cause is currently unknown. No causal investigation has been launched and the workload remains paused.
Potentially related reports / tracker:
- [Meta] Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker #41220 — Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker
- Weekly Codex quota reset/reconciliation appears broken — quota exhausted with no local activity #42660 — Weekly Codex quota reset/reconciliation appears broken — quota exhausted with no local activity
- Weekly usage % jumps 18pp when plan_type flips pro -> prolite despite only 26M tokens #21216 — Weekly usage % jumps when rate-limit/account state changes
- Weekly reset timestamp appears stale after Sep 7 global Codex reset #44201 — Weekly reset timestamp appears stale after recent global reset
I am deliberately not attributing this to any specific task or model without server-side reconciliation. The key verified facts are the 60% → 97% displayed weekly usage change and the simultaneous Sep 15 → Sep 11 displayed reset-time change on the same 7-day Codex limit.
Activity
github-actions commentedon Sep 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Hannark commentedon Sep 9, 2026
Passive forensic follow-up
Passive inspection of existing local records on 2026-09-09 found the main Codex weekly quota at 60% used at 16:53:21.727 UTC (18:53:21.727 Europe/Paris), followed by 96% used at 17:01:34.578 UTC (19:01:34.578 Europe/Paris): a 36-percentage-point change between consecutive observations 8m12.851s apart.
No intermediate local quota state from 61% through 95% was found in the examined interval.
At the same time,
resets_atchanged from1789452752to1789112992, moving earlier by 339,760 seconds (~3d22h22m40s) without resetting usage to zero. The window remained 10,080 minutes andplan_typeremained "pro".The first explicit 97% result was recorded at 17:02:49.748 UTC. A native
token_countrecord only 8 ms later still showed 96%, followed by 97% again. Therefore, local record timestamps cannot safely be assumed to represent the exact server publication order.Local activity around the anomaly included:
gpt-6-astra / highgpt-6-astra / highgpt-6-astra / lowgpt-5.6-sol / high, inactive before the critical intervalcodex-auto-review / lowThe records also contain substantial token activity, much of it cached, but the available local evidence does not provide a reliable
response_id-deduplicated token total for this interval. We therefore cannot attribute the quota change to these activities.Please investigate whether this reflects:
No reproduction attempt, banked reset, paid reset, credit purchase, or intentional workload restart was performed after the anomaly was detected.
Environment:
26.903.8094.0, x6426200.9168The workload and monitors remain paused while the issue is investigated.
Tbagz123 commentedon Sep 9, 2026
补充一个 macOS 上同日出现的相同症状：周额度百分比和重置时间同时跳变。以下为脱敏后的独立观测。
环境：ChatGPT 桌面 App / Codex，App 26.901.51231（build 8109），内置 codex-cli 0.153.4，macOS 26.6.2 arm64，ChatGPT Pro（接口返回
plan_type: pro）。两条受查会话的配置记录均为gpt-6-astra、effort: max。以下均为 UTC，A / B 是匿名任务代号。所有快照都对应
limit_id: codex，primary.window_minutes: 10080（7 天）。任务 A 的两个相邻快照相差 18.802 秒，已用额度从 7% 变为 48%，即剩余从 93% 变为 52%。同一时段内，任务 B 也记录到了相同的两组状态。
同时，重置时间从 2026-09-16 15:22:31 UTC（1789572151）变为 2026-09-14 06:41:40 UTC（1789368100），提前约 56 小时 41 分钟。
稍后的账户额度接口返回
usedPercent: 49、windowDurationMins: 10080、resetsAt: 1789368101，与界面显示剩余 51% 一致；该接口与会话快照的重置时间相差 1 秒。这是从现存会话事件与额度接口读取到的状态变化，目前没有确定性的复现步骤。当时有多个任务在运行，尚未取得服务端逐任务用量与窗口变更账本，因此这些记录不能证明某个任务在上述 18.802 秒内消耗了 41 个百分点，也不能证明具体是哪一层出错。
请协助核对 2026-09-09 17:05–17:21 UTC 附近的额度窗口、重置/对账或计量状态变化，解释为何相同
limit_id的百分比和重置时间一起改变；如果确认存在错误计量或归属，请修复并恢复受影响额度。脱敏说明：只保留版本、公开模型 ID、额度字段和必要时间戳。已移除账号/用户标识、邮箱、任务真实名称与 ID、本机路径、组织/项目名称、内部链接、提示词及业务内容；未附加原始会话日志、截图、认证信息或诊断包。
VLFYNORW commentedon Sep 9, 2026
Additional affected account on macOS / ChatGPT Pro, with the same simultaneous weekly-quota and reset-date change on September 9, 2026.
The displayed remaining allowance fell from 74% to 14% within a few minutes. Two consecutive rate-limit snapshots from the same local Codex rollout narrow the abrupt part of the change to 73% remaining → 14% remaining, 7.243 seconds apart.
Environment
26.903.61454, build8378, verified from the installed app bundle after the event.0.153.4.26.5.2(build25F84), Apple Silicon (arm64).plan_type: "pro".gpt-6-astra, reasoning effortmax.Recorded evidence
These are server-provided values from
event_msg/token_count/rate_limits, not estimates calculated from raw token totals.All three snapshots report the same
limit_id: "codex",window_minutes: 10080, andplan_type: "pro".The last two snapshots contain:
{ "before": { "timestamp": "2026-09-09T17:11:25.147Z", "used_percent": 27, "resets_at": 1789560735 }, "after": { "timestamp": "2026-09-09T17:11:32.390Z", "used_percent": 86, "resets_at": 1789189986 } }A subsequent read-only account query still reported 86% used and the September 12 reset date. The diagnostic session did not redeem a reset or change account settings.
Requested investigation
There was ongoing Codex work, so this is not a claim of zero activity or proof of an incorrect charge. The specific anomaly is a 59-percentage-point increase in used allowance between consecutive snapshots, while the weekly reset moves from September 16 to September 12.
Please check the server-side usage ledger and reset history for this interval, explain why both values changed together, and restore the affected allowance if the reconciliation was incorrect. I do not have a deterministic reproduction.
The original evidence is retained locally. This public report omits account identifiers, session identifiers, private paths, prompts, conversation contents, and client/project data. This appears related to the September 9 reports in #44218 and #44213 as well as the reset-date change described in this issue.
Hannark commentedon Sep 9, 2026
Recovery confirmed on affected account
The account has now returned to a state consistent with the pre-anomaly weekly quota window.
Earliest confirmed recovery observation:
At that point, the Usage UI showed:
This closely matches the pre-anomaly state:
No banked reset, paid reset, or credit purchase was used to produce this recovery.
The fact that both the weekly percentage and the reset anchor returned together to essentially their prior values strongly suggests that the transient 36–37 percentage-point loss was not a durable consumption event on this account. However, the exact backend mechanism is still unknown, so I am not attributing it to a specific cause (display-only bug, deferred reconciliation, entitlement/window state, or other accounting issue).
For this account, the user-visible state is now back to normal. The issue should remain useful for correlating the underlying service-side cause and the similar independent reports already attached here.
sxxkchan commentedon Sep 9, 2026
Additional independent Windows case: weekly remaining switched to another reset window, then returned
I observed the same quota-window oscillation on Codex Desktop for Windows. The values below are server-provided
account/rateLimits/read/ rollout rate-limit snapshots for the exact account-widelimit_id=codexbucket withwindowDurationMins=10080; they are not percentages inferred from local token totals.Environment
26.903.8094.0, x6426200planType: proliteRecorded timeline
resetsAtThe user also watched the Codex Usage UI reach approximately 100% remaining and then decrease through 97% and 94%. The UI later returned to the original Sep 15 reset window and displayed 54% remaining, matching the account API.
There was substantial real Codex activity during part of the interval: two concurrent local Codex sessions emitted 140
token_countevents and approximately 23.10M processed tokens from 02:30-03:29 KST, with about 97.9% of input tokens reported as cached input. I therefore do not claim zero legitimate consumption. However, the processed-token activity does not explain why the weekly reset anchor changed from Sep 15 to Sep 14 and then returned to the exact prior Sep 15 anchor. The temporary 97%-94% remaining state and the later 59%-54% state belong to different server-reported reset anchors and should not be interpreted as one continuous 35-point consumption sequence.This was not a local third-party display-only issue: both the Codex UI and the server-provided rate-limit snapshots showed the alternate state. The account and device association remained unchanged in the local ledger, and all three reset credits remained available.
Please correlate the server-side quota ledger around 2026-09-09 16:50-19:10 UTC and determine whether this was stale quota-window state, replica/cache inconsistency, entitlement reconciliation, or another accounting transition. If any allowance was incorrectly reconciled, please restore it. Sanitized timestamped evidence is retained locally; account IDs, email, session IDs, prompts, project names, local paths, and authentication data are intentionally omitted from this public comment.
sxxkchan commentedon Sep 9, 2026
In-app /feedback was also submitted for this independent case.
Feedback/session ID: 01a05208-ecad-7573-9870-be9a0441cfce
Please correlate this session with the server-side weekly codex rate-limit window oscillation described in my earlier comment.
dterenyi commentedon Sep 9, 2026
Adding independent Windows Desktop / Pro 20x evidence from the same September 9, 2026 interval. I observed 66% → 75% → 66% weekly remaining in the UI. The recorded equivalent sequence is 66% → 75% → 74% → 66%. The percentage and reset timestamp switched together, and the original pair returned within the same Astra task.
This complements the original reporter's recovery update and the independent Windows case already attached here. My remaining allowance temporarily increased before returning to its original state. The useful common observation is that the weekly percentage and reset timestamp changed together and later returned; a common internal cause has not been established.
The 66% reading was already after the September 7 global reset I had observed. Earlier Sol tasks showed 66%; the upward change appeared after starting an Astra task. This is a single observed occurrence, with a return to the original state, rather than a deterministic reproduction.
Environment
plan_type: pro.10.0.26200, x64.0.153.4in the relevant task log. Installed Windows app package checked during investigation:26.903.8094.0.gpt-5.6-sol. During all four observations below:gpt-6-astra, reasoningxhigh. Fast setting was not established by the retained metadata.Recorded sequence
All four rows below are from
event_msg/token_countrecords in one Desktop task log. Every row haslimit_id: codex,plan_type: pro, primarywindow_minutes: 10080, and secondarynull. Remaining is calculated as100 - used_percent; the intermediate 74% is established by the log.The two
resets_atvalues are1789435611and1789353112, separated by 22 hours, 54 minutes, 59 seconds. Both were still in the future during these observations. The earlier reset timestamp appeared with the higher remaining allowance; the later timestamp then returned with the original 66% remaining value.Minimal log projection
These are selected fields copied from the four events, with the enclosing event metadata and unrelated fields omitted. They are not complete raw logs.
{"timestamp":"2026-09-09T16:52:04.217Z","rate_limits":{"limit_id":"codex","plan_type":"pro","primary":{"used_percent":34.0,"window_minutes":10080,"resets_at":1789435611},"secondary":null}} {"timestamp":"2026-09-09T16:57:17.765Z","rate_limits":{"limit_id":"codex","plan_type":"pro","primary":{"used_percent":25.0,"window_minutes":10080,"resets_at":1789353112},"secondary":null}} {"timestamp":"2026-09-09T17:27:17.791Z","rate_limits":{"limit_id":"codex","plan_type":"pro","primary":{"used_percent":26.0,"window_minutes":10080,"resets_at":1789353112},"secondary":null}} {"timestamp":"2026-09-09T17:41:17.488Z","rate_limits":{"limit_id":"codex","plan_type":"pro","primary":{"used_percent":34.0,"window_minutes":10080,"resets_at":1789435611},"secondary":null}}An existing local usage monitor independently recorded
account/rateLimits/readsnapshots around the Astra turn: 34% used with reset1789435611at the beginning, and 25% used with reset1789353112at the end. Both snapshots were marked as app server reads, with no rollout fallback. That monitor uses a separately installed CLI, so the Desktop task events above are the primary evidence.The monitor history had already recorded both reset anchors before September 9: reset
1789353112with 0% used by September 7 at 02:32:19 UTC, and reset1789435611with 0% used by September 8 at 01:30:46 UTC. These are observation times, not verified reset application times. This may help investigate why an earlier quota state resurfaced.Interpretation and expected behavior
The evidence establishes alternating quota snapshots in recorded data, beyond the visible percentage changing. It does not establish which state was authoritative, whether starting Astra caused the switch, or whether the cause was server accounting, caching, or selection among quota sources. No extra usable allowance or permanent credit can be inferred from this sequence. I did not capture a server reset ledger or account identity fields for these events.
Please investigate why the same labeled weekly limit returned these two percentage and reset pairs in one task. The displayed allowance should consistently identify its quota source and window, and explain legitimate changes to that state.
This excerpt contains only usage metadata. Prompts, responses, tool output, organizational data, local paths, credentials, account identifiers, and task identifiers are excluded.
Further comparison and incident context (September 9)
Checking the immediately preceding log entries narrows the two switches:
16:56:06.414 UTC: 34% used, reset1789435611;16:57:17.765 UTC: 25% used, reset1789353112. Interval: 71.351 seconds.17:40:23.033 UTC: 26% used, reset1789353112;17:41:17.488 UTC: 34% used, reset1789435611. Interval: 54.455 seconds.The model remained Astra in both pairs, and cumulative token counters increased across each pair. These observations do not support assigning the abrupt changes to switching models or estimating a quota cost from the token counts. HTTP quota headers were not available in the retained diagnostic database for this interval.
#44251 adds HTTP headers showing an older reset window resurfacing after the global reset and then reverting. Its changed and restored readings at
17:11:11and17:39:58 UTCon September 9 (September 10 KST) fall inside my interval from16:57:17.765to17:41:17.488 UTC, about 44 minutes. My observations came from one Astra Desktop task and involved September 15 and September 14 reset timestamps. This provides an independent account observation with temporal overlap.OpenAI's unexpected usage limit resets incident was published at
17:29:55 UTC, marked as mitigated/monitoring at17:45:25 UTC, and resolved at17:54:12 UTC. My return to the original state was recorded during that incident timeline. A connection is plausible but has not been confirmed for this account.In a bounded check after the resolution notice, all 87 retained local quota snapshots from
17:54:25.677through18:23:27.827 UTCused reset1789435611, with used percentage ranging from 34 to 36. That sample shows no recurrence after the notice; it does not establish complete account accounting or permanent resolution.Relevance of the bot suggestions
Comparison with the five suggestions in #44251:
Also related: #44251 (HTTP headers and overlapping UTC interval), #44264 (macOS Pro reversal), and #31696 (earlier July symptoms). These are symptom comparisons; shared causes and duplicate status remain unconfirmed.
vbzgn2rc98-ctrl commentedon Sep 10, 2026
Another independent ChatGPT Pro 20x datapoint.
I am also seeing a large reduction in effective weekly Codex capacity. Under my historical heavy Codex workload (primarily Sol-era usage), a full weekly allowance corresponded to roughly 5–6B activity tokens. Recently, the same account appears closer to roughly 1–1.4B activity tokens per full weekly allowance, with materially less engineering throughput per 1% of weekly quota.
One recent interval showed roughly 400–450M total activity tokens while weekly remaining moved from 48% to 7%. I am aware of the Sep 9 unexpected usage-limit/reset incident, so I am not treating that single interval as a clean proof of consumption. The broader capacity drop is based on repeated heavy-use observations over time.
My main concern is whether the server-side Pro 20x entitlement / weekly quota bucket / usage multiplier is currently being provisioned or reconciled incorrectly, potentially closer to a lower-tier / 5x-equivalent allowance. Simply switching models would not explain or resolve that if the underlying account bucket itself is wrong.
Could the team please verify the actual backend entitlement and quota ledger for affected Pro 20x accounts, rather than only confirming that the subscription UI says Pro/20x?
Potentially related historical reports: #38157 and #38367.