[Pro 20x] Severe 7-day quota depletion during light workloads + frequent "Selected model is at capacity" with usage remaining

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.81509

What subscription do you have?

Pro 20x

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

I am currently experiencing two severe issues on a ChatGPT Pro 20x subscription:

1. The 7-day Codex usage allowance is being consumed dramatically faster than expected, including during relatively light workloads.
2. Codex frequently returns Selected model is at capacity. Please try a different model. despite substantial usage allowance still being available.

I am reporting these together because both issues are currently making the effective Pro 20x capacity dramatically less usable.

I am not assuming that they necessarily share the same root cause. They may be separate regressions involving usage accounting / entitlement and model serving / routing.

Bug 1: Pro 20x 7-day quota is depleting abnormally fast

I have observed multiple cases where the amount of visible work performed by Codex appears completely disproportionate to the percentage deducted from the Pro 20x 7-day allowance.

Case A: ordinary frontend positioning fix

The task was a normal frontend development task involving a UI/page element whose positioning was drifting.

Conditions:

• No image recognition or vision input.
• No large document ingestion.
• No unusually large data-processing workload.
• No Fast Mode.
• Runtime: approximately 50 minutes.

Observed usage:

Approximately 11 percentage points of the entire Pro 20x 7-day allowance were consumed in about 50 minutes.

Normalized representation of the measured delta:

Pre-task weekly remaining quota: 100% baseline
~50 minutes later: ~89% of that baseline
Consumed: ~11 percentage points

### What steps can reproduce the bug?

## Reproduction A: abnormal weekly usage during an ordinary frontend task

1. Use a ChatGPT Pro 20x account with available 7-day Codex usage.
2. Record the current 7-day usage percentage.
3. Start an ordinary frontend coding task involving a relatively small page-positioning/layout issue.
4. Do not provide image or vision input.
5. Use normal/Standard Codex operation rather than Fast Mode.
6. Let Codex work for approximately 50 minutes.
7. Check the 7-day usage meter again.

Observed in my case:

> Approximately **11 percentage points of the Pro 20x 7-day allowance were consumed in ~50 minutes**.

---

## Reproduction B: external CLI orchestration

1. Record the current Pro 20x 7-day usage percentage.
2. Ask Codex to invoke another CLI tool to analyze documents.
3. Let the external CLI perform the actual document analysis.
4. Codex should mainly send instructions to that CLI without independently performing substantial analysis or additional command execution.
5. Check the usage meter after a little over one minute.

Observed in my case:

> Approximately **2–3 percentage points of the Pro 20x 7-day allowance were consumed in just over one minute**.

---

## Reproduction C: model capacity error

1. Use Codex normally while substantial 5-hour / 7-day usage allowance is still available.
2. Start or continue a task using a GPT-5.6 model.
3. Codex intermittently or repeatedly returns:
> Selected model is at capacity. Please try a different model.
4. Retry the task or switch among GPT-5.6 models.
5. The capacity failure may continue even though the account has not exhausted its usage allowance.

- session id:
- 019ff8f5-9b9f-7e63-ae74-25240cf72c68
- 019fb0d2-9120-7581-909d-da9a88bf8414
- ......

### What is the expected behavior?

For usage accounting:

- A Pro 20x subscription should receive the effective usage allowance associated with the Pro 20x tier.
- Ordinary workloads should not unexpectedly consume a very large fraction of the weekly allowance without corresponding visible model activity.
- Waiting for an external CLI or background process should not silently generate large amounts of model usage.
- Automatic polling, retries or waiting should not repeatedly resubmit large contexts at significant quota cost without making that activity visible.
- Failed requests, cached input, compaction, subagent activity and background execution should have transparent quota treatment.
- Usage should be attributable to a specific thread/task.

If the observed consumption is considered correct, Codex should expose enough per-task telemetry to explain how the usage was calculated, including:

- input tokens;
- cached input tokens;
- output/reasoning tokens;
- number of model requests;
- retries;
- compactions;
- subagent requests;
- background requests;
- service tier;
- quota charged to the 5-hour limit;
- quota charged to the 7-day limit.

For model capacity:

- Remaining subscription quota and real-time model-serving capacity should be clearly distinguished.
- Temporary capacity failures should be treated as retryable infrastructure/admission failures where possible.
- Codex should retry with reasonable backoff rather than immediately terminating an active task.
- Existing task state should be preserved.
- The UI should clearly distinguish model capacity, account quota exhaustion, entitlement/routing issues and other rate-limit conditions.

### Additional information

## Potentially related quota / usage-accounting reports

- #38157 — ChatGPT Pro (20x) accounts appear to receive Pro 5x Codex usage capacity
- #38191 — 7-day usage remaining jumped from 48% to 23%
- #38233 — GPT-5.6 Sol normal mode appears to consume Codex quota unusually fast
- #38309 — Usage quota drops by ~50% immediately after reset without any activity

My report adds two workload-specific observations:

1. **~11% of the Pro 20x weekly allowance consumed by an ordinary ~50-minute frontend positioning fix.**
2. **~2–3% of the Pro 20x weekly allowance consumed in just over one minute while Codex mainly instructed another CLI to perform the actual document analysis.**

Possible areas worth investigating include:

- Pro 20x entitlement / effective quota provisioning;
- cached-input accounting;
- automatically injected system/plugin/skill/tool context;
- repeated model sampling while waiting for external commands;
- aggressive polling / `wait` behavior;
- invisible retries;
- background or stale tasks;
- subagent activity;
- context compaction / replay;
- duplicated or delayed usage events;
- incorrect service-tier assignment;
- server-side rate-limit reconciliation.

## Potentially related capacity reports

- #37790 — Pro 20x, frequent capacity errors making Codex nearly unusable
- #37795 — Pro 20x, persistent capacity errors despite sufficient remaining quota
- #37935 — Pro 20x, repeated capacity failure during normal use
- #37944 — repeated `Selected model is at capacity`
- #37959 — GPT-5.6 Luna Max capacity error in Codex CLI
- #28507 — earlier tracker for the same exact capacity error

Recent reports span different subscription tiers, Codex Desktop / CLI and multiple GPT-5.6 variants, so the capacity symptom does not appear isolated to a single local environment.

And, on a lighter note:

@tibo-openai St. Tibo, the quota resets are appreciated, but resets alone don't help much when the effective usable allowance feels like it has been cut to less than one tenth of what it should be, and every now and then Codex also says "Selected model is at capacity" and simply refuses to work. 😅

At that point we're getting the tank refilled, but the tank seems to have shrunk to less than 10% of its old size, and sometimes the pump is locked anyway.

No repository file, test, or entry point is named. Start by comparing the reported 7-day usage deltas in Reproductions A and B and the GPT-5.6 capacity failures in Reproduction C, using the supplied session IDs and related issues for context. Done would require identifying whether these are separate defects and defining observable quota and capacity behavior.