[Codex Desktop][Windows] Weekly quota jumped 67 points in 38 seconds (Oct 16, 2026; 18:10 UTC)

Summary

New evidence from local Codex logs: On October 16, 2026, the remaining WEEKLY Codex allowance dropped from 77% at 21:10:43 to 10% at 21:11:21 Moscow time (UTC+3) — 67 percentage points in 38 seconds. According to a Codex-assisted inspection of local logs, token counters rose by only 380,821 tokens between these two records, including 373,120 cached-input tokens (~98% of the increment). The weekly reset timestamp did not change.

This is a significant unexplained quota-meter discontinuity. It does not by itself prove that the backend billed those 380,821 tokens incorrectly: delayed posting of previous requests, usage outside the inspected local sessions, weighting, and reconciliation must all be checked against server-side records. The underlying raw log excerpts have not yet been attached to this public issue.

My remaining weekly quota later reached 6%, leaving development effectively blocked. This concerns the weekly allowance, not a five-hour window.

Revised timeline

The initial report relied on the times when the drop was noticed in the UI. The following more precise local-log timestamps supersede the initial inferred 21:16 start time.

Oct 16, Moscow time (UTC+3)	Weekly allowance remaining	Evidence
20:14	79%	Local Codex log summary
21:10:43	77%	Local Codex log summary
21:11:21	10%	Local Codex log summary — 67-point drop in 38 s
~21:26	8%	Initially observed UI value
~22:33	6%	Local Codex log summary, consistent with Support's 94% used / 6% remaining

Critical interval for backend correlation: 18:10:43–18:11:21 UTC on October 16, 2026. Also examine the preceding hours for delayed or batch usage postings and the later period through 19:33 UTC.

Token counts reported by local Codex inspection

At approximately 22:35 Moscow time on October 16, local logs were summarized as:

Total tokens recorded that day: ~83.16 million
Cached input: ~80.91 million
Noncached input: ~1.97 million
Model output (including reasoning): ~278,000

Between the two critical quota snapshots (21:10:43 → 21:11:21):

Total increment: 380,821 tokens
Cached input within that increment: 373,120 tokens
Other tokens in that increment: 7,701
Weekly allowance remaining: 77% → 10%
Weekly reset timestamp: unchanged

These are figures transcribed from a Codex-generated analysis of local logs, not independently authenticated here; server-side reconciliation is necessary. The daily aggregate should not be confused with the much smaller 38-second delta or interpreted as a direct quota-cost calculation.

Environment

Surface: Codex Desktop on Windows
Subscription: paid ChatGPT plan with Codex access
Affected quota: weekly Codex usage allowance
App build, exact model/reasoning/speed during the interval: not confirmed here; please obtain those details from server-side request records.

Previous similar incident

In September 2026, I experienced a similar sudden quota drop which recovered automatically within about 15 minutes. This October 16 event has not recovered within that time frame and interrupted work.

The event followed the global Codex reset announced for October 15. This temporal proximity does not establish causality, but post-reset accounting/reconciliation should be examined.

Expected / actual

Expected: consistent, auditable weekly quota accounting correlated to requests and any background/cloud work.

Actual: 67 percentage points were deducted between two local quota snapshots separated by 38 seconds, despite only a 380,821-token increment across the locally inspected counters; the weekly reset timestamp stayed unchanged. The eventual remainder was 6%.

Requested investigation

Prioritize the specific server-side window 2026-10-16 18:10:43–18:11:21 UTC, and examine earlier activity for delayed/batched deductions.
Reconcile each quota-meter change with backend request/session IDs, tokens (cached/uncached/output), models, reasoning/speed tiers, subagents, retries, cloud/background work, and weighting.
Determine whether there was a batch posting, accounting correction, duplication, entitlement change or metering defect; identify the exact activity or correction accounting for the 67-point jump.
Explain why the weekly reset timestamp remained constant and why quota did not automatically recover as it did during the earlier September event.
Correct any verified erroneous deduction or provide a remedy restoring access without consuming the account's two available rate-limit reset credits.
Check whether similar concurrent reports reflect a common event; do not assume this without checking backend evidence.

OpenAI Support confirmed the account displayed 94% weekly used / 6% remaining. A private Support case has already been escalated. This public report contains no private account identifiers.

Related reports

[Codex app][Windows][Pro] Weekly quota jumped 14% to 88% used in one server update; 98.1% cached Astra telemetry #44213 — server-reported quota discontinuity
Weekly allowance drops unexpectedly with GPT-6 Astra High at Standard speed on a $500 account #52530 — sharp weekly quota decline
[Meta] Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker #41220 — cross-report tracker of quota and accounting inconsistencies

Please investigate the local-log discrepancy and provide server-side attribution, rather than treating the meter reading alone as proof of ordinary consumption.

Potentially contemporaneous Reddit report (October 16, 2026)

A separate user reported an abrupt Codex usage drop from 57% remaining to 0%:

https://www.reddit.com/r/codex/comments/1x7obzw/codex_usage_dropped_from_57_remaining_to_0/

The report was described as occurring at approximately 21:09:10–21:09:13 Moscow time (18:09:10–18:09:13 UTC) on October 16 — about 7 minutes before the start of my observed 21:16–21:31 Moscow time (18:16–18:31 UTC) incident. Another participant reportedly described a drop from 68% remaining to zero.

These are third-party, user-reported observations, not independently verified server-side telemetry and not proof of a common cause. The Reddit page could not be independently re-opened during this update; please verify the exact timestamps and details against the original post.

Request: Please check whether quota accounting, delayed deductions, or a shared service event affected multiple accounts around 18:09–18:31 UTC on October 16, 2026. My own documented drop remains 79% → 8% → 6% weekly allowance remaining.

New forensic evidence — October 16, 2026 (correction to initial approximate timeline)

A subsequent Codex-assisted local-log inspection placed the critical weekly quota discontinuity earlier than first noticed:

21:10:43 MSK / 18:10:43 UTC: 77% weekly remaining
21:11:21 MSK / 18:11:21 UTC: 10% weekly remaining
67 percentage points gone in 38 seconds
Local token-counter increase between these two records: 380,821 total, of which 373,120 cached input
Weekly reset timestamp: unchanged
Daily recorded totals by ~22:35 MSK: ~83.16M tokens, including ~80.91M cached input, ~1.97M uncached input, ~278k output/reasoning.

The original ~21:16–21:31 report referred to when the change was noticed; 18:10:43–18:11:21 UTC is now the primary investigation window. The issue body has been updated accordingly.

These numbers are from a Codex-generated summary of local logs, not independently authenticated server data. They establish a discontinuity between reported quota and nearby locally observed token counters, not proof of incorrect billing. Please reconcile possible deferred/aggregated posting, other active sessions or subagents, model weighting, and any accounting correction against backend ledger events before concluding it was legitimate usage.

Can confirm this, went from 35% to zero within seconds. I had been monitoring my quota every couple minutes and it was being consumed at a normal pace before this abrupt fall. Not specific to the desktop app.

Adding another account's local observations from October 16, 2026. My Codex weekly usage went from 46% used to 100% used, with the first exhausted snapshot recorded during the same time window reported here.

Recorded time (UTC)	Weekly used	Weekly remaining
2026-10-16 17:46:24.801	46%	54%
2026-10-16 18:10:48.116	100%	0%

These are the last pre-jump and first exhausted snapshots found in the inspected local logs, about 24 minutes apart. I cannot claim that the entire 54-point increase happened within seconds.

The allowance bucket, seven-day window, weekly reset timestamp, and reported plan type were unchanged between these snapshots.

A Codex-assisted inspection of the available local records found one model-response sample in that interval, at 18:10:48.116 UTC: 112,264 input tokens, including 109,056 cached input (3,208 uncached), and 139 output tokens. Two subsequent responses in the same turn were recorded after the meter had already reached 100%. The inspected records did not show a runaway retry or concurrency spike.

This is local evidence, not a complete account-wide usage ledger. It cannot exclude other devices, cloud activity, delayed accounting, model weighting, or stale quota snapshots. The token counts alone do not establish what percentage should have been charged.

Credits subsequently began decreasing; the first decrease in the inspected records was at 18:26:17.114 UTC. No banked reset was used during the investigation.

Please correlate this with the other reports around 18:09–18:12 UTC and check the server-side ledger for delayed deductions, entitlement recalculation, duplicate charges, or a metering defect. If the deductions were incorrect, please restore the affected allowance and any incorrectly charged credits.

Adding another affected account's observations, this time from Codex Desktop on macOS, with two Linux execution hosts checked as well.

My last recorded pre-exhaustion snapshot showed 62% remaining (38% used). The next captured snapshot showed 0% remaining (100% used):

Timestamp (UTC)	Source	Weekly used	Weekly remaining
2026-10-16 05:13:08.124	Linux execution host	37%	63%
2026-10-16 05:27:59.704	Mac	38%	62%
2026-10-17 01:03:28.523	Mac	100%	0%

These snapshots bound an unexplained 62-percentage-point increase. They do not establish the exact moment of the change or that it happened within seconds. The other reports' October 16 18:09–18:12 UTC cluster falls inside my interval, so backend correlation would be useful.

Between the 38% and 100% snapshots:

Limit ID remained codex.
Reported plan identifier remained prolite.
Window duration remained 10080 minutes (seven days).
Reset timestamps were 1792649589 and 1792649590, a one-second difference.
The reported credit balance was exactly unchanged.

A Codex-assisted inspection checked the Mac and both Linux hosts, verified that they used the same account, and reviewed session records, goals, and available diagnostic logs:

