Codex and Work analytics can show contradictory quota pools and zero credits while the global usage gate remains blocked

Open 💬 3 comments Opened Jul 23, 2026 by grtninja

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The Codex and Work analytics surface can present mutually contradictory account state: the shared weekly pool is exhausted and blocks all Work/Codex execution, while model-specific or shorter-window pools still show substantial or full remaining usage. Purchased credits can also remain at zero in the product while the payment is pending or completed externally.

This makes the analytics page non-authoritative and leaves the user unable to distinguish a normal exhausted pool from entitlement drift, delayed reset propagation, credit-ledger delay, or a desktop/account migration problem.

This is separate from #35040, which requests a durable first-party quota/reset event history. This report concerns the current state becoming internally contradictory and operationally blocking.

Environment

Product: ChatGPT Codex and Work analytics / Codex Desktop
Platform: Windows 11 Pro
Subscription: ChatGPT Pro
Observed during the July 2026 Work/Codex desktop rollout
Workload: active long-running repository and security work

Observed behavior

Across the affected account state, the analytics surface showed combinations including:

shared Codex and Work weekly usage at 0% remaining;
a shorter usage window still showing remaining capacity;
one or more model-specific pools showing 100% remaining or substantial remaining capacity;
Credits remaining: 0 after a credit purchase was initiated and visible as pending externally;
the global Work/Codex gate continuing to reject work despite apparently available model-specific capacity;
sidebar/history/project state changing during the same unified-app migration window, increasing uncertainty about whether the product was reading one coherent account ledger.

The user briefly observed a reset/full state and could send a small request, then the account returned to the blocked state. No durable event history explained whether the reset was applied, reverted, partial, or superseded.

Steps to reproduce / diagnose

This may depend on account migration or ledger timing, so the most useful reproduction is telemetry-driven:

Open Codex and Work analytics for an account with multiple usage pools.
Exhaust or approach the shared weekly pool.
Observe whether shorter-window or model-specific pools still report available capacity.
Purchase or auto-reload credits near the shared limit.
Compare the payment state, displayed credit balance, and the actual execution gate.
Refresh or reopen the unified desktop app during an account/sidebar/history migration window.
Check whether the displayed pool states and the server-side execution decision remain consistent.

Expected behavior

Every displayed pool should identify exactly which operations it can fund.
The execution gate should cite the specific exhausted pool that blocked the request.
Model-specific remaining balances should not imply usable capacity when a higher-level shared gate overrides them without explanation.
Purchased credits should show a visible lifecycle: pending, posted, rejected, refunded, or applied.
A reset or adjustment should produce a durable account event with before/after balances and affected pools.
If account state is still reconciling, the UI should say so rather than presenting contradictory balances as final truth.
The user should have a session-linked support route for usage or credit review.

Impact

Paid Pro agentic work is blocked while the UI appears to show unused capacity elsewhere.
Users may purchase additional credits without knowing whether they can be applied to the blocked pool.
Users cannot determine whether a reset failed, a credit purchase is delayed, or an account migration is stale.
Repository and security work is interrupted, and additional usage can be spent diagnosing product-account state rather than completing the task.

Evidence available

timestamped analytics screenshots showing the contradictory pools and zero-credit state;
a private incident packet preserving the account-state chronology;
screenshots of the simultaneous sidebar/history migration instability;
no private balances, payment identifiers, repository names, or account identifiers are included in this public report.

Related reports

#35032 — repeated compaction/reprocessing usage waste
#35038 — active service incident not surfaced or linked to usage protection
#35040 — requested authoritative reset/quota-event history
#23511 — auto-reload credit does not trigger at the configured threshold
#15477 — dashboard quota and actual execution gate contradict each other for code review

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#34323
#34874
#34066

Powered by Codex Action

grtninja · 1 month ago

Duplicate-triage distinction:

