Repository navigation
Weekly Codex limit exhausted immediately after purchasing Plus; usage attribution is unclear #34066
Description
Codex App version
Codex Desktop build unavailable from the About dialog; codex-cli 0.144.4 is installed locally.
Subscription
ChatGPT Plus (€23/month) with purchased flexible-usage credits.
Platform
Darwin 25.5.0 arm64 (Apple Silicon)
What issue are you seeing?
I purchased or reactivated ChatGPT Plus, but the Codex desktop app immediately showed the weekly limit as fully exhausted.
The official Usage & billing page currently shows:
- Plan: Plus (€23/month)
- Weekly usage: 0% left
- Reset date: 25 July 2026 (about 6d 8h remaining when captured)
- Rate-limit resets: none available
- Current purchased-credit balance: €187.68
A third-party local usage display (OpenUsage/CodexBar) simultaneously reports Limit reached and estimates Extra Usage at $188.12 / 4.7K credits. Earlier during the same day it displayed very large aggregate estimates (about 449.9M tokens today, 277.7M yesterday, and 1.9B over 30 days), but the official Codex UI does not provide enough per-session attribution to reconcile those values or explain why a newly purchased Plus weekly allowance was already at zero.
At the time the limit appeared, no visible task was running that seemed sufficient to explain a complete new weekly allowance being consumed. I need to understand whether this is stale quota state, account/plan entitlement drift, a background agent loop, duplicated subagent accounting, or expected billing behavior.
I am not claiming that the third-party dollar/token estimates are authoritative. The official facts are the Plus plan, 0% weekly remaining, 25 July reset, no reset available, and €187.68 credit balance.
Steps to reproduce
- Purchase or reactivate ChatGPT Plus.
- Open Codex Desktop and use a repository project with one long-lived orchestration thread and a small number of implementation subthreads/worktrees.
- Open Codex Settings → Usage & billing.
- Observe that Weekly usage reports 0% left / Limit reached immediately after the plan purchase, with the reset almost a full week away.
- Observe that no per-thread/session/token breakdown is available to explain the exhaustion.
Affected orchestration session ID: 019f7223-6394-7ae3-ba57-47110d24ff0f
Captured: 18 July 2026, Europe/Paris.
I can provide private account and billing identifiers to OpenAI Support, but I am intentionally not posting them publicly.
Expected behavior
A newly purchased Plus entitlement should either provide the documented included Codex allowance or clearly explain why the allowance is already exhausted. The Usage page should show auditable attribution by session, model, and time window; distinguish included usage from purchased-credit usage; and identify any background or subagent consumption. If the quota state is stale or attached to a previous entitlement period, it should refresh automatically.
Additional information
Potentially related issues:
- Codex CLI: gpt‑5.6‑sol Ultra Fast background loop drained weekly limit #33276 — background loop drained weekly limit
- Codex CLI /status alternates between two actively-decrementing quota states in the same session #31696 — alternating quota states
- Codex CLI and desktop app report usage limit despite Plus account showing available quota #30349 — Plus account quota mismatch
This report differs because the official billing page itself shows the newly purchased Plus plan and 0% weekly remaining at the same time.
I have three screenshots available: the Codex limit card, the official Usage & billing page, and the draft public post describing the immediate reset/limit problem.

Activity
github-actions commentedon Jul 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ardjo-s commentedon Jul 18, 2026
https://x.com/rdjooo/status/2078584139905745201
ardjo-s commentedon Jul 18, 2026
Potentially related to my MCP lifecycle report: #33700.
#33700 shows a reproducible macOS App multiplier: completed/interrupted subagents remain
openinstate_5.sqlite.thread_spawn_edges; restoring the parent then starts one full MCP/plugin helper generation for each stale descendant. The controlled run produced 6 restored contexts, 6 generations, 48 direct child processes, and 3152 MiB RSS; an earlier snapshot reached 11 generations, 99 children, and 3798 MiB RSS.That process-side behavior could explain hidden background/subagent activity relevant to the quota symptoms in this issue, but it is not yet proof that the MCP multiplier alone caused the weekly-limit exhaustion. Please cross-check quota attribution against restored-task/subagent/MCP lifecycle events.
phyrexia commentedon Jul 31, 2026
Same pattern here, on a brand-new account.
After exhausting my reset credits I created a fresh account. Per Codex's own
/usage daily, its entire lifetime is 374M tokens,Streak 1d, longest task 1h40m — lifetime equals peak, because that single task is everything the account ever did. One task consumed the full weekly quota.Client-side telemetry for the same period, including the reset-window behaviour behind it, in #36307 (comment).