Neither Linux host's inspected standard Codex session store recorded further model execution after the final Mac 38% snapshot.
The Mac showed brief internal model activity around 2026-10-16 05:28:03–05:28:07 UTC and 2026-10-17 00:58:47–00:58:48 UTC, but no sustained recorded workload explaining the increase.
An earlier substantial Astra on-call goal was paused. Its final recorded usage snapshot was still 38%.
The inspected cloud on-call chat had stopped before this interval.

Support's AI subsequently identified credit-consumption entries around 2026-10-17 01:13–01:17 UTC. I was using a Sol diagnostic chat to investigate this issue and prepare the support submission then. Those entries occurred after the first captured 100% snapshot and therefore do not locate or explain the earlier weekly-meter change.

This is client-side evidence, not a complete account-wide ledger. It cannot exclude unobserved usage, delayed posting, weighting, stale snapshots, or entitlement recalculation, and it does not by itself prove incorrect billing. A private Support case has been escalated to a human.

Please correlate the account's server-side weekly-allowance ledger over 2026-10-16 05:27:59.704 UTC through 2026-10-17 01:03:28.523 UTC, especially the cluster reported here around 18:09–18:12 UTC. Please distinguish original request/execution times from posting or reconciliation times, identify what accounts for the 62-point increase, and correct any verified erroneous allowance deduction and subsequent credit charges.

Private account identifiers, exact credit balances, and raw transcripts are omitted from this public comment.

Adding another potentially contemporaneous report from Windows 11 / Codex Desktop (app version observed in local logs: 26.1013.31256). Posted with the affected user's explicit authorization.

Timeline (Asia/Shanghai, UTC+8):

2026-10-16 22:42:30: the last inspected local token_count event reported weekly used_percent = 27, window_minutes = 10080 (approximately 73% remaining).
On the morning of 2026-10-17, the user opened the computer and saw the WEEKLY allowance exhausted. This is the user's direct observation; we do not have a pre-reset 100% snapshot in the inspected local logs and cannot identify the exact moment of the drop.
2026-10-17 09:31: the account's usage-reset history confirms one banked reset was used to resume work. This is 2026-10-17 01:31 UTC.

Additional observations:

No entries were found in the inspected local Codex service log between 2026-10-16 23:00 and 2026-10-17 09:28 (UTC+8). This does not rule out cloud activity, shared account-level usage, or delayed posting of earlier consumption.
There WAS legitimate evening activity, including main chats, subagents and background memory processing. We are not claiming zero usage or converting local token totals directly into allowance cost.
When checked after the reset, the official usage analytics page warned that usage data may be stale and that some usage was unavailable/incomplete. The displayed weekly-history entry was only current as of October 13 UTC, so it could not reconcile this event.

The timing is compatible with the October 16 18:09–18:12 UTC reports linked in this issue (October 17 02:09–02:12 in our timezone), but a common cause has not been established.

Please investigate server-side quota accounting/entitlement changes and delayed deductions for this interval, explain whether these reports share a cause, and consider restoring the banked reset consumed because of this incident if an erroneous deduction is confirmed. No assumption is made here about a plan downgrade or the cause. This public comment intentionally omits account identifiers, raw logs and private project information.

Additional affected account: macOS / Codex via OpenClaw

Posting with the affected account holder's explicit authorization. Our saved local diagnostics show a weekly-allowance drop from 70% remaining to 0% across the following observations (all UTC):

2026-10-16 17:59:38: 70% weekly remaining.
2026-10-16 20:00:12: 0% weekly remaining.
2026-10-16 20:04:22: still 0% weekly remaining.
2026-10-16 20:27:09: 100% remaining after the account holder manually used a banked reset. This was not an automatic recovery.

These are the last pre-exhaustion and first exhausted snapshots found in the inspected records. They bound the change to roughly two hours; we cannot establish its exact time or claim it occurred within seconds. The 18:09–18:12 UTC cluster reported here falls within our interval, but a shared cause is unconfirmed. The observations concern the seven-day / 10,080-minute allowance, not the shorter usage window.

An initial inspection of ordinary conversation records missed internal background activity. A subsequent inspection found two internal memory-processing model completions at 18:01:52 and 18:02:12 UTC, with 5,577 and 4,462 tokens respectively (10,039 in total), as recorded in the local service completion logs. We therefore explicitly retract any inference of zero model activity during this interval. These local token counts are not a complete account-wide ledger and cannot be converted directly to a weekly-allowance percentage.

There was also legitimate usage outside this interval, including monitoring and the later investigation. We are not attributing all consumption to a defect or claiming that the inspected local records rule out other devices, background/cloud usage, delayed posting, model weighting, or stale quota observations.

Please reconcile server-side quota events for 2026-10-16 17:59:38–20:00:12 UTC, especially around 18:09–18:12 UTC. Please distinguish request/execution time from quota-posting or reconciliation time, identify the activity or adjustment responsible for the 70-point change, and determine whether these reports share a cause. If an erroneous deduction is confirmed, please restore the affected allowance and the banked reset used to regain access.

The figures above are transcribed from saved local diagnostic records, not independently authenticated backend accounting. Raw logs, account identifiers, local paths and credentials are not attached.

Adding evidence from my report, #54767, to consolidate it here. I saw a weekly allowance drop around the same time, followed by unusually fast allowance consumption after using a banked reset.

Environment: Linux, Codex Desktop, ChatGPT Pro; installed Codex CLI version 0.160.0. All times below are UTC, and the figures come from token_count and rate_limits entries in my local Codex logs.

On October 16, 2026, my remaining weekly allowance dropped from 48% at 18:01:16 to 0% at 18:10:32. Both snapshots had the same weekly reset timestamp.

Usage across my local work and review chats during that interval was:

Token type	Count
Cached input	8,466,304
Uncached input	30,402
Output	14,901
Total	8,511,607

This usage was all GPT-6.1 Sol, with 99.64% of input tokens cached. Automatic approval reviews accounted for another 1,630,548 tokens, listed separately.

After the drop and before the banked reset, my additional credit balance fell from 62,500 to 62,204.18291, a decrease of 295.81709 credits.

I then used one banked reset. By October 17 at 00:30:48, the logs showed 100% remaining. The following comparison shows usage before the incident and after that reset:

UTC interval	Weekly allowance remaining	Total tokens, including cached input	Input cache hit rate	Tokens per percentage point consumed
Oct 16, 12:49–17:00	56% → 49%	169,277,530	98.80%	24,182,504
Oct 17, 00:32–00:52	100% → 97%	7,775,073	96.69%	2,591,691
Oct 17, 00:32–01:10	100% → 94%	12,370,374	97.53%	2,061,729

The two post-reset rows overlap. On these raw token counts, allowance consumption per token was 9.33–11.73× higher after the reset.

Model usage for those intervals was:

UTC interval	GPT-6 Astra tokens	GPT-6.1 Sol tokens
Oct 16, 12:49–17:00	53,596,681	115,680,849
Oct 17, 00:32–00:52	7,775,073	0
Oct 17, 00:32–01:10	12,370,374	0

Automatic approval review usage is excluded from these tables: 46,803,685 tokens in the earlier interval and 739,706 tokens in the post-reset period.

I have also encountered the sudden weekly allowance exhaustion discussed here in Codex Desktop on Windows. Could the team confirm whether these reports reflect a known issue and share an official explanation or next steps for affected users?

Additional user report (as of 2026-10-17, UTC+08:00): My remaining Codex usage allowance suddenly dropped from approximately 40% to 0%. The change appeared abrupt, rather than a normal gradual reduction. I have also seen reports on X of apparently similar symptoms, although I cannot verify that these incidents share a cause.

Could the Codex team investigate whether server-side quota metering, delayed usage attribution, background activity, or reconciliation might explain the 40-percentage-point drop? In particular, please check whether this matches the Oct 16 quota discontinuities documented here and whether affected usage can be corrected if the deduction was erroneous.

I am not claiming the accounting error is confirmed. I can provide exact timestamps, the affected limit/window, screenshots, and account-identifying details privately through official OpenAI Support rather than in this public issue.

Additional account evidence

[Pro 5× / macOS] Reported weekly allowance exhaustion after a plan downgrade; 2.05× higher observed per-token depletion after a banked reset

Environment

Codex Desktop on macOS 27.0.1, arm64.
Relevant rollout metadata: 0.162.0-alpha.17.2 before the incident and 0.163.0-alpha.10.2 in new post-reset sessions. These are session metadata versions, not verified per-request runtime versions for resumed sessions.
Separately installed CLI at investigation time: codex-cli 0.162.1; desktop application version: Not available.
Main model: gpt-6-astra; comparison below uses high reasoning effort.
Times are UTC; corresponding China Standard Time is UTC+8.

Subscription plan

ChatGPT Pro $100/month, Pro 5× (plan_type: "prolite"). I downgraded from $200 Pro on October 8, 2026. I report that no other computers were running during the incident. This does not establish complete coverage of cloud, background, or shared Work usage.

Description

I noticed my weekly allowance fall from approximately 80% remaining to 0% around October 16–17. Afterward, I used one Full Banked Reset on the morning of October 17 (UTC+8) and perceived faster depletion.

The preserved local data does not contain the exhausted snapshot or establish the exact exhaustion time. Its last pre-reset reading is 65% remaining; the next reading is already 100%. I am reporting this gap explicitly rather than assigning my account the 18:08–18:14 UTC onset reported by other users.

Separately, comparable Astra/high intervals show 2.05× higher observed depletion per token after the reset. Historical speed data is incomplete, so this is an accounting investigation request, not a proven billing multiplier or a confirmed reset failure.

Steps to reproduce

