Skip to content

Shared agentic usage pool can exhaust a weekly Codex limit within hours without an adequate warning #33691

Open

Description

@michycom

Summary

Codex, ChatGPT Work/Agents, and other agentic features now draw from a shared agentic usage pool. In practice, this can cause a user's entire weekly Codex allowance to be exhausted within a very short period, without a clear pre-run warning, cost estimate, or confirmation proportional to the amount of quota about to be consumed.

This is especially problematic for long-running or high-reasoning tasks whose actual quota cost is not visible in advance. A user may reasonably choose the strongest available model and allow an agentic task to continue, only to discover afterward that nearly the entire weekly allowance has been consumed and Codex is unavailable for the rest of the week. The completed work may also be incomplete or not provide a quantitatively or qualitatively proportionate benefit for the quota consumed.

Observed case

  • Subscription: ChatGPT Plus
  • Date: July 15, 2026
  • Weekly usage reset shown at approximately 15:23 local time
  • After roughly two hours of agentic/Codex use, Codex reported that the limit had been reached
  • Next reset shown: July 22, 2026 at 15:23
  • Previously, high usage generally resulted in shorter temporary rate limits rather than an immediate week-long lockout
  • Agent runs had previously appeared to have a separate limit; the new shared accounting was not sufficiently apparent before the work started

I cannot determine from the UI exactly which run, model, or product consumed which percentage of the shared pool.

Why this is a user-facing problem

The issue is not merely that usage is limited. The problem is that the product does not provide enough information for a user to make an informed decision before committing a large portion of a weekly allowance.

At minimum, users need to know:

  • that Codex and the relevant agentic products share the same pool;
  • the remaining percentage or credits before starting a task;
  • an approximate cost range for the selected model and task mode;
  • whether a single run is likely to consume a substantial portion of the remaining weekly allowance;
  • which product, model, and run consumed the quota afterward.

Without that information, the effective amount of usable service is unpredictable even immediately after a weekly reset.

Expected behavior

Before starting or continuing an unusually expensive run, show a warning such as:

This task may consume a substantial portion of your remaining weekly agentic usage. Continue?

For very high estimated consumption, the warning should state the approximate percentage or credit range. A warning would be particularly appropriate when a run could consume, for example, more than 25%, 50%, or nearly all of the remaining weekly allowance.

The usage page should also provide a breakdown by:

  • Codex / Work / other agentic product
  • model
  • local, cloud, or remote execution
  • task or session
  • timestamp
  • estimated or final usage cost

Requested improvement

  1. Add a persistent remaining-usage indicator in Codex and other products sharing the pool.
  2. Add a pre-run estimate or at least a low/medium/high cost classification.
  3. Require explicit confirmation before a task can consume an unusually large share of the remaining weekly quota.
  4. Show a detailed post-run usage breakdown.
  5. Clearly announce changes that merge formerly separate limits before they take effect.
  6. Avoid allowing one incomplete or low-value run to silently consume nearly an entire weekly allowance without any intervention point.

This report is about transparency, predictability, and informed consent around shared usage accounting, not a request for unlimited usage.

Activity

  1. added
    enhancementNew feature or request
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    on Jul 16, 2026
  2. github-actions commented on Jul 16, 2026

    @github-actions
    Contributor

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

    Powered by Codex Action

  3. andreszs commented on Jul 24, 2026

    @andreszs

    I am experiencing the same issue and have also created a separate post about it here:

    Stop Hiding Weekly Usage: ChatGPT Work Now Drains the Codex Quota Without Warning

    The lack of a clear, persistent usage indicator—combined with the poorly explained shared quota between Codex and ChatGPT Work—is causing unnecessary confusion for paying users.

    I am linking the discussions so the reports can be cross-referenced and the broader impact of this issue is easier to see.

  4. Depoch commented on Aug 4, 2026

    @Depoch

    I agree with the pre-run warning request, but recommend not putting a second model loop in front of every task. That would add latency and consume the quota it is trying to protect, while still producing false precision for path-dependent agent work.

    V1 can be deterministic using data the client/runtime already has:

    • current rate-limit percentage and reset time;
    • remaining credit/spend-control state when available;
    • model, reasoning effort, and speed tier;
    • current context, prompt/attachment, and tool-schema size;
    • Goal/long-running mode;
    • explicit multi-agent/high/ultra configuration;
    • queue depth and concurrent work;
    • obvious broad scope such as full repository, all files, complete migration, or full test suite.

    Return Normal / Elevated / High / Unknown plus an approximate range, not an exact cost claim. Do not interrupt normal tasks. Warn only when the predicted upper range is large relative to the constraining remaining window, when the run could leave very little headroom, or when a user-set credit threshold would be crossed.

    The Voice UX can be one sentence plus a card: “This looks like a large run, and you have 18% left until tomorrow. Run it, use Efficient mode, or plan only?” Efficient mode must disclose exactly what changes—lower effort, fewer subagents, or staged scope—and never silently downgrade work.

    To avoid repetitive confirmations: warn at most once per root task; let steers inherit the decision unless they materially expand scope; reassess queued work at dequeue but interrupt only if conditions materially worsened; and offer a revocable “Don’t ask again this session” policy. If Voice disconnects while a decision is pending, fail closed and preserve the card for reconnection.

    This could begin entirely without a model estimator: existing App Server quota snapshots plus current execution settings are enough for a useful, calibratable safety gate. A tiny estimator should be considered later only for low-confidence boundary cases.

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

    enhancementNew feature or requestrate-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