Codex 0.152 rate-limit recovery: verify resets, fallback models, and queued prompts
Quick answer
Codex 0.152.0, released on September 1, turns rate-limit notices into recovery actions instead of leaving only a dead-end error. Depending on backend eligibility, a banner can lead you to usage details, credits, an earned reset, an owner notification, a plan page, or a fallback model. The important safety change is less visible: queued prompts remain paused while Codex refreshes the authoritative limit snapshot, and only one queued prompt is released after recovery completes.
Do not treat every stopped turn as “the rate limit.” A rolling usage window, a selected-model limit, a workspace credit cap, an earned reset, and expired Amazon Bedrock credentials have different authorities and recovery paths. Diagnose the state first, take one bounded action, refetch it, and then resume.
The checked stable tag resolves to commit 316795b3cf2a45e90d121d9f46499d4658b2645c. The local CLI available during this review is 0.145.0, so the workflow below is a source-verified rollout checklist, not a claimed live 0.152 canary.
Who this is for
This guide is for developers running Codex interactively, through codex exec, or behind an app-server client. It is especially useful when unattended work has queued follow-ups, when a team workspace controls credits, or when Codex uses an external model provider such as Amazon Bedrock.
For root-goal token accounting, use the Codex 0.151 subagent budget checklist. For API-side 429 and spend controls, see the OpenAI API hard-limit runbook. Those are adjacent controls, not substitutes for this ChatGPT-backed Codex recovery state.
What changed in 0.152
The stable release adds actionable rate-limit banners. The linked implementation carries backend-owned banner and account identity data through account/rateLimits/read, filters banners that do not match the authenticated account or user, refreshes state after a limit error, rejects stale responses, and keeps queued input paused until recovery finishes.
If the banner instructs Codex to use a fallback model, the client switches to the first available fallback without changing unrelated thread settings. This is not a general promise that every account, limit, or model has a fallback.
The same release separately adds provider-authentication recovery progress to the TUI and codex exec. App-server clients receive modelProvider/authRecoveryStarted and modelProvider/authRecoveryCompleted with thread, turn, provider, and message fields. A Bedrock credential refresh is therefore not evidence that a ChatGPT usage window reset.
Classify the stop before acting
| Observed state | Authority | Safe next action | Do not assume |
|---|---|---|---|
| Rolling or selected-model usage limit | Backend usage snapshot and optional banner | Wait for reset or follow the offered fallback-model action | Buying credits or refreshing AWS credentials clears it |
| Workspace/member credits or spend control reached | Workspace billing policy | Notify the owner, add credits, or change the plan only through the offered action | A model switch bypasses workspace policy |
| Earned rate-limit reset available | account/rateLimits/read snapshot | Consume once with a unique idempotency key, then refetch | Every account has a reset or that one reset is free of expiry |
| Provider credential recovery | Model-provider auth events | Let refresh finish; reconnect only on failure | This changes ChatGPT quota or monthly credit state |
The app-server documentation says reset-credit and banner data are snapshot-only. Sparse account/rateLimits/updated notifications must be merged into a recent full read or followed by a refetch; missing fields do not prove zero credits, no spend control, or no banner.
A six-stage recovery workflow
1. Pin the client and record the failed turn
Capture codex --version, authentication mode, account or workspace identity, selected model, thread and turn IDs, error class, queued-input count, and timestamp. Do not upgrade, switch accounts, or re-send the prompt before you can identify the original turn.
2. Read the authoritative snapshot
TUI users should open the banner's usage action. App-server clients should call account/rateLimits/read. Record usedPercent, window duration, reset time, reached type, effective individual limit, spend-control state, available reset count, and the banner actions actually returned.
Never manufacture a reset button client-side. The backend decides eligibility, and identity-mismatched banners are filtered.
3. Hold queued work
Keep queued prompts visible but unsent while recovery is pending. The 0.152 tests cover a failed turn with two queued messages: recovery changes the model when instructed, sends exactly the oldest queued follow-up, leaves the second queued, and does not submit again when recovery completion is repeated.
If your wrapper automatically retries outside Codex, disable that retry until it consumes the same recovery state. Two independent retry loops can duplicate side effects.
4. Choose exactly one recovery lane
- Wait: use the backend reset time for an ordinary rolling window.
- Fallback: accept only a banner-provided model action, then record the old and new model.
- Earned reset: consume one returned credit with a fresh idempotency key; never retry with a new key after an uncertain response.
- Workspace action: notify the owner or manage credits/plan through the returned action.
- Provider auth: wait for the matching completion event; if it fails, repair the named provider rather than changing quota settings.
5. Refetch before releasing input
After any action, run a fresh full read. Confirm account identity still matches, recovery is no longer pending, the selected model is intentional, and the original failed turn has a terminal result. An account change should clear the recovery hold without auto-sending queued work.
6. Release one prompt and reconcile effects
Send only the oldest queued prompt. Check repository, deployment, issue, payment, or other external state before retrying any tool call from the failed turn. A rate-limit error does not prove that every earlier side effect rolled back.
Eight acceptance canaries
- A limit error triggers one authoritative refresh.
- Input submitted during refresh stays queued.
- A stale response cannot overwrite a newer limit state.
- A banner for another account or user is not rendered.
- A banner-directed fallback changes only the model required for recovery.
- Repeated recovery-complete handling does not send a second prompt.
- Switching accounts clears the hold but does not auto-send the queue.
- Provider-auth progress is logged separately from ChatGPT quota recovery.
Copyable recovery record
codex_version: 0.152.0
release_commit: 316795b3cf2a45e90d121d9f46499d4658b2645c
auth_mode: chatgpt|api_key|amazon_bedrock|other
account_id_hash:
thread_id:
failed_turn_id:
limit_reached_type:
selected_model_before:
banner_action: wait|fallback|reset|notify_owner|manage_credits|manage_plan|none
reset_idempotency_key_hash:
provider_auth_recovery: not_seen|started|completed|failed
queued_before:
queued_released: 1|0
external_side_effects_reconciled: yes|no
fresh_snapshot_verified: yes|no
checked_at:
~~~
Building something? Take a 60-sec game break. Score to rank your product or profile on [tapto.top](https://tapto.top/?utm_source=devto&utm_medium=syndicated-blog&utm_campaign=codex-0-152-rate-limit-reset-queued-input-recovery-checklist) and get more exposure—free, no signup.
## Common mistakes
- Calling every stopped turn a quota problem when provider authentication is actually refreshing.
- Assuming an absent reset-credit field means zero instead of unavailable snapshot data.
- Creating a client-side reset or plan action that the backend did not return.
- Retrying a reset with a new idempotency key after an uncertain response.
- Letting a wrapper and Codex both resend the same queued prompt.
- Switching models before recording which model and limit caused the stop.
- Treating a successful recovery as proof that prior tool side effects did not occur.
- Claiming 0.152 runtime validation from a machine still running an older CLI.
## FAQ
### Does Codex 0.152 give every user a free rate-limit reset?
No. It surfaces earned reset information and actions only when the backend says they are available for the authenticated account. Availability, count, details, and expiry can differ.
### Will Codex automatically switch models after every limit?
No. The release supports a fallback when instructed by the backend banner and when a fallback is available. It does not make model switching a universal recovery rule.
### Is Bedrock reauthentication the same as a Codex rate-limit reset?
No. Provider credential recovery has separate started/completed events. It restores provider authentication; it does not reset ChatGPT usage windows or workspace credits.
### Can I safely re-send the failed prompt after the banner disappears?
Only after a fresh snapshot, terminal-turn check, and external-side-effect reconciliation. Release one queued prompt, not the entire queue.
## Sources
- [Codex 0.152.0 stable release](https://github.com/openai/codex/releases/tag/rust-v0.152.0)
- [Actionable rate-limit banner implementation and tests](https://github.com/openai/codex/pull/41742)
- [Codex app-server account and rate-limit contract at the release commit](https://github.com/openai/codex/blob/316795b3cf2a45e90d121d9f46499d4658b2645c/codex-rs/app-server/README.md)
- [Queued-input rate-limit recovery tests at the release commit](https://github.com/openai/codex/blob/316795b3cf2a45e90d121d9f46499d4658b2645c/codex-rs/tui/src/chatwidget/tests/rate_limit_recovery_tests.rs)
- [Provider authentication recovery notifications](https://github.com/openai/codex/pull/41239)
Originally published at [IndieSeek](https://indieseek.co/blogs/codex-0-152-rate-limit-reset-queued-input-recovery-checklist/?utm_source=devto).
Top comments (0)