Not reproducible on demand. The observed sequence was plan downgrade → later reported weekly exhaustion → banked reset → perceived faster depletion. No new model requests, stress tests, or reset redemptions were performed to reproduce this during the investigation.

Expected behavior

The weekly meter should be reconcilable with actual account-wide usage and applicable model/speed weights. Any entitlement adjustment should have an explainable effective time. A redeemed Full Banked Reset should durably grant the applicable refreshed allowance.

Actual behavior and timeline

UTC	UTC+8	Preserved observation
Oct 16 16:56:27.195	Oct 17 00:56:27.195	Last pre-reset snapshot: 65% remaining; Astra/high, `prolite` (E011702).
Between the adjacent preserved snapshots	Exact time unavailable	I report exhaustion and then a banked reset. There is no preserved 0% snapshot or redemption receipt.
Oct 17 04:43:29.082	Oct 17 12:43:29.082	First recovered snapshot: 100% remaining (E011703).
Oct 17 06:42:05.755	Oct 17 14:42:05.755	91% remaining (E011843).
Oct 17 14:15:21.590	Oct 17 22:15:21.590	87% remaining (E011866). No second exhaustion appears in the preserved post-reset data.

The last pre-reset and first recovered snapshots are 11 h 47 m 1.887 s apart. No token-response record appears strictly between them. The first recovered record itself contains 37,850 tokens; those cannot be attributed to the earlier exhaustion. Actual token usage at the exhaustion time is Not available, not proven zero.

The last visible local task completed at Oct 16 16:56:27.203 UTC; the next task started at Oct 17 04:43:20.625 UTC. Retained model-stream logs show no activity or matching reconnect/retry marker in the intervening 17:00–04:43 interval. This is limited local telemetry, not an account-wide inactivity proof.

Rate-limit snapshots

The relevant allowance is identified by 10,080 minutes, not by assuming that primary means a five-hour window. limit_id is codex; secondary is null. No five-hour snapshot was available.

Evidence	Weekly used	Weekly remaining	Weekly reset epoch	Plan
E011702	35%	65%	1792649585	prolite
E011703	0%	100%	1792817003	prolite
E011843	9%	91%	1792817005	prolite
E011866	13%	87%	1792817005	prolite

The old reset was Oct 22 06:13:05 UTC. The new reset stabilized near Oct 24 04:43:25 UTC, with a few seconds of timestamp jitter. Subtracting seven days suggests a new-window anchor around Oct 17 04:43:23–26 UTC; this is an inference about the window, not the redemption time. The window may start on first use after redemption.

Token usage evidence

These intervals use (start, end], exclude the response already counted at the starting snapshot, and aggregate all locally visible sessions within the interval.

Metric	Before: Oct 15 07:57:16.139–08:57:07.988	After: Oct 17 04:43:29.082–06:42:05.755
Model / reasoning	Astra / high	Astra / high
Evidence endpoints	E008959 → E009166	E011703 → E011843
Remaining allowance	99% → 93%	100% → 91%
Input, including cached	30,181,115	22,065,898
Cached input, subset of input	29,630,464	21,784,576
Uncached input	550,651	281,322
Output, including reasoning	32,623	41,887
Total	30,213,738	22,107,785
Input cache hit rate	98.1755%	98.7251%
Weekly percentage points per million tokens	0.198585	0.407096

The observed ratio is 2.05×. This remains 2.07× under a common Standard API-price reference normalization of the token mix. Using the official Astra Standard reference prices checked October 17 ($10 / $1 / $50 per million uncached input / cached input / output tokens), the intervals represent $36.768124 and $26.692146 respectively. This is $6.128021 versus $2.965794 per percentage point, or $612.80 versus $296.58 when linearly extrapolated to 100 points. These are conditional, common-price reference equivalents, not actual historical API charges or official subscription allowances. Actual tier-adjusted equivalents are Not available because earlier speed data is missing. No cache writes or >272k-input requests occur in these comparison intervals.

Crucially, the earlier interval has no surviving historical service-tier tags. In the later interval, 108 records have default tags and 32 lack tags. Model, reasoning, and cache structure are reasonably matched; speed mode, client version, workload, account-wide completeness, and settlement timing are not fully controlled. Integer meter resolution also limits precision. The last short pre-reset Astra/high segment recorded another 7,638,570 tokens while remaining at 65%, which could reflect quantization, stale snapshots, or delayed posting.

Full Reset behavior

The new window and recovered 100% reading are directly recorded and consistent with my reported reset. Subsequent local records show 100% → 87%, with no adjacent drop greater than one percentage point. There are 26,180,534 recorded post-reset tokens including the first recovered response, or 26,142,684 after that snapshot. Two local sessions overlap briefly after recovery and both are included.

I cannot establish a second discontinuity, a rollback to the exhausted balance, the exact redemption time, or an account-specific reduction in absolute allowance.

Related issues

#54677: sudden weekly-meter changes; recommended consolidation target.
#54704: Pro 5× with reset epoch 1792649598; another comment reports 1792649580. My pre-reset 1792649585 differs by only 13 and 5 seconds respectively. This is a specific correlation lead, not proof of a common cause or my onset time.
#54767: exhaustion plus faster post-reset usage; closed by its author as a duplicate of [Codex Desktop][Windows] Weekly quota jumped 67 points in 38 seconds (Oct 16, 2026; 18:10 UTC) #54677.
#54750: temporary recovery followed by exhaustion; that post-reset pattern is not present in my retained records.

As checked October 17, #54677, #54704, and #54750 are open; #54767 is closed as duplicate. The #54677 author relays an AI Support response about an allowance-denominator reduction on their account. This is not an engineering-confirmed root cause for my account or a confirmed fix.

Requested investigation

Please reconcile my account's absolute allowance and consumed units before/after the reported exhaustion, including any delayed entitlement recalculation following the October 8 downgrade. Check execution times versus posting times, all shared Work/Codex usage, actual model/speed weighting, duplicate/deferred charges, and the banked-reset redemption/application ledger. Please correct any verified accounting error or incorrectly consumed reset credit.

Diagnostic limitations and privacy

The read-only extraction contains 11,866 redacted token/rate snapshots from retained local rollouts, plus selected SQLite diagnostics. It excludes the investigation session. Cumulative counters were differenced once; repeated counters contribute zero, cached input is not added twice, and reasoning is not added again to output. Local histories are not the full account-wide usage ledger.

The attached evidence.csv contains only redacted diagnostic fields, with anonymous session/source labels, source line numbers, and selected-field hashes. A real-ID/path mapping is retained locally for a secure support channel. No authentication data, account IDs, prompts, private project names/paths, source code, private attachments, or complete raw JSONL files are included.

Redacted diagnostic attachment

evidence.csv — 11,866 diagnostic rows; 7,116,180 bytes.

SHA-256: 2b8b623a44f674e53613217f988825ae2203430abedd0f403c9bcfa34d7ff666.

Only this redacted CSV is attached. The private ID/path mapping and all original JSONL/SQLite logs remain local.

Full sanitized follow-up — quota cliff, credit spillover, banked reset, and post-reset capacity

Following up on my earlier macOS datapoint with the fuller evidence trail. I am intentionally omitting account IDs, exact credit balances, request/session IDs, local paths, project names, conversation contents, and raw transcripts.

1. Plan context

This account changed from Pro $200 to Pro $100 at the October 14 renewal. OpenAI currently describes Pro $100 as 5× Plus and Pro $200 as 20× Plus: https://help.openai.com/en/articles/9793128-about-chatgpt-pro-tiers

That plan change is relevant, but it does not by itself explain why the server-side allowance changed abruptly in the middle of an existing weekly window on October 16.

2. Sanitized local timeline

All times UTC.

2026-10-16 07:30–14:40
  legitimate OpenAI traffic observed by local proxy:
  2,483 requests
  294,115,130 total tokens
  282,710,528 cached-input tokens
  ~US$137.69 API-equivalent value

2026-10-16 14:24
  weekly meter observed at ~27% USED (~73% remaining)

2026-10-16 14:40–18:29
  only 9 OpenAI requests observed by the same proxy
  530,398 total tokens
  ~US$0.103 API-equivalent value

2026-10-16 ~18:08–18:12
  overlaps the common discontinuity window reported by multiple accounts in this issue

2026-10-16 18:31
  next locally observed weekly reading: 100% USED

after exhaustion
  subsequent Codex activity began drawing from additional usage credits

post-limit short run
  14 Sol requests
  1,275,087 total tokens
  ~US$0.46 API-equivalent
  local usage-credit balance fell by ~14.16 credits during this short run
  (usage credits and API-equivalent dollars are different units)

recovery
  account holder manually redeemed one banked reset because continued work
  was drawing additional credits

2026-10-17 ~15:11
  post-reset account-holder observation:
  ~12 percentage points of the refreshed weekly allowance used
  local tracker showed roughly US$25 API-equivalent usage

The current ~US$25 figure is an account-holder/local-tracker observation. I am not presenting it as a newly authenticated backend reading in this comment. The earlier October 16 request/token aggregates were already preserved during the local investigation.

3. A 4× denominator change fits the October 16 cliff unusually well

For this account, the last pre-cliff reading was about 27% used. If the underlying weekly allowance were reduced from a 20×-scale denominator to a 5×-scale denominator while already-consumed absolute usage stayed unchanged:

27% × (20 / 5) = 108%

That would immediately clamp the meter to 100% — exactly what was subsequently observed.

This is not unique to this account:

issue author: 77% remaining = 23% used; a 4× re-expression predicts 92% used / 8% remaining; observed 90% used / 10% remaining.
another Pro 100 report in this thread: 19% used → 75% used; a 4× re-expression predicts 76%.

