›_ Codex Issues
Codex Issues / #31125

Sudden 80%→0% Codex usage drop on Pro plan, unaddressed by support (recurrence of "Codex Usage Limits Depleting Faster Than Expected")

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

On the Pro plan (100 EUR/mo), my 5-hour usage meter dropped instantly from 80%+ remaining to 0% mid-session, after only 6-7 messages using GPT-5.5 xhigh, with no warning banner. Session was compacted only once; I was not running multiple sessions/tabs. Client: Codex app. Version 26.623.101652 (Jul 3, 2026). This has happened multiple times over the past weeks despite an unchanged workflow (Claude generating a plan, Codex adversarially reviewing it, in one continuous session).

This closely matches the previously acknowledged status.openai.com incident "Codex Usage Limits Depleting Faster Than Expected" (June 29, 2026, marked resolved) - suggesting a possible recurrence/regression.

I raised this with OpenAI support (case #10958570) and received three separate templated responses that didn't engage with the specifics - one claimed the June 29 incident was unrelated without explanation, another referenced "account cancellation" which was never mentioned. No indication that session/usage logs were actually reviewed.

Related: #29895, #30939, #28065, #30918

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.

  • #30939
  • #30660
  • #30918
  • #29955
  • #29895

Powered by Codex Action

axisrow · 1 month ago

+1 — same root cause here, and I have a reproducible local trace.

Hit two consecutive 5h windows exhausted on 2026-07-05 with the same workflow you describe (Claude generates a plan, Codex adversarially reviews it). The only local audit tool (ccusage, reads ~/.codex/sessions/) showed just $8.78 for that day — nowhere near enough to drain two windows. So the rest of the spend is invisible locally.

I traced it: codex-plugin-cc → codex app-server spawns ephemeral threads that:

  • really call the model (gpt-5.5 xhigh) — 2,576 API calls across 10 threads,
  • are billable server-side (visible in the web dashboard, Exec category),
  • but write no rollout transcript locally and are absent from the thread catalog — so ccusage and any local audit see $0 for them.

In other words: app-server sessions are bill in the cloud, log nothing locally. The join keys (thread_id, turn_id) already exist in local telemetry (~/.codex/logs_2.sqlite); only the token numbers are server-side.

Full write-up with the 10-thread timeline (anonymized) and the request for a read-only per-thread usage API:
https://github.com/openai/codex/issues/30918#issuecomment-4889081159

Tl;dr of the ask: (a) a read-only API for per-thread/per-turn usage keyed by thread_id, and (b) persist token_count-style usage locally for app-server sessions like Codex Desktop does for interactive ones. Either would make these "limits draining faster than expected" reports actually triageable. 👍 if you'd use the usage API.

agentHits · 1 month ago

@jif-oai @anp-oai @pakrym-oai @rka-oai @bolinfest @etraut-openai @xl-openai @aibrahim-oai @cconger @sayan-oai @canvrno-oai @celia-oai @owenlin0 @richardopenai @tamird @charlesgong-openai @felixxia-oai @fcoury-oai @viyatb-oai @adaley-openai @apanasenko-oai @shijie-oai @iceweasel-oai @won-openai @guinness-oai @jameswt-oai @rhan-oai @wiltzius-openai @winston-openai @codex @ericning-o @stefanstokic-oai @abhinav-oai @alexsong-oai @dylan-hurd-oai @charliemarsh-oai @fjord-oai @mchen-oai @mzeng-openai @nornagon-openai @adrian-openai @fc-oai @marksteinbrick-oai @zanie-oai @ddr-oai @gpeal @rasmusrygaard @xli-oai

Codex app-server / plugin usage spike without enough local token audit data

I observed a serious Codex usage/accounting issue that may be affecting some users.

Related reports:

From the available reports, the pattern looks like this:

  • Codex can consume a large amount of Pro usage unexpectedly.
  • In one case, roughly two 5-hour Pro limits appeared to be consumed during normal project work.
  • Local evidence was limited to around 10 threads and about 2,576 API calls.
  • Local logs did not preserve enough token usage information to explain the actual limit burn.
  • Detailed usage appears to be visible only in the web dashboard, not in local Codex app-server/session artifacts.

This makes the incident difficult to investigate from the user side.

The issue does not appear to be only about one plugin. It may be an interaction between:

  • a specific project workload;
  • Codex app-server behavior;
  • plugin/tooling behavior;
  • missing local token/session usage accounting.

The main concern is not only the limit consumption itself, but the lack of a reliable local audit trail showing exactly which thread, tool call, server-side session, plugin action, or app-server activity caused the token usage.

Expected behavior

Codex should provide a local per-session token usage audit trail for app-server sessions, similar to what Codex Desktop provides.

At minimum, users should be able to inspect:

  • thread/session id;
  • model used;
  • tool/plugin involved;
  • number of API calls;
  • input/output token counts;
  • cached token counts if applicable;
  • total billable or limit-impacting usage;
  • timestamps;
  • enough correlation data to match local sessions with web dashboard usage.

Actual behavior

Large Pro usage can be consumed without enough local token accounting data to identify the root cause.

Impact

This is risky for real development work because a single runaway session, plugin loop, or app-server behavior can drain the available Pro limit without giving the user enough evidence to debug, stop, or report the exact cause.

A useful mitigation would be to store reliable local token usage data for each app-server session, tool call, and plugin interaction.