Codex GUI blocks prompt submission at 100% usage, including with other models #5797
Description
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
- Start OpenCodex with
ocx start. - Use Codex until the usage limit reaches 100%.
- 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 startScreenshots and supporting files
Redacted configuration
//opencodexChecks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
github-actions commentedon Sep 24, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
chelaxian commentedon Sep 24, 2026
edited
luvs01 commentedon Sep 25, 2026
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 commentedon Sep 25, 2026
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:
MAIN_ACCOUNT_HARD_LOCK_PERCENT = 98).codexMainAccountHardLock: falseis 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 removecodexMainAccountHardLock: falsefrom 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 commentedon Sep 25, 2026
98%-safeguard not works. Codex bypass it and derive usage to 100%.
feat(codex): add an on-demand native queue fallback for blocked compo…