Most importantly, the issue author reports that OpenAI AI Support found that the server-side weekly allowance used for the meter decreased while already-consumed usage initially stayed the same:
#54677 (comment)

So an account-specific hypothesis worth checking is a delayed entitlement/allowance recalculation that retroactively re-expressed already-consumed usage against a smaller denominator. Similar reports from accounts without a plan change mean this should not be assumed to explain every affected account.

4. Why the credit loss and banked reset matter

Once the weekly meter was suddenly at 100%, the next work began drawing from the account's additional usage-credit balance, consistent with OpenAI's documented behavior after included usage is exhausted:
https://help.openai.com/en/articles/12642688-using-credits-for-flexible-usage-in-chatgpt-personal-plans

The account holder therefore used one banked reset to resume work without continuing to burn credits. OpenAI documents a banked reset as refreshing the weekly allowance rather than adding a permanent entitlement:
https://help.openai.com/en/articles/20001498-how-banked-codex-resets-work

If the 100% state was caused by an erroneous or retroactive allowance adjustment, both the additional credits consumed because of that state and the banked reset spent to escape it are consequential losses.

5. Post-reset consumption: concerning UX, but not enough by itself to prove another accounting bug

The current local observation is roughly:

~US$25 API-equivalent / 12 percentage points
= ~US$2.08 per percentage point
= ~US$208 API-equivalent if linearly extrapolated to a full weekly window

Public measurements of Pro $100 / Pro 5× vary materially:

FinOps LLM drained six full Pro $100 windows from Sep 27–Oct 8 and measured US$100–234 per full window, median US$175:
https://finopsllm.com/research/chatgpt-pro-100-real-codex-multiplier
CodexQuota's standardized benchmark synced Oct 17 estimates Pro 5× at US$333/week and a measured 3.3× Plus relationship:
https://codexquota.today/
openai/codex Pro 5x: investigate Astra/Sol quota consumption across three full weekly allowances (Fast mode off) #43413 reports three exhausted Pro 5× meters totaling US$959.87 API-equivalent, or US$319.96 per full meter:
Pro 5x: investigate Astra/Sol quota consumption across three full weekly allowances (Fast mode off) #43413
Older July community measurements were often around US$500–675/week, but those used older models/prices and should not be treated as the current entitlement.

Therefore I am not claiming that today's ~12% / ~US$25 observation, by itself, proves a second post-reset bug. It implies ~US$208/full window, which is inside the range of recent real Pro $100 measurements, although below some standardized estimates. Model mix, reasoning, context, tools, and speed can materially change API-equivalent value per percentage point.

The stronger account-specific problem remains the abrupt mid-window October 16 allowance change, subsequent credit spillover, and forced use of a banked reset.

6. Requested server-side reconciliation

Could the team please provide or verify, for this account:

The absolute weekly allowance denominator and absolute consumed amount at the 14:24 UTC ~27% reading on Oct 16.
The same two absolute values immediately after the Oct 16 server-side event / first 100% reading.
The same values after the banked reset.
Whether a plan/entitlement recalculation was applied around 18:08–18:12 UTC, its intended effective date, and whether already-consumed usage was retroactively carried into a smaller allowance.
The model/service-tier weighting actually applied to the current Pro $100 weekly allowance.
A reconciliation of additional usage credits consumed after the unexpected 100% state.
If the allowance transition was erroneous or applied retroactively in a way that incorrectly exhausted the meter, restoration of the affected additional credits and the banked reset used to recover access.

Raw private logs and account identifiers are deliberately not being posted publicly. Sanitized request/token/quota aggregates can be supplied privately through Support if engineering needs identifiers for backend correlation.

Additional account report: +68 percentage points in the same weekly bucket on 2026-10-16

Adding an independently observed account timeline for backend correlation with this issue.

Observation (UTC)	Europe/Berlin (UTC+2)	Weekly quota used	Remaining
2026-10-16 17:39:52.782	19:39:52.782	23%	77%
2026-10-16 18:09:24.109	20:09:24.109	91%	9%

This is a 68-percentage-point increase between two locally recorded observations, separated by 29 minutes 31.327 seconds. We cannot resolve when within that observation gap it occurred. The first 91% observation is close to the 18:10-18:11 UTC interval reported in this issue, but that alone does not establish a shared cause.

Both observations report the same limit_id: codex, window_minutes: 10080, and resets_at: 1792649550 (2026-10-22 06:12:30 UTC). The weekly reset timestamp did not change.

Sanitized local telemetry excerpts

These fields were extracted directly from local JSONL event_msg / token_count records; private fields and unrelated payload content are omitted.

{"timestamp":"2026-10-16T17:39:52.782Z","rate_limits":{"limit_id":"codex","primary":{"used_percent":23.0,"window_minutes":10080,"resets_at":1792649550},"secondary":null,"plan_type":"prolite"}}
{"timestamp":"2026-10-16T18:09:24.109Z","rate_limits":{"limit_id":"codex","primary":{"used_percent":91.0,"window_minutes":10080,"resets_at":1792649550},"secondary":null,"plan_type":"prolite"}}

Context and limitations

Surface: Codex CLI / app-server used through Maestro on Linux. Currently installed CLI: 0.162.1; the incident-time binary version has not been independently established.
The local review found 2,183 distinct timestamp/percentage observations dated October 16 in Europe/Berlin, for this same weekly bucket. The counter went from 17% at the start of the day to 23% before this gap, then 91%, and 92% by the last observation that evening.
The account holder reports no unusually heavy workload explaining this increase. This was not an isolated idle test: concurrent agents/background work or other clients have not been ruled out. No single model, reasoning level, or speed tier has been established for all account activity during the interval.
No audited account-wide token delta or quota-per-token calculation is asserted here. Local snapshots document the reported quota discontinuity; they do not prove incorrect billing. Deferred posting, weighting, activity elsewhere, or a reconciliation correction require server-side investigation.
The same weekly bucket first reported 100% at 2026-10-17 10:21:54.540 UTC; later snapshots show a decreasing additional-credit balance. This makes reconciliation relevant to ongoing credit use as well.

Please correlate this account's quota ledger around 2026-10-16 17:39:52-18:09:24 UTC, including preceding activity for delayed/batched postings, with the nearby reports. Please identify the activity or accounting adjustment behind the 68-point increase and correct any erroneous quota/credit deductions if confirmed. Private account identifiers and full logs are intentionally not included in this public comment.

Verified local addendum — direct CodexBar + OpenCodex audit, and correction to my previous post-reset interpretation

I now have direct read-only access to the local CodexBar history and OpenCodex/Codex telemetry, so I can replace the earlier account-holder estimate with measured values. This comment is sanitized: no account IDs, email, local paths, project names, request/session IDs, conversation contents, or absolute credit balance are included.

A. Banked reset and current weekly meter are directly verified

CodexBar weekly history:

2026-10-17 05:29:05 UTC   100% used   old weekly window
2026-10-17 05:59:05 UTC     0% used   new weekly window
2026-10-17 07:59:06 UTC     1% used
2026-10-17 10:59:05 UTC     4% used
2026-10-17 12:59:05 UTC     5% used
2026-10-17 13:57:14 UTC     9% used
2026-10-17 14:56:50 UTC    12% used
2026-10-17 15:56:49 UTC    14% used
2026-10-17 16:56:49 UTC    15% used
2026-10-17 17:56:50 UTC    15% used
2026-10-17 18:06:49 UTC    16% used

A live quota refresh at ~18:08 UTC independently returned Pro 5× / prolite, 16% weekly used, with the refreshed window resetting at 2026-10-24 05:57:10 UTC. Two banked resets remain.

B. The earlier “~$25 for 12%” observation was numerically accurate — but its interpretation needed correction

At the exact CodexBar snapshot showing 12% used (14:56:50 UTC), OpenCodex's local usage ledger measured:

529 requests
102,990,353 total tokens
99,701,632 cached-input tokens
268,801 output tokens
US$24.035461 API-equivalent
91.49% request-level usage coverage

So the earlier "~$25" estimate was essentially exact.

However, 4 percentage points had already appeared before either the OpenCodex ledger or local Codex token-usage records showed post-reset model traffic. CodexBar was at 4% by 10:59 UTC; the first recovered native post-reset model activity begins around 12:36 UTC.

Therefore it is not valid to divide $24.04 by all 12 meter points and infer a ~$200 full-week allowance.

Using the 4% pre-existing reading as the local baseline:

4% -> 12%  = +8 points
visible OpenCodex workload = ~$24.04
~$3.00 API-equivalent / point
~$300 API-equivalent / 100 points

Adjusting only for OpenCodex's ~91.5% measured-request coverage gives roughly $328 / 100 points as a simple coverage-normalized reference.

That is close to recent independent Pro 5× measurements/estimates around ~$300–333 per exhausted meter. So I am withdrawing any implication that the post-reset 5× meter is independently proven defective. There is still unexplained/delayed account-wide usage in the first ~4 points, and later meter movement lags local traffic, but the marginal post-reset burn is broadly consistent with a materially smaller Pro 5× allowance.

C. Direct before/after comparison strongly supports a ~4× allowance-denominator change

For the final pre-incident window, from the last 0% state through the Oct 16 ~27% reading, OpenCodex measured:

3,328 requests
398,699,618 total tokens
383,372,672 cached-input tokens
1,817,393 output tokens
US$290.276 API-equivalent
~27 meter points
=> ~$10.75 API-equivalent / point

Post-reset, using the visible-traffic interval from the 4% baseline to the 14% reading:

628 requests
120,931,755 total tokens
117,181,696 cached-input tokens
366,142 output tokens
US$28.9385 API-equivalent
~10 meter points
=> ~$2.89 API-equivalent / point

