Repository navigation
Credit usage ledger frozen since Aug 8, 2026 — 45,252 of 53,000 purchased credits (85.4%) consumed with zero usage records; ongoing #39260
Description
Summary
The Credit Usage Log in Codex → Settings → Analytics stopped recording on 8 August 2026 and has not written a single entry since. Its most recent row today, 18 August, is byte-for-byte identical to what it showed on 16 August: 43 events, all dated 6–8 August, totalling ~7,406 credits.
During those ten days I purchased 43,000 additional credits across seven invoices. All of them were consumed or lost. None produced a single ledger entry.
This is not the documented 1–6 hour analytics delay. The gap is ten days and still growing.
Reconciliation
| Invoice | Date | Qty | Ex-VAT | VAT (15%) | Total |
|---|---|---|---|---|---|
| 8159F611-0024 | 6 Aug 2026 | 10,000 | $400.00 | $60.00 | $460.00 |
| 8159F611-0025 | 15 Aug 2026 | 25,000 | $1,000.00 | $150.00 | $1,150.00 |
| 8159F611-0026 | 15 Aug 2026 | 7,000 | $280.00 | $42.00 | $322.00 |
| 8159F611-0027 | 15 Aug 2026 | 2,000 | $80.00 | $12.00 | $92.00 |
| 8159F611-0028 | 15 Aug 2026 | 7,500 | $300.00 | $45.00 | $345.00 |
| 8159F611-0029 | 17 Aug 2026 | 500 | $20.00 | $3.00 | $23.00 |
| 8159F611-0030 | 17 Aug 2026 | 500 | $20.00 | $3.00 | $23.00 |
| 8159F611-0031 | 18 Aug 2026 | 500 | $20.00 | $3.00 | $23.00 |
| Total | 53,000 | $2,120.00 | $318.00 | $2,438.00 |
Every invoice carries a single line item, Credits, at $0.04 each. All were purchased from Codex → Settings → Usage → Credits.
Purchased .................. 53,000 credits
Documented in usage log ...... 7,406 credits (43 events, all 6–8 Aug)
Current balance .................. 342 credits
─────────────────────────────────────────────
Unaccounted ................. 45,252 credits = 85.4%
At the invoiced rate that is $1,810.08 ex-VAT / $2,081.59 including VAT.
The most recent case is the cleanest: 1,500 credits purchased on 17–18 August, balance now 342. 1,158 credits consumed in roughly one day with zero ledger entries.
Environment
- Plan: ChatGPT Pro 20x (active continuously since at least Aug 2025)
- Surfaces in use: Codex desktop (Work), Codex Desktop App, Cloud, web, mobile
- Auto-recharge: never enabled (verified — the settings dialog is an empty setup form with no payment method attached and the Enable button greyed out)
- GitHub account: not linked (the Codex page displays "Your GitHub account is not linked")
- Weekly rate limit: currently 100% consumed
Where the consumption actually goes
The Rounds chart (8,190 rounds over the period) attributes the overwhelming majority to codex-auto-review:
| Day | codex-auto-review | gpt-5.6-sol | gpt-5.6-luna | gpt-5.6-terra |
|---|---|---|---|---|
| 4 Aug 2026 | 1,241 | 79 | 9 | 6 |
| 13 Aug 2026 | 1,284 | 41 | 5 | 5 |
That is over 95% of all rounds from a process that runs automatically, on an account with no linked repository.
By surface, in the only period the ledger did record (6–8 Aug), the split was:
| Surface | Credits | Share |
|---|---|---|
| Desktop (Work) | 7,143 | 96.4% |
| Mobile | 156 | 2.1% |
| Cloud | 45 | 0.6% |
| Web | 38 | 0.5% |
| Desktop App | 24 | 0.3% |
Individual Work-desktop events reached 2,219 credits in a single entry, against 0.02–8 credits for the same models on other surfaces.
What support has confirmed in writing
Two statements from OpenAI support, both relevant to this repository rather than to billing:
- That the credit history views "can lag and may not include some background, sub-agent or tool activity even when it consumes credits."
- That there is "no public documentation that explains [codex-auto-review's] exact trigger conditions or a supported way to disable it."
The first is an acknowledgement that the metering surface is known to be incomplete. The second means a process consuming >95% of rounds is neither auditable nor controllable from the product UI. (auto_review.policy and approvals_reviewer do exist in the config reference, so the second statement appears to be a documentation gap on the support side rather than a genuine absence.)
Why this looks like a ledger bug, not usage
- The ledger froze on a specific date and has not resumed for ten days, across five different surfaces.
- Purchases made after the freeze produce no entries at all — not partial, not delayed.
- The balance still decrements correctly. So consumption is being metered somewhere; only the user-visible ledger stopped being written.
- Reloading, changing the date range, and re-authenticating do not change the result.
That combination points at a write path from the metering service to the credit-history store, not at unreported-but-real usage.
Related
- Credits were successfully added and visible (~2300 total), then later disappeared completely, dropping to 0 without any corresponding usage records after April 8, 2026. #19242 — same signature: credits purchased after the last recorded usage entry, balance dropping to zero, no records. Open, no maintainer response.
- Multiple community reports describing the identical pattern:
- https://community.openai.com/t/codex-cloud-credits-disappeared-from-analytics/1380355
- https://community.openai.com/t/codex-chatgpt-credits-disappeared-usage-history-missing-and-support-keeps-giving-ai-generated-loop-responses/1381561
- https://community.openai.com/t/purchased-codex-credits-seem-to-disappear-far-faster-than-subscription-usage/1388784
- https://community.openai.com/t/codex-credits-dissappearing/1366891
- https://community.openai.com/t/title-500-purchased-codex-credits-fell-to-29-68-between-recorded-sessions-support-says-it-cannot-verify-what-consumed-them/1389679
- https://community.openai.com/t/purchased-1000-credits-gone-in-under-an-hour/1378847
None of these has a maintainer response or a documented resolution.
What would help
- Confirmation of whether the credit-history write path can silently stop while metering continues, and whether that is what happened here.
- Whether
codex-auto-reviewconsumption is expected to appear in the Credit Usage Log at all, or whether sub-agent activity is excluded by design. If excluded by design, that should be documented, because it makes the ledger unusable for reconciliation. - A way to recover or reconstruct the internal ledger for 6–18 August for this account.
I have the full invoice and receipt PDFs for all eight transactions, plus screenshots of the frozen ledger taken 48 hours apart showing identical content. Happy to supply the account identifier privately to anyone who can look it up — the invoice prefix 8159F611 maps to a single Stripe customer record.
Support case reference: 13260716.
Activity
github-actions commentedon Aug 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
smsubaie commentedon Aug 18, 2026
Thanks — I've reviewed all three. I don't think this should be closed as a duplicate, but they are clearly the same cluster and I'm happy to consolidate if maintainers prefer.
Shared signature across #39260, #38984, #38294, #39167 and #19242:
One detail from #38294 that I think reframes this cluster: the reporter exceeded a hard cap of 5,000 credits by roughly 7x, and a 10,000 cap by roughly 4x. If the cap is not enforced and the ledger stops recording, the failure is not in the reporting layer alone — it points at the metering/enforcement service itself. That would also explain why my balance decrements correctly while nothing is written to the credit history.
What this issue adds that the others don't have: a complete invoice-level reconciliation. Because every invoice states the unit price ($0.04/credit), the loss can be quantified exactly rather than estimated:
Plus two statements from OpenAI support in writing: that the credit history views "may not include some background, sub-agent or tool activity even when it consumes credits", and that there is no documented way to disable
codex-auto-review, which accounts for >95% of my rounds.If it's useful, the cleanest reproduction in this cluster is probably mine on 17–18 August: 1,500 credits purchased, 1,158 consumed within roughly one day, zero ledger entries, on an account with no linked GitHub repository and auto-recharge never enabled.
Happy to run any diagnostic or provide the account identifier privately to whoever picks this up.
smsubaie commentedon Aug 18, 2026
Two screenshots from today, 18 August, UI in English:
Credits usage history— the table still starts at Aug 8, 2026 and every visible row carries that date. Nothing has been written for ten days.Credits remaining: 0,Weekly usage limit 0% remaining, resetting Aug 20, 2026 6:31 AM.Worth noting: when I began checking this account earlier today the balance read 342 credits. It reached 0 roughly an hour later, with no ledger entry written for that consumption either. The failure is live, not historical.
FromAriel commentedon Aug 27, 2026
Cross-linking this purchased-credit/ledger reconciliation case to #41220, a meta tracker for abnormal Codex usage/quota depletion and usage-accounting inconsistencies. This report adds a distinct but important evidence class: the balance continues to decrement while the user-visible credit ledger does not reconcile the consumption, with unusually large
codex-auto-reviewattribution. The tracker explicitly keeps ledger/analytics failures separate from quota-weighting and workflow-amplification hypotheses while correlating them.sergeyzm-dot commentedon Aug 31, 2026
I’m seeing a very similar issue on a ChatGPT Pro subscription with managed GitHub Auto Review.
In my case, roughly 15 fairly simple PR code reviews can consume my Codex quota all the way to zero. These are ordinary code reviews where I absolutely do not need the most capable/expensive model.
What makes this especially frustrating is that my Usage reports show these reviews being attributed to GPT-5.6 Sol. For this workload, Sol is unnecessary — GPT-5.6 Terra would be more than sufficient — but I cannot find any supported way to choose the model used by managed GitHub Auto Review while staying on my Pro subscription.
So the practical problem is:
It would be very helpful if OpenAI could either:
At the moment, automatic review is useful, but the quota cost makes it difficult to keep enabled.
D4ttara commentedon Sep 15, 2026
Related data point from a separate ChatGPT Plus account, with local Codex telemetry available.
I initially believed a 250-credit purchase had not been granted, but the local session records corrected that assumption:
So the grant itself is confirmed, while almost 250 credits were consumed in about 23 minutes.
The user-facing Analytics view shows aggregate credit spending, but it still does not provide enough task/turn-level attribution to explain the burn. OpenAI Support told me they cannot provide internal event IDs or per-task server-side ledger attribution by session/thread.
I have not found evidence so far of a large
thread_spawnfan-out in the specific rollout, so I cannot attribute this case to subagents. There is substantial long-session/compaction activity, but I am not treating that as billable cause without evidence.This may therefore be a different backend cause from the frozen-ledger signature reported here, but it reinforces the same auditability problem: the balance can move dramatically while the user has no reliable way to reconcile exactly what consumed the purchased credits.
For anyone investigating similar cases, local
credits.balancesnapshots in~/.codex/sessionscan at least establish whether a credit grant occurred and reconstruct the balance timeline, even when the UI is insufficient.