›_ Codex Issues
Codex Issues / #39260

Credit usage ledger frozen since Aug 8, 2026 — 45,252 of 53,000 purchased credits (85.4%) consumed with zero usage records; ongoing

Open 💬 4 comments Opened Aug 18, 2026 by smsubaie
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

  1. That the credit history views "can lag and may not include some background, sub-agent or tool activity even when it consumes credits."
  2. 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

None of these has a maintainer response or a documented resolution.

What would help

  1. Confirmation of whether the credit-history write path can silently stop while metering continues, and whether that is what happened here.
  2. Whether codex-auto-review consumption 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.
  3. 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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 9 days ago

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

  • #38984
  • #38294
  • #39167

Powered by Codex Action

smsubaie · 9 days ago

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:

  • Windows / Codex desktop is the affected surface in most reports (mine: 96.4% of all recorded credit consumption came from the Work desktop surface)
  • Credits are purchased after the weekly quota is exhausted, then drain far faster than any issued work would justify
  • Drain continues with zero user-issued tasks — #38294 reports ~9 hours of consumption while the reporter was asleep, #38984 reports credits held in reserve draining by themselves
  • The usage log / analytics shows nothing corresponding
  • All five are open with no maintainer response

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:

  • 53,000 credits purchased across 8 sequential invoices, $2,438.00 including VAT
  • 7,406 credits documented in the usage log, all dated 6–8 August
  • 342 credits currently remaining
  • 45,252 credits (85.4%) with no record at any date = $2,081.59 including VAT

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 · 9 days ago

<img width="1547" height="794" alt="Image" src="https://github.com/user-attachments/assets/66075c5a-62f4-456e-a2d2-6c67de60a43e" />
<img width="1546" height="795" alt="Image" src="https://github.com/user-attachments/assets/0deb297b-65e0-4f11-8d93-6a2430e17cb1" />

Two screenshots from today, 18 August, UI in English:

  1. 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.
  2. 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 · 12 hours ago

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-review attribution. The tracker explicitly keeps ledger/analytics failures separate from quota-weighting and workflow-amplification hypotheses while correlating them.