[Meta] Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker

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

1. Designate a canonical tracker for abnormal Codex usage/quota-accounting reports (this issue or another existing issue) and link duplicates/related reports to it.
2. Correlate the server-side timeline for the strongest bounded reports, especially #38728, #37445, #40067, and #40895, against deployments/feature flags/rate-limit or entitlement changes.
3. Separate root-cause classes rather than closing all reports as one generic “usage varies by model/workload” explanation.
4. 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.

1. Document which background activities are quota-bearing and provide user controls where appropriate.
2. Reconcile and restore incorrectly consumed quota/credits when server-side investigation confirms erroneous accounting or unintended background activity.
3. 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_count totals 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.