Codex GUI blocks prompt submission at 100% usage, including with other models

[chelaxian]

Client or integration

Codex App

Area

Authentication and account pool

Summary

When Codex usage reaches 100%, the Codex GUI disables the prompt submission button. The conversation cannot be continued through the GUI, even after switching to another model. This behavior appeared after a recent update.

Expected behavior

Reaching the Codex model usage limit should not prevent prompt submission with a model that remains available.

Actual behavior

The submit button is disabled for all models. Prompt submission becomes available again only after the usage limit resets. Signing in with another account also restores access.

Suggested improvement

Consider stopping requests to Codex models before usage reaches 100% (for example, at 99%) if that would keep the GUI available for other models.

Environment

• Codex version: 26.917.71314

Reproduction

1. Start OpenCodex with ocx start.
2. Use Codex until the usage limit reaches 100%.
3. Try to submit another prompt, including after switching to a different model.

Version

2.64.0

Operating system

Windows 26H1, build `28000.3086

Provider and model

Any

Logs or error output

ocx start

Screenshots and supporting files

Redacted configuration

//opencodex

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[chelaxian]

edited

[luvs01]

Related to #5694 / #4878 — distinguish the version and Reserve state

This is the same observed Desktop submission-gating symptom family as #5694: the desktop account is exhausted, selecting another model does not enable Send, and the reporter describes recovery after quota reset or an account change. It is not yet a demonstrated provider-side HTTP 429 or proof that the selected model uses an independently authorized upstream.

#4878 records a more specific state: regular and Luna Reserve allowances are both exhausted; the model picker reopens, but Send stays disabled. Reserve status is not given here, so please link the reports without assuming that this exact transition or a shared internal cause has been reproduced.

Important version distinction: this report explicitly names OpenCodex 2.64.0 and Codex App 26.917.71314 on Windows. In the closure comment on #5694, the maintainer identifies 2.65.0 as the release intended to ship the default-on 98% main-account guard from #5743, with the #5748 follow-up. #5743 changes an existing opt-in 99% policy to default-on at 98%. Thus the suggested pre-exhaustion cutoff already has related implementation work; this 2.64.0 report alone is not evidence that the new default failed after installation. Please record the actually running OpenCodex version and effective guard state separately from the Desktop version.

The cutoff is prevention, not recovery: stopping guarded main-account requests before exhaustion does not replenish an account already at 100% or establish that an already-disabled composer will recover. The merged policy explicitly uses observed quota rather than reserving remaining capacity. Traffic outside that guarded path can still consume the same account. A working preventive guard and a remaining post-exhaustion composer problem can therefore coexist.

To connect this Windows report to the existing investigation, the remaining useful evidence is a short redacted summary: the effective provider/auth mode (independent provider vs the same ChatGPT allowance), regular/Reserve availability, effective guard state and whether it was active before exhaustion, and whether an attempted submission reaches the app-server/OpenCodex at all. No credentials, account/thread identifiers, raw prompts or full usage/configuration dumps are needed; no need to deliberately exhaust another account.

The Windows/App-version details are valuable corroboration. Retain recovery at already-exhausted quota as a separate verification case rather than closing it solely on the existence of a pre-exhaustion cutoff. This comment adds cross-issue/version context, not a new local reproduction or a verified workaround for this installation.

[lidge-jun]

This is addressed in v2.65.0.

OpenCodex now stops routing requests to the main Codex account at 98% usage, before the upstream account reaches 100% and the Codex App disables the Send button. The lock is on by default:

• fix(codex): bundle L4 — service uninstall key, startup rollout budget, sub-agent identity, agent-message recovery, 98% main lock #5743 lowered the main-account hard lock threshold to 98% (MAIN_ACCOUNT_HARD_LOCK_PERCENT = 98).
• Codex send button grayed out of after 0% usage #5694 made the lock default-on. It is disabled only if codexMainAccountHardLock: false is explicitly saved in the config.

To pick it up, update with npm install -g @bitkyc08/opencodex@latest (or the desktop app updater) and restart the proxy. If you previously turned the lock off, re-enable it in the dashboard or remove codexMainAccountHardLock: false from your config.

If the Send button still becomes disabled on v2.65.0 or later, please reopen this issue with your version and the usage percentage at the time. A configurable threshold is tracked separately in #5649.

[chelaxian]

98%-safeguard not works. Codex bypass it and derive usage to 100%.