[Windows Desktop 26.831.11858] General quota banner blocks GPT-5.3-Codex-Spark despite separate quota; same-account CLI succeeds

What version of the Codex App are you using?

Codex Desktop for Windows, 26.831.11858, released August 31, 2026.

Standalone control client: Codex CLI 0.152.0.

What subscription do you have?

ChatGPT Pro, personal account. No Business or Enterprise workspace is involved.

What platform is your computer?

Windows x64 (Microsoft Windows NT 10.0).

What issue are you seeing?

The Windows Codex desktop app applies the exhausted general Codex/Work allowance as a composer-wide hard stop even while GPT-5.3-Codex-Spark is selected and its separate Spark allowance remains available.

The desktop banner says:

You’re out of Codex and Work usage

At the same time, the usage surfaces show approximately:

General Codex/Work allowance: exhausted
GPT-5.3-Codex-Spark 5-hour allowance: 100% remaining
GPT-5.3-Codex-Spark weekly allowance: ~98% remaining

The app’s picker displays 5.3 Codex Spark Light; Light is the selected reasoning effort, and the model is GPT-5.3-Codex-Spark.

This is not merely a stale percentage display. A request using the exact Spark model succeeds immediately through the standalone CLI with the same ChatGPT account and quota state, while Desktop blocks before submission.

Steps to reproduce

1. Use the general Codex/Work allowance until it is exhausted while the separate GPT-5.3-Codex-Spark allowance still has capacity.
2. Open Codex Desktop 26.831.11858 on Windows.
3. Start a completely new thread.
4. Select No project.
5. Select 5.3 Codex Spark Light before sending the first message.
6. Use Ask for approval/manual approval.
7. Enter a minimal one-line prompt.
8. Observe that the composer remains blocked by You’re out of Codex and Work usage.

Same-account control test

Run:

& "$env:ProgramFiles\nodejs\npx.cmd" -y "@openai/codex@latest" exec --skip-git-repo-check -m gpt-5.3-codex-spark "Reply only with OK."

Result:

OpenAI Codex v0.152.0
model: gpt-5.3-codex-spark
response: OK
session id: 01a05dc4-013a-7ce3-88c4-bdb91c1ec86a

This demonstrates that the account entitlement is active, the Spark bucket is usable, and the backend serves the selected model. The failure is specific to the Windows Desktop quota/banner path.

Expected behavior

When the selected model is gpt-5.3-codex-spark and the Spark-specific allowance is available, the desktop composer should remain enabled and submit the request regardless of the exhausted general Codex/Work pool.

A general quota banner must not be treated as an account-wide hard stop for a model charged to a separate available bucket.

Actual behavior

Desktop blocks the selected Spark request at the composer. The same request, account, and model work through CLI.

Possible regression area

This first appeared on a build released the same day as #41742, which added actionable rate-limit banners and recovery gating. That change includes behavior where:

• a rate-limit error places composer input into a recovery hold;
• an authoritative usage refresh installs a backend-owned rateLimitUpsell banner;
• input may remain queued while recovery is pending;
• a banner without a model-specific scope can be treated as applicable to the currently selected model.

A plausible failure state is:

general Codex/Work bucket: exhausted
Spark-specific bucket: available
selected model: gpt-5.3-codex-spark
general rate-limit upsell/banner: present and not correctly excluded for Spark

I cannot establish that the proprietary Desktop shell uses the TUI path identically, so #41742 is a lead rather than a claimed root cause.

Suggested regression test

Construct an account usage response where the general pool is exhausted, the GPT-5.3-Codex-Spark additional limit is allowed, and the active model is gpt-5.3-codex-spark. Verify that:

• the composer remains enabled;
• the Spark turn is submitted;
• the general upsell banner does not create an account-wide hard stop;
• no fallback away from Spark occurs while its separate bucket is available.

Related issues

• #32053 — Spark continuation blocked despite remaining Spark quota
• #23171 — client-side quota state blocks models the server will serve
• #23150 — separate Spark/general bucket accounting
• #41742 — actionable rate-limit banner and recovery changes

Start with the rate-limit banner and recovery path described in #41742, including the TUI path and the model-scoping behavior for rateLimitUpsell. Reproduce the usage state from this issue, then add or run a regression test verifying that an exhausted general pool does not block gpt-5.3-codex-spark when its separate allowance remains available.