Skip to content

Weekly Codex limit exhausted immediately after purchasing Plus; usage attribution is unclear #34066

Open

Description

@ardjo-s

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

  1. Purchase or reactivate ChatGPT Plus.
  2. Open Codex Desktop and use a repository project with one long-lived orchestration thread and a small number of implementation subthreads/worktrees.
  3. Open Codex Settings → Usage & billing.
  4. Observe that Weekly usage reports 0% left / Limit reached immediately after the plan purchase, with the reset almost a full week away.
  5. 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:

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.

Image Image

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    on Jul 18, 2026
  2. github-actions commented on Jul 18, 2026

    @github-actions
    Contributor

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

    Powered by Codex Action

  3. ardjo-s commented on Jul 18, 2026

    @ardjo-s
    Author
  4. ardjo-s commented on Jul 18, 2026

    @ardjo-s
    Author

    Potentially related to my MCP lifecycle report: #33700.

    #33700 shows a reproducible macOS App multiplier: completed/interrupted subagents remain open in state_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.

  5. phyrexia commented on Jul 31, 2026

    @phyrexia

    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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingrate-limitsIssues related to rate limits, quotas, and token usage reporting

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions