Feature Request: Optional queueing of prompt submissions when usage limit is reached

What variant of Codex are you using?

App

What feature would you like to see?

Add an optional way to queue prompt submissions when a usage limit is reached, instead of immediately failing the request.

Today, when the limit is reached, the request fails with a message like:

"You've hit your usage limit. Upgrade to Pro (https://chatgpt.com/explore/pro), visit https://chatgpt.com/codex/settings/usage to purchase more credits or try again at X"

This interrupts workflows and forces manual retries even when the app already knows the relevant reset time and already shows usage / upgrade UI.

Problem

When the usage limit is reached:

• the current submission fails immediately
• I have to come back later and manually resend it
• the error message is somewhat redundant because the app already surfaces usage information and upgrade / credits actions elsewhere

This is especially disruptive for longer-running workflows, when I would prefer to "send and let it run when available" rather than keep retrying manually.

Proposed solution

Introduce an optional queue-on-usage-limit behavior for prompt submissions.

If enabled, when a submission hits a usage limit:

• the submission is retained as pending instead of being treated as a final failure
• the thread/composer shows a clear queued state, e.g.:
• Queued until 3:15 PM
• or Queued - will retry when usage resets
• once the relevant limit resets, Codex automatically retries the queued submission

If disabled, keep the current behavior exactly as it is today.

Suggested behavior

When a usage limit is hit

If queueing is enabled:

• do not discard the prompt
• place it into a pending queue
• show a visible status in the UI
• allow the user to:
• cancel it
• edit/remove it
• optionally switch models

If queueing is disabled:

• preserve current behavior
• show the normal error message

When the limit resets

• automatically retry queued submissions
• process them in FIFO order
• re-check current auth / model availability before retrying

Suggested config

A simple first version could be a single toggle in the App such as:

• Enable prompt queueing when usage limit is reached

Possible config names:

[usage_limits]
queue_when_limited = true

or

[experimental]
queue_on_usage_limit = true

Scope suggestion

I think this should apply to new prompt submissions that fail because of usage limits.

I am not suggesting that partially executed tool actions or in-flight side effects should be resumed blindly. This seems safer if it is limited to replaying a prompt submission that never actually got to run because the usage limit blocked it.

Why this would help

• removes manual retry friction
• makes reset times actually actionable
• improves long-running / async workflows
• matches user expectations better when the app already knows "try again at X"
• reduces repeated failed attempts caused by users checking whether the limit has reset yet

Notes

This seems to fit the existing app UX well because Codex already surfaces usage-limit messaging and rate-limit information. This request is mainly about improving the behavior after that state is reached.

A minimal version would already be very useful if it only:

• queues one pending submission per thread
• shows Queued until <time>
• retries automatically once limits reset

Additional information

_No response_