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

No files, tests, or implementation entry points are identified. Start by locating the shared usage-accounting and pre-run agent execution flows, then determine how remaining quota, estimates, confirmations, and post-run breakdowns would be represented and tested.

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.