That is a 3.71× change in displayed percentage per API-equivalent workload. Normalizing both only for each ledger window's incomplete usage coverage moves the ratio to approximately 3.8×.

This is strikingly close to the 4× capacity change from a 20×-scale allowance to a 5× allowance.

It also explains the Oct 16 cliff mathematically:

~27% used under old-size denominator × 4 ≈ 108% used
=> meter clamps to 100%

This is consistent with the issue author's relayed Support finding that the weekly allowance denominator decreased while already-consumed usage initially stayed fixed.

D. Plan terms suggest the move to the smaller allowance was expected; the timing/application is the dispute

This account's Pro $200 -> Pro $100 downgrade took effect at the Oct 14 renewal.

OpenAI's current Pro-tier documentation says grandfathering of the prior allowance lasts through Oct 29 while the Pro $200 subscription is active; once the lower tier takes effect, the Pro $100 limits apply. So I am not asserting that this account was entitled to keep a 20× allowance after the Oct 14 downgrade.

The account-specific problem is narrower:

the meter appears to have continued using an old-size denominator after the downgrade;
around Oct 16 ~18:08–18:12 UTC it was apparently re-based to roughly one-quarter the prior size;
already-consumed usage appears to have been carried into that smaller denominator;
this instantly exhausted the account mid-window rather than applying a clean new allowance boundary;
subsequent usage therefore spilled into additional credits and forced the account holder to use a banked reset.

E. Credit-balance reconciliation is the strongest new evidence

OpenAI documents 2,500 personal usage credits as equivalent to $100, i.e. 25 credits per $1:
https://help.openai.com/en/articles/20001147-codex-credits-for-students-terms-of-service

From the last stable pre-cliff credit baseline to the first recovered post-reset native snapshot, the local Codex quota records show a total balance decrease of:

1,270.442748 usage credits
≈ US$50.82 at 25 credits / $1

The timeline is important:

Immediately after the meter first appeared at 100%:
  visible balance deductions through 18:35 UTC = 39.63556 credits (~$1.59)

Between that last exhausted-state snapshot and the first recovered post-reset native snapshot:
  additional balance difference = 1,230.807188 credits (~$49.23)

After the first recovered post-reset snapshot:
  542 local quota/credit observations through 15:55 UTC
  credit balance change = exactly 0

Meanwhile, the local OpenCodex ledger between the first observed 100% state and the banked-reset window contained only:

19 requests
2,040,102 total tokens

GPT-6.1 Sol:
  14 requests
  1,264,631 input
  1,144,320 cached input
  10,456 output

GPT-6 Astra:
  5 requests
  763,597 input
  485,760 cached input
  1,418 output

OpenCodex API-equivalent: ~$3.7946

Using OpenAI's published token-based credit rates (Sol 6.1: 50 / 2.5 / 250 credits per 1M uncached/cached/output; Astra: 250 / 25 / 1,250), that locally recorded workload is approximately 94.87 usage credits, or ~$3.79 at 25 credits/$1:
https://help.openai.com/en/articles/11481834-chatgpt-rate-card-business-enterpriseedu-credit-based-pricing

So:

Observed credit-balance decrease:   ~1,270.44 credits
Locally explained workload:            ~94.87 credits
Difference:                          ~1,175.58 credits
Equivalent:                            ~$47.02

This does not prove that $47.02 was incorrectly charged. Local telemetry is not an account-wide ledger and cannot exclude ChatGPT Work/cloud activity, other-device activity, deferred settlement, or backend reconciliation.

But it is large enough that I am asking OpenAI to reconcile it explicitly. The local ledger does not contain anything close to enough post-limit model traffic to explain that balance movement at published token-based credit rates.

A plausible hypothesis to investigate is that when the allowance denominator was reduced/rebased, some previously included usage was retrospectively treated as over-limit usage and settled against the flexible-credit balance. That is a hypothesis, not a finding.

F. Requested backend answer

Please provide for this account:

Absolute included weekly allowance before the Oct 16 re-base.
Absolute consumed units at the last ~27% reading.
Absolute included allowance immediately after the re-base.
Whether previously consumed usage was retroactively re-expressed or repriced when the denominator changed.
An itemized explanation for the ~1,270.44-credit balance decrease, including original execution time versus settlement/posting time.
Whether any of those credit deductions represent usage that had originally been inside the larger included allowance.
If the mid-window transition caused incorrect credit deductions, restore those credits.
If the banked reset was only required because of an incorrect transition/settlement, restore that reset as well.

The post-reset account is now at 16% used and has shown no further flexible-credit draw in the local snapshots. That makes the Oct 16 transition and the associated credit settlement—not ordinary post-reset usage—the primary account-specific issue to investigate.

Possibly related account report: I’m on ChatGPT Pro $100/month. On October 18, 2026 (UTC+8), the dashboard showed about 70% of my weekly allowance remaining. By my estimate, this was roughly six hours after the reset; the exact reset time is unverified. I’d only run a few small tasks during that period, so around 30% used seems unexpectedly high to me.

Please reconcile deductions since the reset with actual account-wide usage, including any delayed posting or model/speed weighting, and confirm the applicable weekly allowance. If an accounting error is found, please correct the affected quota.

IMPORTANT UPDATE — October 18, 2026: OpenAI Support cannot explain the delayed quota adjustment, and routine tasks now consume excessive weekly allowance

I received another response from OpenAI Support, signed by Janis, regarding the sudden loss of 67 percentage points of my Codex weekly allowance on October 16.

OpenAI has confirmed that my server-side allowance changed on October 16, but still cannot explain why the adjustment occurred ten days after my subscription change.

1. What OpenAI Support confirmed

Here are the most important statements from their latest response:

The available records confirm that the allowance used by the meter changed on October 16. However, they do not show why the lower allowance was applied ten days after the subscription change, so we cannot confirm whether this resulted from delayed entitlement synchronization or an account configuration correction.

Support also stated:

There is no separate published provision describing the exact timing of this type of mid-window recalculation.

And:

Once the lower allowance took effect, the same usage represented a larger percentage of the new limit.

To summarize:

I switched from Pro $200 (20x) to Pro $100 (5x) on October 6.
I understood and accepted the lower allowance of the new plan.
On October 16, at 18:10:43 UTC, I had 77% weekly allowance remaining.
At 18:11:21 UTC, only 10% remained.
67 percentage points disappeared in 38 seconds.
OpenAI confirms the server-side allowance changed but cannot explain why it happened ten days after the subscription change.

A weekly usage window lasts seven days. My subscription change took place ten days before the adjustment.

How does the explanation about carrying accumulated usage into the new allowance account for a correction occurring more than one weekly window after the plan change?

Even if OpenAI initially assigned the wrong allowance, why was this corrected without warning, in the middle of active work?

Why were affected users not notified that their displayed weekly allowance could suddenly decrease?

2. A new problem: 6% of the weekly allowance for a routine documentation and Git task

Today, October 18, I experienced another concerning example of how quickly the Pro $100 weekly allowance is being consumed.

I asked Codex to perform a straightforward repository maintenance task:

Rename 73 existing PNG screenshots using a consistent filename format.
Update the corresponding Markdown image references.
Make minor updates to project documentation.
Run the existing quality checks.
Commit the changes and push them to main.

The task completed successfully, with commit 9145e98.

No application features were developed. No complex architectural implementation was required. Application CI and deployment were not triggered.

The entire task consumed approximately 6 percentage points of my weekly allowance, according to the usage meter.

To be clear, I am referring to the entire Codex task, including file inspection, edits, checks, and Git operations — not claiming that the git commit and git push commands alone consumed 6%.

At that rate, approximately 16 similar tasks would exhaust an entire weekly allowance on a $100/month subscription.

This raises a serious practical question:

If routine documentation maintenance consumes 6% of the weekly allowance, how much allowance will be consumed by actual feature development, debugging, architectural research, or complex implementation work?

3. Is the current allowance and metering behavior correct?

Other users have reported unusually rapid allowance consumption after the October 16–17 incidents, including after using banked resets.

I am not claiming that every reported case has the same cause or that my 6% consumption has already been proven incorrect.

However, after the confirmed server-side allowance change on October 16, I have no reliable way to determine whether my current weekly allowance and usage accounting are working as intended.

OpenAI Support says it cannot provide the absolute token allowances before and after the adjustment because usage depends on models, reasoning levels, caching, and other factors.

That may explain why there is no simple published token allowance, but it does not explain the delayed entitlement change or provide sufficient transparency to evaluate an unexpectedly high deduction for a specific task.

4. What I am requesting from OpenAI

I am asking the Codex engineering and billing teams to:

Explain why my Pro $100 entitlement was adjusted on October 16 rather than when I changed plans on October 6.
Confirm whether this was part of a broader server-side correction affecting multiple accounts.
Verify that my current weekly allowance is correctly configured for Pro $100.
Investigate the approximately 6% weekly allowance consumption associated with the documentation-only task described above, including model usage, background activity, and any delayed deductions.
Explain whether the accounting rules, model weighting, or effective allowance changed around October 16–17.
Restore any incorrectly deducted allowance or credits if errors are confirmed.

My existing additional credits and banked resets are separate resources. Using them does not resolve the underlying accounting question.

This is no longer just about one sudden 67-percentage-point reduction. It is about whether a $100/month Codex subscription provides predictable, transparent, and practically usable capacity for professional development.

I would appreciate an actual engineering investigation and a clear public explanation, particularly given the number of independent reports in this issue and on Reddit.

If other affected users have received substantive replies from OpenAI Support or have observed similar post-incident consumption, please share the details here without disclosing private account information.

