Repository navigation
[Meta] Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker #41220
Description
Summary
There are now many open Codex reports describing a common user-visible symptom family:
Codex subscription quota or purchased credits are depleted materially faster than the user's prior baseline or local/token evidence would predict, sometimes with abrupt changes during an unchanged usage window, passive/background consumption, or usage records that do not reconcile with the meter.
This meta issue is intended to link and compare those reports in one place.
This does not assume they all have one root cause. The evidence already points to several potentially independent mechanisms: entitlement/provisioning, server-side weighting/accounting, background activity, retries/polling, context replay, analytics/ledger gaps, and client-side workflow amplification. The purpose is to stop treating each report as an isolated anecdote and give maintainers a single place to correlate timelines, fixes, regressions, and account-side reconciliation.
Why a tracker is warranted
Several reports contain controlled or unusually strong evidence rather than only subjective impressions:
| Issue | Evidence / symptom | Why it matters |
|---|---|---|
| #28879 | Same GPT-5.5 plan/app: reported limit cost per token jumps ~10–20x between June 12 and June 18 despite smaller prompts and near-zero reasoning | Strong pre/post comparison; not Sol-specific |
| #30939 | Usage reported 5–10x faster since mid-June; one message consumed 46% of a 5-hour window | Early recurring report; bug + rate-limits |
| #31322 | Usage normalized, then regressed to ~5x faster later the same day without a matching workflow change | Suggests transient/server-side state rather than only task complexity |
| #33685 | Weekly allowance draining like the former 5-hour limit on GPT-5.5 High | Important evidence that the symptom is not limited to GPT-5.6 Sol/Ultra |
| #34971 | Long sessions repeatedly reprocess massive cached context; July smaller operational workload generated far more token processing than earlier larger projects | Concrete workload-amplification mechanism |
| #35259 | Corrected rollout audit attributes 19.8% of raw local token volume to model turns whose only action was wait/status polling | Concrete avoidable-consumption mechanism |
| #37445 | Controlled experiment: 103h47m with clients closed = 0% drain; launching ChatGPT desktop/background activity triggered a fixed ~6% weekly deduction; quitting stopped it | Strong passive/background-consumption reproduction |
| #38157 | Multiple active Pro 20x accounts allegedly behave like Pro 5x while still reporting plan_type: pro |
Possible entitlement/provisioning class |
| #38335 | Pro 20x: ~11 percentage points of weekly quota during an ordinary ~50-minute frontend task; ~2–3 points in just over a minute while an external CLI did the substantive work | Workload-specific reproduction |
| #38728 | Same account, same 7-day bucket, same reset timestamp and service tier: quota accounting temporarily accelerated ~2.4x, then returned to its earlier range | Particularly strong bounded accounting-shift evidence |
| #39260 | 53,000 purchased credits; 45,252 credits not reconciled in the user-visible ledger; balance still decremented; >95% of rounds attributed to codex-auto-review |
Purchased-credit/ledger reconciliation failure |
| #39699 | Same repository/comparable development workflow; newer sessions reportedly consume >2x weekly quota despite similarly high cache ratios | Comparable-work regression report |
| #39818 | GPT-5.6 Luna: weekly allowance drops ~40% in one day during relatively light work | Not Sol-only; model-weighting/accounting question |
| #40067 | Plus weekly usage ~99% remaining → 0% within hours; local OAuth-agent logs show ~9.39M gross input tokens while Profile later attributes 81.7M tokens; historical same-account days did not consume quota at the same rate | Local/server attribution mismatch plus same-account historical baseline |
| #40527 | Pro 20x user reports similar Sol-dollar-equivalent activity consuming roughly twice the prior fraction of weekly quota after reset | Post-reset baseline shift |
| #40895 | ~78% remaining → 0% in a very short period on Aug 26; asks for server-side reconciliation of sessions/background activity | Very recent sudden-depletion report |
Additional related reports already cross-linked from those issues include #38191, #38233, #38309, #36801, #29955, #26512, #21966, #28525, #20153, #35463, and others.
Symptom classes that should be investigated separately but correlated
A. Effective quota / entitlement / weighting changes
Examples: #28879, #30939, #31322, #33685, #38157, #38335, #38728, #39699, #39818, #40527.
Question: did the effective capacity, plan entitlement, per-model weighting, cache treatment, or rate-limit accounting change for some users/windows even when the advertised plan and nominal quota did not?
B. Passive or background consumption
Examples: #37445 and reports linked from #29955/#38335.
Question: which app/background/suggestion/review/subagent operations consume the same subscription bucket, and are those operations both intentional and visible to the user?
C. User-visible ledger / analytics does not reconcile with charged usage
Examples: #39260, #40067, #37751, #25479.
Question: can the backend meter decrement while analytics/credit-history surfaces omit or misattribute the activity? If so, users currently cannot audit their own consumption.
D. Workflow amplification that can consume large amounts of quota without proportional useful work
Examples: #34971, #35259, #38831, #38989.
Potential mechanisms include repeated cached-context replay, model-mediated waiting/polling, retry/fallback behavior, recursive delegation, repeated reviews/tests, and compaction/reconstruction loops.
These may be real billed work rather than a meter arithmetic error, but from the user's perspective they still reduce effective subscription capacity and need to be distinguishable from an entitlement/accounting defect.
E. Sudden or bounded discontinuities
Examples: #38728, #40067, #40895, #31322.
These are especially useful diagnostically because the consumption rate changes sharply while important account/window variables remain stable, or later returns to the prior range.
Important distinction: nominal quota vs. effective usable work
A statement such as “the subscription quota was not reduced” does not by itself resolve these reports.
The nominal bucket can remain unchanged while effective usable work falls if any of the following change:
- entitlement/provisioned capacity;
- model weighting;
- cache-hit behavior or cache charging;
- hidden/background model calls;
- retries or transport fallback;
- agent polling/wait loops;
- context replay/compaction behavior;
- subagent fan-out;
- usage attribution or reconciliation.
The tracker therefore asks about effective consumption and attribution, not only whether the advertised percentage bucket was intentionally resized.
Requested maintainer actions
- Designate a canonical tracker for abnormal Codex usage/quota-accounting reports (this issue or another existing issue) and link duplicates/related reports to it.
- Correlate the server-side timeline for the strongest bounded reports, especially Pro weekly quota meter accelerated ~2.4x mid-window, then returned to normal (Aug 14) #38728, Opening the ChatGPT desktop app silently consumes the Codex weekly limit (fixed 6% per background suggestion run; reproduced under controlled conditions) #37445, GPT-5.6 Plus weekly usage suddenly drained from ~99% to 0% within hours — possible usage accounting regression #40067, and Abnormal Codex usage accounting exhausted remaining weekly allowance instantly #40895, against deployments/feature flags/rate-limit or entitlement changes.
- Separate root-cause classes rather than closing all reports as one generic “usage varies by model/workload” explanation.
- Expose auditable per-task usage attribution, ideally including:
- foreground model requests;
- model + reasoning effort + service tier;
- input / cached input / output / reasoning tokens;
- retries;
- compactions;
- subagent requests;
- wait/status model re-entry;
- background/ambient/auto-review activity;
- surface/client;
- amount charged to each active quota bucket or purchased-credit balance.
- Document which background activities are quota-bearing and provide user controls where appropriate.
- Reconcile and restore incorrectly consumed quota/credits when server-side investigation confirms erroneous accounting or unintended background activity.
- When a fix is deployed, state which symptom/root-cause class it addresses so users can tell whether remaining reports are expected to be resolved.
What would make reports maximally useful
For users adding cases here, please include as much of the following as possible without publishing private project content:
- plan and Codex surface (CLI / Desktop / Work / web / external OAuth client);
- model and reasoning effort;
- exact time window + timezone;
- quota percentage before/after and reset timestamp;
- whether Fast/Ultra/subagents were used;
- local
token_counttotals and cache ratio if available; - whether the app was idle/backgrounded;
- whether another device/client was active;
- session/feedback IDs that maintainers can inspect internally;
- a comparison against an earlier baseline on the same account/workflow when available.
The key goal is not to prove one universal bug in advance. It is to make the existing evidence correlatable, so that entitlement bugs, accounting bugs, background drains, and genuine client/workflow amplification can be separated and fixed rather than repeatedly rediscovered in isolated tickets.
Activity
amiras2030 commentedon Aug 27, 2026
I’m seeing the same issue on my ChatGPT Pro account.
Within only a few hours, roughly 50% of my remaining Codex usage quota suddenly disappeared. The consumption was far beyond my normal usage rate and does not match the amount of work I was doing.
After this sudden depletion, the quota/reset window also appears to have moved forward to the following week.
In my normal usage, even several hours of active Codex work consumes only a small percentage, so losing around 50% within such a short period is clearly inconsistent with my usual baseline.
This has happened more than once, so it does not appear to be a one-time display glitch.
Lucifor1976 commentedon Aug 29, 2026
I’m seeing a very similar pattern on ChatGPT Plus with Codex.
My main issue is not simply that the limits are “too low”, but that the effective usable work per 5-hour window has dropped dramatically and the quota behavior is difficult to plan around.
Recent example from today:
What makes this especially frustrating is that the weekly quota still had plenty of capacity left, but I was completely blocked by the 5-hour limit.
My workflow before the recent changes was very different. When the 5-hour restriction was not the main bottleneck, I could work for several hours across multiple smaller projects before exhausting the weekly allowance. Those projects were less agent-heavy and involved less repository scanning, testing, Git work, browser checks, and automated validation than my current project, so I do expect higher usage now — but the difference still feels disproportionately large.
I have also observed confusing reset behavior in the UI:
This makes planning development sessions difficult.
The current Codex workflow also makes the 5-hour window particularly painful for long autonomous tasks. In my case, a release task was still actively performing browser checks, tests, and final validation when Codex stopped with:
So the quota can interrupt a coherent task before the release is fully finished, despite significant weekly quota still remaining.
I am not claiming that all of this necessarily has one root cause. Large repository tasks obviously consume more resources. But from a user perspective, the important problem is that the relationship between:
is currently too opaque to understand or predict.
A per-task usage ledger would help enormously: model, input tokens, cached input, output/reasoning tokens, subagents, retries, browser/test activity, and the exact amount charged against both the 5-hour and weekly buckets.
At the moment, I can see percentages disappearing, but I cannot reliably tell which part of the task caused the consumption or estimate whether the next task will use 5%, 30%, or the remainder of the entire 5-hour window.
FromAriel commentedon Aug 29, 2026
I think the substantive test would be to find a past point where you know exactly how many tokens and how much percentage of usage were done for a task in the past. Gather the logs and sanitize them to avoid any private data.
Then roll back the project to that same state today and give it exactly the same prompt from the logs and then record how much usage it drained.
IF anyone had screenshots or other data from a historical point where they can say for sure X tasks used Y tokens with prompt P then we can easily roll back and repeat it and see how much usage is consumed.
Karlam77 commentedon Aug 29, 2026
I opened a separate issue with a controlled local-log comparison between the 0.147 and 0.150 runtime series: #41541.
With reasoning=high and almost identical total token workload (~32.8M), I measured:
0.147.0-alpha.6.5:
32.807M tokens / 71.3 min = 0.460M tokens/min
0.150.0-alpha.12.2:
32.754M tokens / 40.5 min = 0.809M tokens/min
The newer runtime therefore processed essentially the same token workload ~1.76x faster in wall-clock time in this direct comparison. My broader early-August baseline suggests ~1.6x as a conservative description of the scale.
The increase comes from both more model steps/min and more tokens/model-step.
I do not observe a proportional improvement in end-to-end engineering task completion time, while my Pro weekly allowance now lasts only around 2–3 intensive working days.
Full measurements and methodology:
#41541
axisrow commentedon Aug 30, 2026
+1. Filed a related report specifically about the transparency gap: #41617 — quota drained with zero matching "Exec" events in local ccusage logs, so this isn't just poor UI attribution, it's a silent billing skip with no inspectable record on either side.
axisrow commentedon Aug 30, 2026
+1. Same symptom under the current "Computer History" name (renamed Chronicle) — silent quota drain on 2 consecutive days, Aug 29 and Aug 30, no corresponding attributable activity.
dzhokn commentedon Aug 30, 2026
+1. It is an absolute catastrophe! My team is literally blocked at the moment.
FromAriel commentedon Aug 31, 2026
2 turns in codex used %60 of weekly quota even when model was told to tightly scope the requests and bee efficient. The agent admits to multiple failures. The first task used an entire 5 hour budget and 16% of the weekly then when I resumed it used another 70% of the 5 hour budget.
On Plus a 5 hour budget is also equal to 16% of the weekly total. Roughly 17th of the weekly total. So these are not 5 hour budgets these are entire days of coding. This is regardless of model used. %100 of 5 hours on plus = 16% or 17th of the week.
Also the model admits despite extensive prompting it specifically ignored the constraints to be efficient.
wauspe commentedon Sep 1, 2026
just for one task...
ushigyu88-alt commentedon Sep 1, 2026
Adding an independent, sanitized local-log measurement that may be useful for comparison. No raw logs, project names, paths, prompts, account/session identifiers, or source content are included here.
I analyzed historical vs. recent Codex sessions using the in-log
rate_limits.primary.used_percentmeter. The analysis is deterministic (no LLM used for the calculations), and I am not asserting a specific root cause.Key observations:
Caveats: the sample is small, absolute expected/normal quota consumption is unknown, and client-side logs cannot distinguish among metering, model/reasoning behavior, context handling, tool processing, retries, or other backend/runtime changes. Very small sessions were also treated cautiously because quota-per-token ratios become unstable with small denominators.
The limited conclusion is therefore: a substantial measurable change occurred in the relationship between observed processed workload and the OpenAI-provided quota meter in this local history. I cannot determine the cause from client-side telemetry alone.
Sharing the aggregate measurements only in case they help correlate this report with other reports or server-side telemetry.
grtninja commentedon Sep 1, 2026
Related Desktop messaging/entitlement-state report: #42153.
After the shared Codex/Work allowance was exhausted, the user manually selected GPT-5.6 Luna. Desktop accepted the selection and displayed
You're now using Luna, a faster model for simpler tasks, but the immediately following prompt was still rejected by the exhausted usage gate.This is not an automatic-fallback claim and does not assume Luna Reserve was present. The defect is that the product presents
model selectedas though it were an active usable state without verifying that any allowance can execute the next request. The UI should distinguishselectedfromavailable to run, show the active usage bucket, and avoid success-style messaging when the composer remains hard-blocked.t-var-s commentedon Sep 2, 2026
Adding another bounded sudden-depletion reproduction for correlation. I have posted the fuller report under #20153 as well.
Environment
Sequence after the 5-hour quota reset
The contrast seems diagnostically useful: the older/complex thread, including a compaction, consumed 7 percentage points total, whereas the fresh thread in another project after a full app restart coincided with an 84-point drop from one planning request.
This also makes accumulated context from the previous thread or continued foreground execution in that thread less likely to explain this particular event.
I was testing a context-reduction workflow at the time (t-var-s/repo-brief), intended to reduce repeated repository discovery/context overhead. The abnormal drop nevertheless occurred in the fresh project/thread after restarting Codex, so reducing that source of context/work did not prevent the event.
I have also reported the incident directly to OpenAI Support. They have the timestamp/account information for the event.
jgcrosta commentedon Sep 2, 2026
+1. Same issue here. My entire 5-hour allowance was exhausted after only 3 normal prompts, none of them particularly heavy. This is very different from my previous Codex usage and looks consistent with the quota depletion issue reported here.
32 remaining items
austindtranz-cloud commentedon Sep 17, 2026
Adding my own experience to this tracker rather than opening another issue.
Environment: ChatGPT Work/Codex on Windows; my main account is Pro 20x, and I also pay for a second Pro subscription, purchased specifically to continue client work when the first account's weekly allowance ran out.
Around September 12, I observed the allowances reset on both accounts. I do not know what triggered those resets. The renewed capacity was then consumed unusually quickly again: roughly two days of usable work followed by several days of waiting. Screenshots I supplied to Support on September 15 showed 0% weekly remaining on the main account and 7% on the second. These are historical snapshots, not a claim about today's balances. I have not purchased usage credits or paid resets.
Before Astra, my usual workload with GPT-5.5/GPT-5.6 generally fit within the weekly allowance. I now switch models repeatedly to conserve it. Fast mode is normally off for Astra. Some tasks did involve high reasoning/Ultra and parallel agents, so this is not a controlled identical-workload benchmark or proof of incorrect billing.
I have been reporting the problem to Support since September 11 and submitted a consolidated 14-point follow-up on September 15, with screenshots and clarifications. Please review the account-side entitlement and usage records, including model weighting, repeated context processing, subagents and delayed accounting, rather than treating this only as a request for more usage.
Requested outcome: explain what happened, restore any allowance found to have been incorrectly deducted, and consider a temporary weekly reset or other goodwill allowance while the case is investigated.
Client development and contractual deadlines are being disrupted. I want to stay with OpenAI, but unpredictable access is making that difficult. I am not asking for unlimited usage; I need a working service and an understandable account-level outcome. Account identifiers and supporting evidence can be provided privately through Support.
jcdomarquesexames commentedon Sep 18, 2026
Windows Desktop: 2% quota consumed immediately after app update/restart, with no Codex task run
I observed a passive quota decrease associated only with updating and reopening the Codex Windows desktop app.
Environment
Observed sequence
Observed result
A 2-percentage-point quota decrease occurred during the update/restart cycle without any user-initiated Codex task.
Expected result
Installing an application update and reopening the desktop client, without starting any Codex task, should not consume the user's Codex quota.
This may be relevant to the passive/background-consumption class tracked in this meta issue. If startup/update initialization intentionally performs quota-bearing model work, that activity should be documented and attributable in the usage ledger; otherwise this appears to be unintended background quota consumption.
I can reproduce/monitor this on the next Windows app update and provide before/after screenshots and the exact app version if needed.
liweijie123 commentedon Sep 21, 2026
There is also an escalation gap for account-level quota/reset problems: the Help Center/support UI does not expose a ticket path for my account, while the information needed to verify these cases (server-side usage ledger, reset type, pre/post-reset allowance, and reset-anchor changes) is not available client-side.
For reset/accounting incidents, please provide either:
Without one of those, users cannot independently distinguish an additive reset from a window replacement/re-anchoring or reconcile unexplained quota changes.
lechatlisse commentedon Sep 21, 2026
Post-fix evidence from two paid Pro accounts (Europe/Paris). This is continuing after the 12 September reset/fix announcement.
This is a marked change from my historical Codex usage. I could previously work heavily without repeatedly exhausting Pro allowance. The issue is not merely that limits exist; consumption has changed suddenly and the product gives me no usable way to audit or anticipate it.
Could the Codex team please reconcile the server-side ledger and confirm whether this accounting is intended? Please inspect model/reasoning weights, subagents, auto-review/background work, retries/failures, duplicated tool calls, Fast-mode flags and reset events. Internal orchestration is controlled by the product; a customer should not have to ration or reverse-engineer it to make a paid plan usable. I am filing the account-specific evidence privately with Support as well.
Radek44 commentedon Sep 21, 2026
New Pro case: rapid post-reset depletion, idle/background symptom, and non-reconciling analytics
Adding a new case that appears to span this tracker's passive/background consumption, missing attribution, and agent/subagent fan-out categories.
Plan / surface
Observed behavior
Usage UI evidence
-, so the visible per-chat ledger does not reconcile with the 100% meter.Private account details and screenshots are being submitted through OpenAI Support rather than posted publicly.
Requested account-side audit
This appears directionally similar to #43971, #44339, #46904, #47045, and #47051, although the same root cause is not assumed.
ryfzfr-coder commentedon Sep 22, 2026
Subject: Unexpected Codex 5-hour quota consumption caused by background memory/follow-up activity
Hello OpenAI Support,
I would like to report unexpected Codex usage consumption on my ChatGPT Plus account and request an investigation of the affected usage.
Product:
Summary
My Codex 5-hour usage window unexpectedly dropped from approximately 100% remaining to 87%, and then to 86% after restarting the Codex Desktop app.
This was unusual because my only intentional activity during this period was a very small scheduled automation that replies "good morning" once per day.
I inspected the local Codex telemetry and found that the scheduled automation itself does not appear to explain the quota consumption.
Scheduled automation
The automation is scheduled daily at approximately 04:45.
Its visible session was:
Thread:
01a06ae1-a01e-7472-8d5f-0e7e7d4b2eb1
At approximately 04:48:10:
There were no additional inference turns in that visible automation session.
Unexpected background thread
However, local Codex logs show that a second thread appeared at approximately 05:19:
Thread:
01a0c5d6-afe1-7bb3-85e6-8064be1b6ac8
Turn:
01a0c5d6-b01f-7023-a592-0945ffb8ce40
This thread continued generating model sampling activity from approximately 05:19 until 08:27.
There were 19 token-usage samples associated with the same turn.
Examples:
05:19:44
total_usage_tokens=24731
model_needs_follow_up=true
has_pending_input=false
needs_follow_up=true
05:20:13
total_usage_tokens=64865
model_needs_follow_up=true
has_pending_input=false
needs_follow_up=true
07:33:44
total_usage_tokens=76500
model_needs_follow_up=true
has_pending_input=false
needs_follow_up=true
08:27:53
total_usage_tokens=86783
model_needs_follow_up=true
has_pending_input=false
needs_follow_up=true
There was no new user input during this activity.
Memory subsystem correlation
Immediately before the second thread started, the local log contains:
2026-09-22 05:19:36
codex_memories_write::phase1
The second thread was created at essentially the same time.
This suggests that the unexpected inference activity may have originated from Codex background memory generation.
The same turn continued requesting follow-up sampling for more than three hours, despite:
has_pending_input=false
Local logs also show quota-related events at approximately:
and an HTTP 429-related event at approximately 07:33:40.
Usage impact
Before this incident, the same daily automation normally left my 5-hour usage at approximately 99–100% remaining when I checked it in the morning.
On September 22, with otherwise similar intentional usage, the meter showed approximately:
Restarting the client did not correspond to a new visible model turn, so the additional percentage change may have been a usage-meter refresh or delayed server-side reconciliation.
Request
Could you please:
I can provide additional sanitized excerpts from:
~/.codex/logs_2.sqlite
and the relevant rollout JSONL files if needed.
I will not provide auth.json, authentication tokens, or unrelated conversation/source-code content.
Thank you.
route0254 commentedon Sep 26, 2026
I experienced what appears to be a similar quota/accounting issue today.
Environment
no-active-thread-01a0dc6f-1d2a-7921-bdd4-15bd172234f9Usage pattern before the issue
I started using Codex at approximately 10:30 JST, shortly after my weekly quota had reset.
I was intentionally using Codex quite heavily across two projects in parallel:
From approximately 10:30 to 15:00 JST, my weekly quota decreased from about 100% to about 40% remaining.
I checked the Usage page multiple times during this period, and the quota appeared to decrease gradually and consistently.
Because I was deliberately running two high-reasoning projects in parallel, I consider this approximately 60% consumption plausible and I am not disputing that portion of the usage.
Unexpected quota drop
At approximately 15:00 JST, I confirmed that I still had about 40% of my weekly quota remaining.
I then continued substantially the same type of work, without intentionally increasing the workload or changing to a significantly more expensive configuration.
At approximately 15:30 JST, the weekly quota suddenly changed to 0% remaining, and my active Codex work was stopped because the usage limit had been reached.
In other words:
The final approximately 40% disappeared within roughly 30 minutes, despite the workload being broadly similar to the preceding period.
Current account state
At the time I submitted feedback:
Usage Analytics
The 7-day Usage Analytics page currently shows the following activity breakdown:
I understand that these percentages represent the breakdown of recorded activity and are not percentages of the weekly quota itself.
Feedback already submitted
I also submitted this through the ChatGPT feedback form with diagnostic/browser logs enabled.
Feedback ID:
no-active-thread-01a0dc6f-1d2a-7921-bdd4-15bd172234f9Request
Could the OpenAI team please investigate:
I can provide additional redacted local logs if necessary. I will not provide authentication tokens,
auth.json, unrelated conversation contents, or unrelated source code.1337Mizu commentedon Sep 29, 2026
Adding another current Pro case from September 29, 2026.
Plan: ChatGPT Pro 5x ($100/month)
Surface: Codex in VS Code
Model: GPT-6 Astra
Observed symptom: the entire weekly Codex allowance is being consumed within roughly 5 hours of intensive but normal development work.
This has happened consistently enough that it has become difficult for me to use Astra as my primary coding model. After a weekly reset, I can start with essentially the full allowance and reach the weekly limit again within approximately one working session.
I understand that Astra, reasoning level, context size, tool calls and subagents can materially affect quota consumption, so I am not claiming that a five-hour session should correspond to a specific percentage of the allowance. However, the effective usable weekly capacity is far below what I would expect from this subscription and appears consistent with the rapid-depletion reports collected in this issue.
The practical result for me is currently:
~100% weekly allowance → ~5 hours of Astra development → 0% remaining
Could the Codex team please reconcile the affected period against the server-side usage ledger and distinguish how much of the weekly allowance was consumed by:
If server-side reconciliation confirms unintended background processing, incorrect model weighting, entitlement/accounting issues, or otherwise incorrectly consumed quota, please restore the affected weekly allowance or provide an equivalent credit/reset adjustment.
I can provide more precise timestamps, usage screenshots and client/session information privately if useful for investigation.
Posting this here rather than opening a duplicate issue because it appears to match the quota-depletion/accounting symptom family being tracked in #41220.
jin44194649 commentedon Sep 30, 2026
Related current data point from Sep 29, 2026 (America/Chicago): on a $200 ChatGPT Pro account, the weekly meter reset/upgrade time was 18:09. The main ChatGPT Work session lasted about three hours (to ~21:09) and was used for eight chapters of writing/review. By 22:32 the weekly meter showed 89% remaining. I am not claiming the same root cause as this issue, but the effective consumption was unexpectedly high and the UI did not provide enough task-level attribution to reconcile the drop. I added the fuller timeline in #40527.
This seems appropriate for this meta tracker because it adds a current Work-surface case. It would be useful if task-level attribution exposed foreground requests, model/reasoning tier, retries/compactions/subagents/background activity, and exactly how each task was charged against the weekly allowance.
tsukaska commentedon Oct 1, 2026
Codex Pro $500 allowance exhausted twice, rapid credit depletion, and Sol/Ultrafast settings mismatch — September 29–30, 2026
Adding a September 29–30, 2026 case to this tracker. All narrative times are Mountain Time, America/Denver (MDT, UTC−06:00). CSVs include UTC for internal correlation.
I upgraded from Pro $200 to Pro $500 overnight September 29–30 while work was running in the Windows Codex desktop app. Before upgrading, I was using Sol 6.1 xhigh with several agents/subagents across a couple of sessions, and the allowance was barely ticking down. When the old allowance reached zero and began consuming my courtesy credits, I upgraded. I tried Astra Ultrafast on a few tasks and left it finishing an improvement, with a Sol Fast session and some subagents also working. At my first check roughly three hours later, I saw the upgraded allowance exhausted AND approximately 42,000 credits already consumed. I then used my banked reset and went back to sleep. At the next check, the reset allowance was exhausted and approximately 15,000 credits remained. This is my recollection of the account displays; the local snapshots below record different credit amounts around the reset and need reconciliation with the server ledger. I request an engineering reconciliation of entitlement, model/tier weighting, cached-context processing, subagent work, and the credit ledger. The evidence does not establish one universal billing bug.
The strongest specific anomaly is an archived Sol session recording
service_tier: ultrafastin applied settings while its contemporaneous feedback logs recordunset. OpenAI documents Ultrafast for Astra and lists Sol 6.1 as Standard/Fast. Please inspect the actual server-selected tier and charge for this session.Environment and activity
plan_typechanges fromprotopromaxat the times below; the mapping to the commercial plan comes from my account history, not the string alone.originator: Codex Desktop. Internalsource: vscodelabels should not be mistaken for evidence that I ran a separate IDE client.0.159.0and0.159.2. Desktop observed before the later investigation update:26.928.21956, build12404; after updating:26.928.31416, build12553. These observations do not identify the exact desktop version at every overnight request.gpt-6.1-solandgpt-6-astra, bothxhighin the audited window. Speed settings include Standard (default), Fast (priority), and Ultrafast;unsetremains unresolved rather than being treated as Standard.Recorded allowance and credit timeline
propropropromaxpromaxpromaxpromaxpromaxpromaxpromaxpromaxpromaxpromaxThese are first/last observed account snapshots, not exact purchase/reset click timestamps. Snapshots from different streams can briefly disagree or be stale. The first upgrade observations have reset timestamps varying by seconds; the second reset settles on Unix
1791373335(October 7, 5:42:15 a.m. MT). The preceding upgrade bucket includes Unix1791360494(October 7, 2:08:14 a.m. MT).From the observed 62,496.930985 credit balance to the last observation before 8 a.m., the recorded net decline is 32,080.592620 credits. Before 9 a.m., the recorded net decline is 45,433.134440. By noon it is 47,433.6820525. These arithmetic differences describe local snapshots, not the exact values I saw at my checks. In particular, I recall approximately 42,000 credits already consumed before I used the reset, while the local balance near the reset is approximately 57,292 remaining. Please reconcile this difference instead of treating the snapshot sequence as a complete or authoritative billing history.
I also recall a model breakdown attributing approximately 80% of activity in the relevant period to Sol, and a separate usage calculation/display showing only approximately 63% total usage. The denominator, selected date range, and freshness of those figures have not been established. The 63% figure is not the token audit calculated below. The initially captured historical analytics showed 62.9% as of September 29 at 6 p.m. MT with an out-of-date warning; that particular capture predates most of the overnight activity. Please identify which period and meter each account display represents.
Local token evidence
gpt-6.1-sol/xhighgpt-6-astra/xhighThe combined total is 964,573,759 processed tokens across 6,852 positive cumulative-counter increments. Input is 960,190,113; cached input is 929,715,456 (96.83%); uncached input is 30,474,657; output is 4,383,646. Reasoning tokens are already part of output and were not added again.
Gross processed tokens include repeated context processing. They are not distinct project tokens, dollars, credits, or proof of an incorrect charge. No token-counter decreases were observed in the included streams. There were 99
compactedrecords, 12 directspawn_agentcalls, and extensive tool/agent coordination during the window. This supports investigating workflow/context amplification; it does not quantify its billed share. Archived sessions and child-parent mappings are preserved in the CSV evidence.Specific settings mismatch and correlation IDs
01a0ef5b-f00a-7210-bc94-96d952dff66e. Applied settings pairgpt-6.1-sol,xhigh, andultrafastat September 30 02:43:05.498, 04:19:22.443, 05:18:02.620, 06:19:10.423, and 07:01:14.840 MT. Local rollout lines: 9814, 9859, 9874, 9888, 9900. Corresponding feedback observations sayunset. Ten following usage increments total 1,876,880 tokens under the latest recorded Ultrafast setting; this is temporal association, not evidence the server accepted or billed Ultrafast for Sol.01a0f16e-ea84-7a22-982f-05339e8fbc2b. Applied Ultrafast at 02:30:04.032 MT, Standard at 02:35:27.649, then Ultrafast again at 02:39:42.918; subsequent settings are preserved in my local evidence.01a0f197-3f30-73b0-9231-8a476efb3e2f, observed 03:43:22–04:00:52 MT.01a0f285-0979-7642-ae62-e64608bf790a,01a0f285-1223-7673-a6a8-4fdd11773511,01a0f285-1b7c-7941-ac7c-2ccbbf866d8c.01a0f0b8-8647-7012-8835-69f293f60d3dhaddefaultfeedback during 06:52–07:48 MT; Sol children hadpriorityfeedback. Thus the evidence does not show every Sol session switching to Ultrafast.All 26 audited session IDs and parent relationships are included in the expandable table below. A dedicated submitted feedback ID and support ticket number were not available in the supplied conversation; none has been fabricated. Project titles, prompts, file paths, account identifiers, and shared conversation links are omitted from this public comment.
Baseline and interpretation
My earlier same-account/workflow experience was that Sol xhigh with multiple agents/subagents across a couple of sessions consumed allowance slowly on Pro $200. That qualitative baseline is my observation, not a reconstructed charge-per-token measurement. The immediate local comparison starts with 81% used on the old plan at 10 p.m.; a fresh upgraded bucket is first observed at 02:08:16, exhausted at 05:06:26; a second fresh bucket is observed at 05:45:35 and exhausted at 07:33:09. I have retained model/token totals for these periods in the local evidence. This is not a controlled baseline: the plan, models, speed settings, number of streams, and work changed. I do not have a verified earlier matched-workflow credit ledger.
OpenAI's speed documentation states Fast consumes included allowance at 2.5× Standard and credits at 2×; Astra Ultrafast consumes allowance at 8× and credits at 6×. These multipliers are material but do not reconcile the particular account by themselves.
Other user reports include Astra reconnect-associated credit drain #43045 and two-turn Astra quota depletion #42987. They are reports on OpenAI's repository, not confirmation that my case has the same cause. I have not demonstrated the reported reconnect loop in my sessions.
The official changelog lists CLI 0.159.3 on September 30 for account security setup reminders, and 0.159.2 on September 29 for Windows console suppression. It does not map desktop build 26.928.31416 to a fix for this usage complaint. I found no official confirmation that the update resolves this case.
Requested investigation
Please reconcile the session IDs and timestamps against server inference and billing records: the actual model and normalized service tier for each request; cache discounts and repeated context/compaction charges; retries or duplicate requests; parent/child attribution; credit debits; the exact entitlement provisioned at upgrade; and the reset transition. Specifically determine why Sol accepted/stored an Ultrafast setting while feedback reported
unset, and whether that affected any charge. Please identify any incorrect deductions and restore the affected allowance/credits if an error is confirmed.Evidence package
I retained CSVs with numeric usage, timestamps, settings and opaque session IDs only; they are not attached to this comment. Rate-limit/credit snapshots are account-wide observations and must never be summed across sessions. Raw screenshots, project mapping, account identifiers and the original support transcript are retained separately for private support review.
All 26 audited sessions and parent relationships
01a0ef5b-f00a-7210-bc94-96d952dff66e0.159.001a0ef89-e5d9-7e70-9dea-19be932a5de001a0ef5b-f00a-7210-bc94-96d952dff66e0.159.001a0ef8a-04c2-7f33-871a-97bc17347a4401a0ef5b-f00a-7210-bc94-96d952dff66e0.159.001a0ef8a-2fcc-7d33-b65d-31e5017c946501a0ef5b-f00a-7210-bc94-96d952dff66e0.159.001a0ef9a-88fb-7163-8cfb-40c3a73746880.159.001a0efe5-6453-7720-8037-9ed27bc4c7db0.159.001a0f007-b9d8-7983-bc2d-c711ea7d014401a0efe5-6453-7720-8037-9ed27bc4c7db0.159.001a0f007-d7d2-7f03-8c65-07b43bd1fda301a0efe5-6453-7720-8037-9ed27bc4c7db0.159.001a0f007-f1a2-7ed3-bd1d-98a0b661c41501a0efe5-6453-7720-8037-9ed27bc4c7db0.159.001a0f053-f0a5-7f70-a559-3efd611d66c001a0efe5-6453-7720-8037-9ed27bc4c7db0.159.001a0f0b6-9148-7ba1-9675-b8246e4edf540.159.001a0f0b8-8647-7012-8835-69f293f60d3d0.159.001a0f0bd-36f7-7d20-8eeb-87d51abde3f701a0f0b8-8647-7012-8835-69f293f60d3d0.159.001a0f0bd-6c6c-7db1-95af-f90950ffe3a501a0f0b8-8647-7012-8835-69f293f60d3d0.159.001a0f0bd-a149-72c1-9e53-c9e03b3bce5401a0f0b8-8647-7012-8835-69f293f60d3d0.159.001a0f0c6-1a6a-7b13-b6e1-d98caa8017c501a0f0b8-8647-7012-8835-69f293f60d3d0.159.001a0f0f5-9268-7123-a8ec-5561427779880.159.001a0f103-8184-79b2-b240-b95d7efe316301a0ef5b-f00a-7210-bc94-96d952dff66e0.159.001a0f13f-b395-7b63-8020-cb31e44d444e01a0f0b8-8647-7012-8835-69f293f60d3d0.159.201a0f13f-fbd6-7df0-9412-54a0a642341601a0f0b8-8647-7012-8835-69f293f60d3d0.159.201a0f140-474f-7ba2-80fd-24200f8a900501a0f0b8-8647-7012-8835-69f293f60d3d0.159.201a0f16e-ea84-7a22-982f-05339e8fbc2b0.159.201a0f197-3f30-73b0-9231-8a476efb3e2f0.159.201a0f285-0979-7642-ae62-e64608bf790a01a0f16e-ea84-7a22-982f-05339e8fbc2b0.159.201a0f285-1223-7673-a6a8-4fdd1177351101a0f16e-ea84-7a22-982f-05339e8fbc2b0.159.201a0f285-1b7c-7941-ac7c-2ccbbf866d8c01a0f16e-ea84-7a22-982f-05339e8fbc2b0.159.2Local audit method and coverage
The token window is 2026-09-30 04:00:00Z inclusive through 14:00:00Z exclusive. Available recent local state records supplied rollout paths; archived sessions were included. Per session, I calculated positive differences in
token_count.info.total_token_usagein file order, using pre-window values as the starting baseline and skipping unchanged totals. I did not repeatedly sum cumulative totals or addlast_token_usage. Model/effort comes from the precedingturn_context. Input includes cached input; output includes reasoning. Events are attributed to their recorded completion timestamp, without time-prorating a request across a boundary. No decreasing cumulative counters were found in included histories.Applied settings come from
thread_settings_applied; feedback tier tags are a separate source. Neither establishes the actual billed tier. Tier settings and logs can disagree, as in the Sol example. Account-level allowance/credit snapshots are observations and are not summed across sessions. Coverage is available local records, not all server-side activity. Direct tool and compaction counts do not measure their billed share.I can provide the sanitized detailed CSVs through an appropriate follow-up channel. Private account details, project content and raw screenshots are not published here.
denisgolovkin220-code commentedon Oct 3, 2026
GPT-6.1 Sol / Pro $100 — October 3 vs October 1, with corrected speed/concurrency context
Correction to my original comparison: I have clarified the workflow: October 2 used Fast; October 3 does not use Fast. October 1 had one intentional working task; October 3 has two. These are my own observations as the account owner, added after the initial metadata investigation. October 2 is therefore retained only as contextual data, not the primary comparison baseline.
I perceived faster weekly allowance consumption around the latest reset. The primary comparison below is now October 3 versus October 1, and it must account for the changed number of working tasks. It is not a controlled same-workload experiment.
Plan: ChatGPT Pro 100 ($100/month, previously described as Pro 5x)
Surface/platform: Windows desktop app, Windows 11 Home ARM64, build 28000
Installed app package: 26.930.3930.0; CLI/runtime at investigation: 0.160.0
Model/effort: predominantly GPT-6.1 Sol high/xhigh in the compared work; other efforts and GPT-6 Sol children also occur. The separate diagnostic chat uses GPT-6.1 Sol Ultra.
Speed clarification: Fast on October 2; no Fast on October 3. Current config records
service_tier=default(Standard). The exact speed of every October 1 request is not established by this clarification or the sparse local tier records.Timezone: Asia/Yekaterinburg, UTC+05:00.
These are account-wide, integer-rounded used percentages, with local response-token sums between the same endpoint timestamps:
Corrected interpretation: October 3 aggregate quota consumption per wall-clock hour was 1.795× October 1 (+79.5%), while recorded token throughput was 2.891× (+189.1%). Gross tokens per quota percentage point increased from 7.353M to 11.846M. These records do not show increased deductions per gross recorded token or establish incorrect server accounting.
The change from one intentional task to two is a material confounder and may explain much of the aggregate increase. I am not dividing the quota rate by two as though tasks had equal costs: their context sizes, active durations, reasoning, subagent activity and contributions to the account-wide meter are not independently matched. The October 1 interval is nearly a full calendar day, whereas October 3 covers about 2.8 hours. These are elapsed calendar hours including concurrent work and waits, not isolated active-compute hours or equal completed work.
For context only, Oct 2 00:00:02.377–22:19:11.549 showed 49% → 100% used, 2.285 pp/hour and 468,832,532 gross tokens. This Fast-mode day is excluded from the primary comparison. Official Pro tier guidance states Fast uses included allowance at 2.5× Standard for the same model. That is not a valid multiplier to apply blindly to a whole day's mixed, concurrent activity; actual request tiers would need server-side reconciliation.
The last old bucket observation was 100% at Oct 2 22:19:11.549, with next reset Oct 7 12:41:53. The first new observation was 0% at Oct 3 10:48:17.047, with next reset Oct 10 10:48:14. The reset trigger itself is unknown. Desktop Usage and the account API agreed at about 13:40: 91% remaining / 9% used. No five-hour secondary limit, zero purchased credits, two available banked resets. No reset, purchase, or speed-setting change was performed by the investigation.
Local coverage, Sep 29–Oct 3: 100 rollout files / 96 unique threads, including 79 child files; 8,049 unique response usage records, 14 explicit compactions, 607 duplicate cumulative snapshots excluded. Cached/input ratios for the primary Oct 1 / Oct 3 windows were 96.84% / 96.80%. Cached input is a subset of input and reasoning a subset of output; neither was added twice. Gross tokens include repeated context processing and are not an independent billing oracle.
Further limits:
defaultandpriority; many responses lack a preceding tier observation. These records do not override the account-owner clarification or establish the actual billed tier of every call.#49961 was verified open during the investigation; it remains a related user report, not a confirmed cause. No official October 2–3 Pro 100 allowance-cut or GPT-6.1 Sol weighting announcement was found in the bounded search.
One built-in Codex feedback was submitted before this clarification. Its October 3/October 2 rate comparison should be read subject to the correction above. The corrected account-specific report and private correlation identifiers have now been sent in the existing OpenAI Support conversation, and the Support UI confirmed escalation to a support specialist. No case/reference number was displayed; server-side reconciliation remains pending. Safe screenshots and detailed metadata are retained privately; file attachment through the Support browser control did not complete. Please reconcile actual server model/tier, cache/context replay, compactions, retries, parent/child attribution, entitlement and reset transitions. Private project content, email, account/session IDs and local paths are omitted here.
hortrame-systems commentedon Oct 6, 2026
Public forensic dataset: tier provenance, context accounting and unreconciled credit depletion
I run HORTRAME Systems. We have published the minimized evidence and executable calculations from our Codex investigation: https://github.com/hortrame-systems/openai_dispute.
This adds a bounded dataset to the tracker, not a claim that all reports share a cause. The acute episode occurred on 15 September 2026 evening in America/Toronto (16 September UTC). Earlier tier observations are distinguished from the acute context-accounting episode.
Reproducible client-side observations:
Alternative explanations are retained. A post-event configuration contains Priority. A frozen-rate scenario is compatible with 89.47% of one nominal reported balance decline, subject to cross-time conversion, assumed rates and unpriced guardian work. Ordinary charging remains possible. A tier multiplier prices a workload; it does not establish why that workload was generated or whether the repetitions were necessary.
The unresolved request is for historical tier/authorization provenance, request parentage and usage, account/funding-pool attribution, effective rates, and debit/balance/settlement linkage. We accept privacy-preserving identifiers or attributable provider reconciliation. The public record does not establish a billing defect, wrong-account billing or a particular restoration amount.
The repository also preserves dated support correspondence: provider reconciliation was represented as pending on October 3 UTC; another thread was closed on October 6 UTC without that reconciliation; subsequent AI-assisted intake could not confirm prior internal case states. This does not establish that all internal review has stopped.
Requested maintainer action: route this dataset to the owner of request-to-credit attribution and tier provenance, and identify a way to obtain the historical reconciliation described above. Public reviewers can test the included calculations and report exact counterexamples. Account-specific remediation remains in Support.
Archive SHA-256:
2735eda6746b271a09526dbda245c706c7cdb3f9df6bc6cb8e9a6d8ad287e67a.Zenodo DOI (all versions): https://doi.org/10.5281/zenodo.23192953. The README links the pinned archive and reproduction instructions. Please do not post private prompts, credentials or raw account identifiers here.
hortrame-systems commentedon Oct 8, 2026
Cross-reference for provenance: the public forum report that preceded the released forensic package is the 16 September 2026 Codex Rate Limits Discussion Thread post here:
https://community.openai.com/t/codex-rate-limits-discussion-thread/1378553/875
That post records the contemporaneous user-visible symptom: Luna Reserve fell from roughly 95% to 0 during the same session after rapid purchased-credit use. The later public package does not treat that observation alone as proof of a billing defect; it reconstructs the surrounding client-side tier/context-accounting record and preserves alternative explanations.
Public package: https://github.com/hortrame-systems/openai_dispute
Zenodo DOI: https://doi.org/10.5281/zenodo.23192953
Archive SHA-256:
2735eda6746b271a09526dbda245c706c7cdb3f9df6bc6cb8e9a6d8ad287e67aThis comment adds only the dated cross-reference; it does not change the findings or claims in the released archive.
FromAriel commentedon Oct 11, 2026
Datapoint...
Project Token Usage Audit
This project consumed 698,991,068 recorded tokens before the current audit—approximately 699 million.
Total Token Usage
Token Breakdown
Of the 2,902,664 output tokens, 897,876 were reasoning tokens.
Important: Cached input and reasoning tokens are subsets of the totals above, not additional amounts to add again.
Session and Response Counts
Audit Overhead
The quoted project total of 698,991,068 tokens excludes the current audit.
At the measured snapshot, the audit itself had consumed an additional 2,844,415 tokens.
Summary
The project consumed approximately 699 million tokens across 73 sessions and 5,084 model responses before the current audit.
Including the audit overhead measured at the snapshot, total recorded consumption reached approximately 701.84 million tokens.
All session-level response usage totals were verified against their corresponding cumulative counters.
lowkeybuilds commentedon Oct 14, 2026
A suggestion for making reports here comparable: many comments use different units (percentage drops, "turns", screenshots, hand-totalled token counts), which makes it hard to tell a metering change from a heavier workload.
The rollout files already hold what is needed to compute one comparable number per window. Each
token_countevent logs the call'sinput_tokens,cached_input_tokens,output_tokensandreasoning_output_tokensnext torate_limits.*.used_percent,window_minutes,resets_atandplan_type. Dividing quota points used in a window by the tokens logged in that window gives points per 1M tokens per plan and model. A step change in that number on the same plan, model and kind of work is evidence of class A in the tracker. Jumps inused_percentwith no local calls at all are evidence of class B (another device, a cloud task or background use).I published a free, zero-dependency script that computes this from local logs (disclosure: I wrote it):
npx github:lowkey-studio/quotatrace --since 30d. The report contains only counts and hashed session ids, so it can be pasted here. It also flags quota steps out of line with their tokens, and estimates replay, polling and re-sent tool output (class D).--shareproduces per-window aggregates (date, window, plan, points, thousands of tokens) in one JSON line, which can be pooled across reporters. Source and method: https://github.com/lowkey-studio/quotatrace