#34323 and #34874 concern a reset being shown/applied and then disappearing or updating reset_at without restoring allowance.
#34066 concerns a newly purchased Plus entitlement already showing the weekly pool exhausted.
#35047 is narrower at the simultaneous current-state reconciliation layer: the UI can show a globally blocking shared pool, apparently available model-specific/shorter-window pools, and a zero or pending credit state at the same time, without identifying which pool controls the execution gate or whether the account ledger is still reconciling.

Please consolidate only if the canonical issue will preserve these acceptance requirements: every pool identifies what it can fund; the blocking response names the exhausted governing pool; model-specific capacity cannot look usable when a higher-level gate overrides it without explanation; and purchased credits expose a pending/posted/rejected/refunded/applied lifecycle.

kejriwals · 28 days ago

Adding a Plus-tier case that supports the acceptance requirement in this thread that purchased credits must expose a pending / posted / rejected / refunded / applied lifecycle.

My case differs from the opening report in one respect that may be useful for diagnosis: the purchase was not pending. It was completed, receipted by OpenAI, and confirmed by the issuing bank. The credits ledger also loads successfully rather than failing — and it reports a figure that directly contradicts the displayed balance.

Environment

Product: ChatGPT Desktop app, Work module (Codex CLI not used)
App version: 26.721.81911 (released 29 Jul 2026)
Platform: Windows 11 Home Single Language, 25H2, OS build 26200.8894, x64
Subscription: ChatGPT Plus, subscribed 28 July 2026
Account: personal, single account, no workspace
Models in use: gpt-5.6-sol, gpt-5.6-terra
Region: India

The reconciliation failure

Credits purchased (30 Jul 2026)     500.00
Credits shown as consumed            20.21
Expected remaining balance          479.79
Actual displayed balance              0.00
Unexplained                         479.79

The Codex and Work analytics usage table shows exactly one credit event for the entire 7-day window:

Jul 30, 2026 | Desktop (Work) | 20.21 credits

Pagination confirms 1–1 of 1 usage events. There is no second entry, no adjustment, no expiry event, and no error state accounting for the remaining 479.79 credits.

Concurrent state

Weekly usage limit: 0% remaining, resets 5 August 2026 10:56 AM
Credits balance: 0 — shown identically in the desktop app Usage & billing panel and in ChatGPT web Settings → Usage
Auto-reload / auto top-up: confirmed not enabled, before and after the purchase
No local agent, background process, scheduled task, or automated run active during the affected window

Timeline

28 Jul 2026 — Subscribed to Plus. Charge posted, status Paid.
29–30 Jul 2026 — Work module used on desktop. 125 turns across the 7-day analytics window.
30 Jul 2026 — In-app warning that plan usage was running out.
30 Jul 2026, ~18:12 IST — Purchased 500 credits for ₹2,006 (₹1,700 + 18% GST). Payment authorised by the issuing bank within seconds. OpenAI invoice and receipt both issued, both marked Paid.
30 Jul 2026, ~18:12–21:00 IST — No work performed. Desktop app closed.
30 Jul 2026, ~21:00 IST — Returned to Work module. Zero credits, "You're out of Codex and Work usage".

Elapsed time from a completed 500-credit purchase to a zero balance: under three hours, with 20.21 credits recorded as consumed.

Why this may be a distinct signal

The opening report describes credits showing zero while payment is pending externally, which is consistent with a posting delay. My case rules that explanation out. The payment settled and was receipted, and the balance still reached zero with the ledger contradicting itself rather than failing to load.

That suggests the defect is not only a lifecycle display gap. Either the entitlement was never posted despite settlement, or it was posted and then reversed without generating a durable account event — which is precisely the failure mode this issue asks to be made visible.

Related open reports describing the same pattern: #19536, #17764.

Evidence available

Timestamped screenshots of the analytics usage table, both balance panels, the billing history, the OpenAI invoice and receipt, and the issuing bank confirmation. No account identifiers, payment identifiers, or balances beyond those above are included here. Invoice and receipt numbers are available to OpenAI staff on request through a support channel.