Adding another affected account from Codex Desktop on macOS. I observed both sudden weekly-quota exhaustion and faster depletion afterward.

1. Sudden exhaustion

All timestamps below are UTC on October 16, 2026:

Timestamp	Weekly quota used
18:10:00.795	59%
18:10:08.939	100%
18:10:20.851	100%

The first two snapshots came from different sessions. The session reporting 59% also reported 100% at 18:10:20.851.

Before this event, usage increased steadily from 49% to 59% over approximately five hours. The quota window remained seven days, and reset timestamps differed by only two seconds.

2. Faster depletion afterward

I compared locally recorded token usage using the same published Standard credit rates for each model, calculating uncached input, cached input, and output separately:

Period (UTC)	Weekly quota consumed	Token-equivalent credits	Equivalent credits per percentage point
Oct 16, 07:49–17:49	18 percentage points	4,077.76	226.54
Oct 17, 20:43–Oct 18, 01:25	24 percentage points	1,839.64	76.65

This represents approximately 2.96 times greater weekly-quota consumption per Standard-equivalent credit in the later period. The earlier comparison excludes the sudden 59% to 100% jump.

These estimates account for model mix and caching at Standard prices, but do not establish the speed mode or subscription-specific quota weights. Local records cannot exclude delayed accounting or unobserved account activity.

I have preserved the original quota-event lines, timestamps, source references, and SHA-256 checksums.

Please investigate both the abrupt exhaustion around 18:10 UTC and the subsequent change in depletion rate, including any entitlement, model-weighting, or accounting adjustments.

Follow-up with a local-log analysis of my own account (ChatGPT Pro, $100/month; the rate-limit record reports plan_type "prolite"). These figures were calculated by a separate local Codex session and are provided for investigation, not as proof of a particular billing multiplier.

Client reported in the analysis: Codex Desktop on Windows 10, bundled codex-cli 0.163.0-alpha.10.2, app build 26.1013.40934. All times below are UTC.

On October 18, 2026, between approximately 04:11 and 04:23, the weekly primary.used_percent (10080-minute window) increased from 18% to 30%, or 12 percentage points. The local logs record 31 model calls across two long-running sessions in that interval:

Input: 4,986,268 tokens
Cached input: 4,893,568 tokens
Uncached input: 92,700 tokens
Output: 27,364 tokens
The recorded percentage increased through 18, 19, 20, 22, 23, 24, 25, 27, 29 and 30. The analysis found no image generation in this interval.

For comparison, two other intervals on the same account also consumed 12 weekly percentage points:

October 17 22:00 to October 18 02:00: 760 calls, approximately 160.9M input tokens (158.4M cached), 0.54M output; weekly usage 4% to 16%.
October 18 05:30 to 09:30: 730 calls, approximately 172.5M input tokens (170.6M cached), 0.36M output; weekly usage 31% to 43%.

A subsequent local test from 09:31 to 09:44 ran 20 sequential codex exec invocations, each requesting one built-in image_gen call. The analysis reports 79 model calls, approximately 8.4M input tokens and 20 generated images, while weekly usage moved from 43% to 44%. No other Codex activity was intentionally running on that machine during this test; this does not rule out account activity elsewhere.

On a raw-input-token basis, the anomalous interval consumed roughly the same percentage as comparison intervals with over 30 times as much input. This is only a rough comparison: input tokens alone do not determine metered usage, and this report does not establish identical model mixes, speed tiers, output costs, context pricing, or posting delays across the intervals. The later image test is an additional observation, not a matched controlled benchmark.

Could you reconcile the account-side usage for 04:11–04:23 UTC, including other devices, web/cloud tasks, other shared-limit activity, delayed accounting, or any entitlement/weight changes? If the 12-percentage-point increase includes an error, please correct it and restore the incorrectly deducted allowance. I can provide the two session IDs privately to support if needed.

I'm also experiencing noticeably faster weekly allowance depletion with GPT-6.1 Sol on ChatGPT Pro ($100/month). For tasks of similar difficulty, my weekly usage is consumed much faster without a corresponding increase in useful output. I don't have a controlled before/after measurement, but wanted to add another affected Pro user report. I’m looking for reliable service at my subscription level, rather than repeated quota resets.

Adding another report of an unexplained drop in weekly allowance, with a screenshot and timeline I have already shared publicly.

I'm on Pro Lite and mostly use GPT-6.1 Sol. My saved allowance history shows:

October 16, 2026 at 23:24 SGT (15:24 UTC): 92% remaining.
October 17 at 02:51 SGT (October 16, 18:51 UTC): 67% remaining.

That is a 25-percentage-point decline between recorded observations. There are no saved samples within that gap, so this does not establish the exact time of the deduction or its cause. The screenshot was captured later, when the remaining allowance had reached 64%.

This is my allowance-monitoring app's history, not a native Codex screenshot. The dashed future lines are projections, not observed usage.

Public references:

Screenshot: https://x.com/erfanExplores/status/2111399087203610824
Timeline and affected thread IDs: https://x.com/erfanExplores/status/2111761164883697943

Could the team check whether this is related to the discontinuities reported here and reconcile the allowance change against server-side activity, including delayed accounting or entitlement adjustments? I haven't established a common cause or whether the deduction was erroneous.

I have additional investigation details and local evidence that I can share through an appropriate private OpenAI support or feedback channel. Please let me know the preferred route and which diagnostic details would help. I'm keeping raw logs, private conversation content and project details out of this public comment.

Additional account: sustained weekly allowance drain after the 17 October reset

I am adding a separate, timestamped case. My affected usage followed a reset on 17 October 2026 at 20:41 UTC, rather than the sudden 16 October jump in the original report. We have not confirmed a shared cause. This was substantial active parallel work, not an idle-account incident.

This also followed Tibo's 17 October Day 12 announcement that context reuse between subagents, longer cache retention and improved request routing would increase effective Codex/Work usage. My concern is both the faster allowance drain relative to earlier deliberate burn tests and the lack of an apparent improvement in the recorded allowance/token comparison after that announcement. The records do not establish whether those changes applied to these requests, or what the same workload would have consumed without them. High cache reuse means I am not claiming that caching was generally broken.

Environment

Plan: ChatGPT Pro 20x, as reported by the account holder. The logged plan_type: pro establishes Pro but does not itself identify the multiplier.
Client: Codex desktop experience in the Linux ChatGPT desktop package, version 26.1007.71326, package chatgpt-desktop-bin 26.1007.71326-1. The installed package predates this incident. This is installation metadata, not a version field recorded on every request.
Bundled CLI: 0.162.0-alpha.17.2, directly recorded by all 50 affected portal-project native threads.
Platform: CachyOS, Linux 7.2.9-2-cachyos x86_64 GNU/Linux.
Models: gpt-6-astra, gpt-6.1-sol, gpt-6-sol, with small unrelated Luna usage included in the account-wide totals below.
Main coordinator turn contexts: Astra/xhigh initially, Astra/ultra for the long implementation turn, then Astra/xhigh. Child contexts recorded high or xhigh effort.
Affected limit: weekly codex allowance, window_minutes: 10080, secondary: null. New weekly resets_at: 1792874464, corresponding to 24 October 2026 at 20:41:04 UTC. The 17 October reset second is inferred from that seven-day window and is consistent with the user's exact 21:41 BST reset time and the first subsequent 0% readings.

Observed allowance timeline

All times here are UTC, and percentages are used, not remaining. Local BST was UTC+1.

17 October 2026	Weekly allowance used
20:41:29	0%
20:43:28	5%
20:45:25	10%
20:50:58	20%
21:17:31	30%
21:49:34	40%
22:15:43	46%

These are observation times across active local threads, not exact per-request debit times. The 46% reading persisted into the read-only investigation on 18 October. The audit excludes its own model activity.

Native accounting and workload checks

The frozen current window is 17 October 20:41:04 UTC through 18 October 10:35 UTC. Across enrolled sources it contains 3,926 usage records and 466,873,508 tokens. Most were cached input, not newly generated tokens.

Model	Uncached input	Cached input	Output, including reasoning
GPT-6 Astra	4,057,154	184,105,856	597,737
GPT-6.1 Sol	7,658,175	233,498,112	968,552
GPT-6 Sol	605,966	29,694,464	136,905
GPT-5.6 Luna	159,780	5,375,488	9,903
GPT-6 Luna	4,447	0	969
Total	12,485,522	452,673,920	1,714,066

All 3,886 desktop Codex response records, across 65 active native threads, match the central tracker one for one by owning thread/response ID, model and token fields. Another 11 desktop Pi records also match. There are no missing, extra or duplicated desktop events or token-field mismatches.
Repeated cumulative snapshots and inherited history were excluded. Compaction responses were counted once. Each current native thread's response totals reconcile with its cumulative counters at the frozen cutoff. Cached input is part of input; reasoning is part of output.
The reconstructed portal project accounts for 50 active threads and 3,397 responses, totalling 418,200,167 tokens. These are threads active during the run, not 50 simultaneous workers. In its busiest minute, 34 portal threads produced 225 responses.
Astra input cache reuse was 97.844%. The earlier deliberate burn family had 97.828% Astra input cache reuse. Aggregate caching therefore looks strong in both runs.
I genuinely switched several coordinators to Sol. Their first Sol responses appeared at 20:51:03, 20:51:21, 20:52:04 and 21:19:58 UTC. Existing turns continued on Astra after settings acknowledgements. The main coordinator remained Astra and accounted for 71,756,695 tokens over 562 responses.
The parent acknowledged Standard at 20:44:52 UTC. Three existing Astra reviewers retained recorded Fast settings through their last responses at 22:00:22, 22:07:17 and 22:10:26 UTC. This is a settings observation, not a claim that independent child settings are themselves a product defect.

Comparison with earlier deliberate burn tests

The stronger comparator is the 10 October 23:39:30 to 11 October 02:32:33 UTC account window. Its weekly reading rose from 33% to 75%, 42 percentage points over 173 minutes, versus 46 points reached in about 95 minutes after the 17 October reset.

All 2,959 desktop Codex records in the older window also match unique native response records. Genuine additional desktop work during that window is included, rather than attributing the account-wide percentage only to the named burn project.

All enrolled sources	Earlier October window	Current reset window
Uncached input	25,461,307	12,485,522
Cached input	332,870,784	452,673,920
Output, including reasoning	1,954,928	1,714,066
Total tokens	360,287,019	466,873,508
Weekly allowance points used	42	46
Unmultiplied Standard-rate comparison, credit units	12,351.74	7,789.70

The last row weights uncached input, cached input and output separately using published Standard credit rates. It is a comparison proxy, not OpenAI's subscription quota formula. It excludes API long-context premiums and speed multipliers. On that basis, current weighted usage is 36.9% lower despite the greater allowance consumption.

Speed remains an important uncertainty. I recall using Astra Fast for most work in both older burn tests. A preserved September configuration already had the desktop default-service-tier = priority preference alongside top-level service_tier = default. Historical settings acknowledgements therefore do not settle the server-served tier. Current response records also omit served-tier receipts. Applying the documented 2.5x subscription Fast factor only to current explicitly Fast-associated requests raises the current comparison proxy to about 10,147.26. This deliberately does not assume that older requests were Standard, or that unclassified current requests were Standard. It does not settle the discrepancy.

A second, September test rose from 59% to 65% used over about 42 minutes before a reset. It is a weaker comparator: some actor calls were ephemeral and the tracker does not import the compressed historical desktop logs. I am not treating its retained token count as a complete account ledger.

Requested investigation

Please correlate the affected run with server-side records and check:

The subscription debits after the 17 October 20:41 UTC reset, particularly 20:41-20:51 UTC and through 22:16 UTC. This is a later event than the original 16 October incident.
Effective model and speed per request, Ultra/internal-agent accounting, approval-review exemptions, background activity and any delayed or reassigned debits. Client token records cannot reconstruct those charges.
Whether the announced subagent context reuse, cache retention and routing improvements applied to this account/run. The expected gains are not apparent in this allowance comparison, but the available evidence does not establish that the improvements failed.
Whether the effective allowance or accounting changed relative to the earlier October window. Please identify the requests or adjustments that explain the difference and correct any verified erroneous deduction.

In-app diagnostic feedback: 01a14b8f-166c-7871-8fb8-91d634fe78fe

Affected portal thread: 01a14b8f-166c-7871-8fb8-91d634fe78fe. October comparison coordinator: 01a1282f-97df-7493-9bba-da86167adc7c. Additional response IDs, timestamps and redacted accounting metadata are retained for private correlation. Raw transcripts, browser contents, credentials and private infrastructure details are not attached publicly.

Cross-surface corroboration: ChatGPT Work on iOS (Plus plan), October 16–17, 2026.

I am reporting a similar abrupt increase in Work/Codex usage-meter consumption, though my environment is the native ChatGPT iOS app in Work mode, not Codex Desktop on Windows.

Beginning October 16, with a more pronounced effect October 17, the five-hour/weekly usage allowance depleted much faster than during my established use of GPT-6.1 Sol with high reasoning. The allowance had not been exhausted, and I did not receive an exhaustion or upgrade banner. The change was noticeable even when I was not doing the previous multi-hour heavy work.

I also observed an unexpected model-attribution pattern: the October 17 Messages analytics showed 172 messages total, with 146 labeled gpt-5.6-luna and 26 labeled gpt-6.1-sol-wm, although I did not manually select Luna. The seven-day Messages chart showed 190 Luna-attributed messages. A separate Work/Codex weighted usage chart attributed only 0.2% to Luna while attributing most usage to Sol and Astra. These are different measures, and I am not asserting that Luna was charged at Astra rates.

Could the maintainers investigate whether there were changes or defects in server-side usage accounting or model-attribution records around October 16, and reconcile the allowance deductions with actual foreground/background work and selected/executing models? I cannot establish the technical cause from the user-facing analytics.

Existing public discussion with reports from other affected users: https://community.openai.com/t/gpt-6-1-sol-suddenly-consuming-much-more-plus-usage-since-october-16/1407305

Oct 19 follow-up — current 21% window is mostly not new local usage

I re-ran a direct read-only audit of CodexBar, OpenCodex, and native Codex telemetry on this account on 2026-10-19 06:11 UTC. This materially updates my prior conclusion that the refreshed Pro 5× meter looked broadly normal.

No account identifiers, email, local paths, project names, request/session IDs, or conversation contents are included below.

1. Live state

A live quota refresh reports:

plan: Pro 5× / prolite
weekly used: 21%
weekly reset: 2026-10-24 20:49:11 UTC
banked resets remaining: 2
paid-credits-after-limit: disabled

2. There was a second server-side weekly-window re-anchor after the banked reset

The banked reset used on Oct 17 initially created this weekly window:

Oct 17 05:59 UTC   0% used   resets Oct 24 05:57
...
Oct 17 20:36 UTC  18% used   resets Oct 24 05:57

Then, without another banked reset being consumed:

Oct 17 20:56 UTC   0% used   resets Oct 24 20:49

The reset deadline moved forward by ~14h52m and the used counter went 18% -> 0%. The banked-reset count remained two, so this second re-anchor was not another user-redemption.

Another user in this issue independently reports a new weekly reset at Oct 17 20:41 UTC (resets_at=1792874464), only ~8 minutes before this account's new 20:49 anchor:
#54677 (comment)

A shared cause is not established, but the timing makes a server-side cohort event worth checking.

3. The new window climbed 0% -> 17% with zero locally recorded OpenAI requests

CodexBar:

Oct 17 20:56   0%
Oct 17 21:56   1%
Oct 17 22:56   5%
Oct 17 23:56   6%
Oct 18 00:56   7%
Oct 18 03:56   8%
Oct 18 04:56   9%
Oct 18 05:56  11%
Oct 18 06:56  12%
Oct 18 07:56  14%
Oct 18 10:56  17%

OpenCodex usage for Oct 17 20:49:11 through Oct 18 10:56:50 UTC:

requests:       0
tokens:         0
API-equivalent: $0

Native Codex session records likewise contain no response-usage records in that interval.

This is particularly notable because the immediately preceding banked-reset window had reached 18% used just before the server re-anchor. The new window then climbed back to 17% without any new local requests.

For reference, traffic in the prior banked-reset window from Oct 17 05:57 through the 20:49 server re-anchor was:

701 requests
135,959,736 total tokens
131,437,056 cached-input tokens
422,450 output tokens
~$32.99 API-equivalent
~91% request-level usage coverage

This makes delayed/backfilled reconciliation of prior-window usage a concrete hypothesis. It is not proven: local telemetry cannot exclude cloud/other-device activity or account-wide Work activity. But there is no local foreground/background Codex traffic matching the 0% -> 17% increase.

4. Only one scheduled local automation generated material new traffic afterward

The meter remained at 17% from Oct 18 10:56 through 21:56 UTC.

A scheduled local Codex automation ran around 18:20–19:30 UTC. Across OpenCodex it generated:

35 requests
3,663,981 total tokens
2,801,792 cached-input tokens
30,141 output tokens
~$1.450 API-equivalent

model split:
21 GPT-5.6 Terra requests
12 GPT-6.1 Sol requests
2 GPT-5.6 Luna requests

The 12 native Sol responses reconcile to ~1.10M native tokens and the session metadata identifies this as an automation, not foreground interactive use.

Despite that traffic, CodexBar stayed at 17% through 21:56 UTC. Then:

Oct 18 21:56   17%
Oct 18 22:56   21%

There were no additional OpenCodex requests between those two snapshots. This is compatible with delayed posting of the automation's usage, although server-side reconciliation is required to establish attribution.

Since then, only five small Luna requests (~225k tokens / ~$0.042 equivalent) are present locally, and the meter remains 21% as of Oct 19 06:06 UTC.

5. Current-window local totals are far too small to explain 21% as fresh usage

From the Oct 17 20:49 server re-anchor through Oct 19 06:11:

40 total OpenCodex requests
3,889,388 total tokens
2,840,192 cached-input tokens
33,885 output tokens
~$1.492 API-equivalent
100% usage-report coverage for these requests

Native Codex contains only 12 response records in the same window, all from the scheduled automation:

1,096,459 total native tokens
GPT-6.1 Sol / high

There is no large native Work/Codex run hidden behind the OpenCodex proxy.

The flexible-credit balance did not change across the available native snapshots in this current window.

6. Requested server-side reconciliation

Please check this account's server-side ledger around the Oct 17 20:49 UTC re-anchor and answer:

What server-side event changed the reset deadline from Oct 24 05:57 to Oct 24 20:49 and reset displayed usage from 18% to 0%, without consuming another banked reset?
Why did the newly anchored window then rise from 0% to 17% while local OpenCodex and native Codex recorded zero requests?
Was usage from the prior 05:57–20:49 banked-reset window carried/replayed into the newly anchored window?
Were any requests executed before the new 20:49 anchor posted into the new window afterward?
Is the current 21% meter supposed to include usage executed before its own apparent window start?
Please provide absolute consumed units and original execution/posting timestamps, not only percentages.
If prior-window usage was incorrectly carried into the new window, please restore those percentage points.

This account's current 21% reading cannot be reconciled as 21% of fresh local use after the Oct 17 20:49 re-anchor. The local evidence supports at most a small amount of new scheduled/background usage, with most of the displayed percentage appearing before any local request activity in the new window.

OFFICIAL OPENAI EMAIL — October 20, 2026: plan-transition allowance error acknowledged, $500 in credits offered as compensation

I received an email from OpenAI titled “Correcting your usage limit” regarding the abrupt Codex/Work weekly-allowance drop on October 16. This is a more specific written explanation than the earlier Support responses I posted in this issue.

My timeline: I moved from Pro $200 (20×) to Pro $100 (5×) on October 6. On October 16, 18:10:43–18:11:21 UTC, my reported remaining weekly allowance fell from 77% to 10% in 38 seconds.

OpenAI's explanation, quoted from the email:

After you moved from Pro 200 to a lower-priced plan, an error kept the higher weekly allowance from your previous plan in place.

When we corrected that error to match your current plan, any usage you had already accumulated for the week counted against the lower limit.

The email acknowledges that this happened without advance warning and states:

We should have handled the transition more carefully and we’re sorry for the disruption to your work.

Compensation: The email says OpenAI added $500 worth of credits (12,500 credits) to my account, separate from the normal weekly allowance, with an expiration date of January 20, 2027. It does not say that the original weekly allowance was restored. I am reporting what the email states, not independently auditing the credit balance.

What this establishes: OpenAI has explicitly acknowledged an error in how my previous plan's higher weekly allowance remained in effect after a downgrade, followed by a correction that recalculated already accumulated weekly usage against the lower limit. This provides an official explanation for my account's October 16 drop. It does not establish that every other user's October 16–17 quota anomaly has the same cause.

Still unanswered:

Why was my new entitlement not correctly applied on October 6, and why did the correction happen 10 days later, more than one seven-day weekly window after the plan change?
Why was there no advance notice of a sudden mid-window adjustment that could interrupt active work?
Which other accounts or plan transitions were affected, and will OpenAI proactively notify and compensate them?
Has the underlying entitlement synchronization/correction issue been fixed, or can it recur?

I can provide the original email/screenshot to the maintainers through an appropriate private channel if needed. Please confirm the scope of the incident and the preventative fix.

October 20 update: unchanged-tier Plus complaints remain unresolved I have remained on ChatGPT Plus, with no subscription upgrade or downgrade. My Work usage consumption increased sharply beginning October 16 and worsened October 17. I have not received an incident notification or corrective credits. Tibo has now publicly acknowledged approximately 40,000 accounts whose applied limits did not correspond to their selected subscription plans: https://x.com/thsottiaux/status/2112592264686149749 That statement is broader than the Pro-downgrade explanation quoted above. Please clarify whether unchanged-tier Plus accounts are included in the investigation and remedy. Independent Plus reports include: - GPT-6.1 Sol Low at standard speed: roughly 4–5 tasks versus 15–25 previously, with similar reported tasks: https://community.openai.com/t/sudden-and-abnormal-codex-usage-limit-exhaustion-on-chatgpt-plus-astra/1406729/5 - GPT-6 Luna Medium: approximately four hours previously versus under ten minutes beginning October 17, with the same reported workload: #55189 These reports require backend reconciliation; they do not establish a single common cause. But a correction following a Pro downgrade does not, by itself, explain rapid depletion on an unchanged Plus subscription. Please address: 1. Were unchanged-tier Plus accounts checked, and are they represented among the approximately 40,000 identified accounts? 2. How can affected subscribers who received no notification obtain an account-specific review? 3. Does the announced correction address continuing rapid consumption after fresh resets, or only a one-time entitlement adjustment? 4. What are the eligibility criteria for corrective credits, including for affected Plus subscribers? My screenshots and supporting evidence are already with OpenAI Support. Please keep unchanged-tier Plus complaints unresolved pending substantive findings rather than treating the plan-transition apology as a complete explanation of all reports. An acknowledgment and compensation for one identified group do not establish that the other reported cases were investigated or resolved.

…

On Tue, 20 Oct 2026 09:49:13 -0700, Egor Stepkin ***@***.***> wrote: EgorStepkin left a comment (openai/codex#54677) ### OFFICIAL OPENAI EMAIL — October 20, 2026: plan-transition allowance error acknowledged, $500 in credits offered as compensation I received an email from OpenAI titled **“Correcting your usage limit”** regarding the abrupt Codex/Work weekly-allowance drop on October 16. This is a more specific written explanation than the earlier Support responses I posted in this issue. **My timeline:** I moved from **Pro $200 (20×)** to **Pro $100 (5×)** on **October 6**. On **October 16, 18:10:43–18:11:21 UTC**, my reported remaining weekly allowance fell from **77% to 10% in 38 seconds**. **OpenAI's explanation, quoted from the email:** > After you moved from Pro 200 to a lower-priced plan, an error kept the higher weekly allowance from your previous plan in place. > When we corrected that error to match your current plan, any usage you had already accumulated for the week counted against the lower limit. The email acknowledges that this happened **without advance warning** and states: > We should have handled the transition more carefully and we’re sorry for the disruption to your work. **Compensation:** The email says OpenAI **added $500 worth of credits (12,500 credits)** to my account, **separate from the normal weekly allowance**, with an **expiration date of January 20, 2027**. It does **not** say that the original weekly allowance was restored. I am reporting what the email states, not independently auditing the credit balance. **What this establishes:** OpenAI has explicitly acknowledged **an error in how my previous plan's higher weekly allowance remained in effect after a downgrade**, followed by a correction that recalculated already accumulated weekly usage against the lower limit. This provides an official explanation for **my account's October 16 drop**. It does **not** establish that every other user's October 16–17 quota anomaly has the same cause. **Still unanswered:** 1. Why was my new entitlement not correctly applied on October 6, and why did the correction happen **10 days later**, more than one seven-day weekly window after the plan change? 2. Why was there no advance notice of a sudden mid-window adjustment that could interrupt active work? 3. Which other accounts or plan transitions were affected, and will OpenAI proactively notify and compensate them? 4. Has the underlying entitlement synchronization/correction issue been fixed, or can it recur? I can provide the original email/screenshot to the maintainers through an appropriate private channel if needed. Please confirm the scope of the incident and the preventative fix. -- Reply to this email directly or view it on GitHub: #54677 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[Codex Desktop][Windows] Weekly quota jumped 67 points in 38 seconds (Oct 16, 2026; 18:10 UTC) #54677

Description

Summary

Revised timeline

Token counts reported by local Codex inspection

Environment

Previous similar incident

Expected / actual

Requested investigation

Related reports

Activity

EgorStepkin commented on Oct 16, 2026

Potentially contemporaneous Reddit report (October 16, 2026)

EgorStepkin commented on Oct 16, 2026

New forensic evidence — October 16, 2026 (correction to initial approximate timeline)

nkosi23 commented on Oct 16, 2026

Re1ne99 commented on Oct 17, 2026

danieljhkim commented on Oct 17, 2026

xhplyf618 commented on Oct 17, 2026

Niriakot commented on Oct 17, 2026

Additional affected account: macOS / Codex via OpenClaw

AstrumNya commented on Oct 17, 2026

zaijiayoujiayou-bot commented on Oct 17, 2026

Han-1413141 commented on Oct 17, 2026

21 remaining items

Rmosser commented on Oct 17, 2026

Additional account evidence

Environment

Subscription plan

Description

Steps to reproduce

Expected behavior

Actual behavior and timeline

Rate-limit snapshots

Token usage evidence

Full Reset behavior

Related issues

Requested investigation

Diagnostic limitations and privacy

Redacted diagnostic attachment

avs-io commented on Oct 17, 2026

Full sanitized follow-up — quota cliff, credit spillover, banked reset, and post-reset capacity

1. Plan context

2. Sanitized local timeline

3. A 4× denominator change fits the October 16 cliff unusually well

4. Why the credit loss and banked reset matter

5. Post-reset consumption: concerning UX, but not enough by itself to prove another accounting bug

6. Requested server-side reconciliation

chr1syy commented on Oct 17, 2026

Additional account report: +68 percentage points in the same weekly bucket on 2026-10-16

Sanitized local telemetry excerpts

Context and limitations

avs-io commented on Oct 17, 2026

Verified local addendum — direct CodexBar + OpenCodex audit, and correction to my previous post-reset interpretation

A. Banked reset and current weekly meter are directly verified

B. The earlier “~$25 for 12%” observation was numerically accurate — but its interpretation needed correction

C. Direct before/after comparison strongly supports a ~4× allowance-denominator change

D. Plan terms suggest the move to the smaller allowance was expected; the timing/application is the dispute

E. Credit-balance reconciliation is the strongest new evidence

F. Requested backend answer

GameDevBaiyi commented on Oct 18, 2026

EgorStepkin commented on Oct 18, 2026

IMPORTANT UPDATE — October 18, 2026: OpenAI Support cannot explain the delayed quota adjustment, and routine tasks now consume excessive weekly allowance

1. What OpenAI Support confirmed

2. A new problem: 6% of the weekly allowance for a routine documentation and Git task

3. Is the current allowance and metering behavior correct?

4. What I am requesting from OpenAI

IWAIBAOLI commented on Oct 18, 2026

1. Sudden exhaustion

2. Faster depletion afterward

GameDevBaiyi commented on Oct 18, 2026

AuricTW commented on Oct 18, 2026

NSErfan commented on Oct 18, 2026

Superfishintights commented on Oct 18, 2026

Additional account: sustained weekly allowance drain after the 17 October reset

Environment

Observed allowance timeline

Native accounting and workload checks

Comparison with earlier deliberate burn tests

Requested investigation