openclaw - 💡(How to fix) Fix [Bug]: Auto rate-limit fallback override still pins Discord session to fallback after primary recovers

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

On OpenClaw 2026.5.7, a Discord session that auto-fell back from openai-codex/gpt-5.5 to openai-codex/gpt-5.4 after a provider usage_limit_reached/429 remained pinned to gpt-5.4 on later turns even after the primary quota recovered; the later turn did not attempt gpt-5.5 first.

Root Cause

On OpenClaw 2026.5.7, a Discord session that auto-fell back from openai-codex/gpt-5.5 to openai-codex/gpt-5.4 after a provider usage_limit_reached/429 remained pinned to gpt-5.4 on later turns even after the primary quota recovered; the later turn did not attempt gpt-5.5 first.

Code Example

agents.defaults.model.primary = openai-codex/gpt-5.5
agent[main].model.primary = openai-codex/gpt-5.5
agent[main].model.fallbacks = [openai-codex/gpt-5.4, google/gemini-3.1-pro-preview]

session key = agent:main:discord:channel:<discord-thread-or-channel-id>
providerOverride = openai-codex
modelOverride = gpt-5.4
modelOverrideSource = auto
authProfileOverride = openai-codex:default
authProfileOverrideSource = auto
modelProvider = openai-codex
model = gpt-5.4
compactionCount = 1

---

Prior primary failure evidence from previous OpenClaw log:
model = gpt-5.5
provider = openai-codex
isError = true
status_code = 429
failoverReason = rate_limit
providerErrorType = usage_limit_reached
providerErrorMessagePreview = The usage limit has been reached
X-Codex-Primary-Used-Percent = 100

Current session state on 2026.5.7:
providerOverride = openai-codex
modelOverride = gpt-5.4
modelOverrideSource = auto
authProfileOverride = openai-codex:default
authProfileOverrideSource = auto
modelProvider = openai-codex
model = gpt-5.4

Later same-session log after quota recovery:
[prompt-cache] cache read dropped ... for openai-codex/gpt-5.4 via session-custom

Search of the later same-day log found no gpt-5.5 attempt for that turn.

---

session-reset-cleanup.ts comment says auto-created overrides (runtime fallbacks, rate-limit rotations) are cleared so resets return the session to the configured default.

session-reset-service clears providerOverride/modelOverride/modelOverrideSource, then reapplies only resetPreservedSelection.

model-selection reads directStoredOverride from sessionEntry.providerOverride/sessionEntry.modelOverride and applies it during normal selection.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On OpenClaw 2026.5.7, a Discord session that auto-fell back from openai-codex/gpt-5.5 to openai-codex/gpt-5.4 after a provider usage_limit_reached/429 remained pinned to gpt-5.4 on later turns even after the primary quota recovered; the later turn did not attempt gpt-5.5 first.

Steps to reproduce

  1. Configure an agent with primary openai-codex/gpt-5.5 and fallback openai-codex/gpt-5.4.
  2. In a Discord-backed session, hit a primary-provider quota failure from gpt-5.5 (usage_limit_reached, HTTP 429, failoverReason=rate_limit).
  3. Let OpenClaw auto-fallback/rotate the session to gpt-5.4.
  4. After the upstream gpt-5.5 quota has recovered, send another message in the same Discord session.
  5. Inspect %USERPROFILE%\.openclawgents\main\sessions\sessions.json and %LOCALAPPDATA%\Temp\openclaw\openclaw-YYYY-MM-DD.log.

Expected behavior

After a transient primary quota failure recovers, the next normal turn should revalidate or retry the configured primary openai-codex/gpt-5.5, or at least expire/clear the modelOverrideSource="auto" fallback pin automatically. This is also consistent with the closure note on #66895, which says #69365 clears modelOverrideSource: "auto" before normal model selection on the next turn so the configured primary is retried.

Actual behavior

The same Discord session continued to start from the persisted fallback model:

  • session store contained providerOverride=openai-codex, modelOverride=gpt-5.4, modelOverrideSource=auto
  • session runtime fields also showed modelProvider=openai-codex, model=gpt-5.4
  • later logs showed openai-codex/gpt-5.4 via session-custom
  • no gpt-5.5 attempt appeared in the same-day log for the later turn

A local source/read-only verification also matched the observed state:

  • createModelSelectionState applies a stored providerOverride/modelOverride from the session entry during normal model selection.
  • session-reset-cleanup only preserves user-driven model overrides and clears auto-created overrides on /new//reset.
  • A copy/emulation of the reset-preservation logic for the affected session cleared providerOverride, modelOverride, and modelOverrideSource, confirming reset would recover the default, but the normal next turn did not.

OpenClaw version

OpenClaw 2026.5.7 (eeef486)

Operating system

Windows 11 Home 10.0.26200 Build 26200

Install method

npm global / Windows native gateway service via Scheduled Task

Model

Configured primary: openai-codex/gpt-5.5

Observed effective model after fallback: openai-codex/gpt-5.4

Provider / routing chain

OpenClaw Discord session -> openai-codex provider -> primary gpt-5.5 with fallback gpt-5.4

Additional provider/model setup details

Relevant sanitized config/session facts:

agents.defaults.model.primary = openai-codex/gpt-5.5
agent[main].model.primary = openai-codex/gpt-5.5
agent[main].model.fallbacks = [openai-codex/gpt-5.4, google/gemini-3.1-pro-preview]

session key = agent:main:discord:channel:<discord-thread-or-channel-id>
providerOverride = openai-codex
modelOverride = gpt-5.4
modelOverrideSource = auto
authProfileOverride = openai-codex:default
authProfileOverrideSource = auto
modelProvider = openai-codex
model = gpt-5.4
compactionCount = 1

Logs, screenshots, and evidence

Prior primary failure evidence from previous OpenClaw log:
model = gpt-5.5
provider = openai-codex
isError = true
status_code = 429
failoverReason = rate_limit
providerErrorType = usage_limit_reached
providerErrorMessagePreview = The usage limit has been reached
X-Codex-Primary-Used-Percent = 100

Current session state on 2026.5.7:
providerOverride = openai-codex
modelOverride = gpt-5.4
modelOverrideSource = auto
authProfileOverride = openai-codex:default
authProfileOverrideSource = auto
modelProvider = openai-codex
model = gpt-5.4

Later same-session log after quota recovery:
[prompt-cache] cache read dropped ... for openai-codex/gpt-5.4 via session-custom

Search of the later same-day log found no gpt-5.5 attempt for that turn.

Related source/code observations from the installed 2026.5.7 bundle:

session-reset-cleanup.ts comment says auto-created overrides (runtime fallbacks, rate-limit rotations) are cleared so resets return the session to the configured default.

session-reset-service clears providerOverride/modelOverride/modelOverrideSource, then reapplies only resetPreservedSelection.

model-selection reads directStoredOverride from sessionEntry.providerOverride/sessionEntry.modelOverride and applies it during normal selection.

Related issues:

  • #66895 was closed as completed and specifically describes modelOverrideSource="auto" persisting after failover. Its closure comment says the next turn should clear auto override and retry the configured primary.
  • #51251 is open for broader/stale session modelOverride persistence, but this report is specifically about an auto-created rate-limit fallback pin still affecting a later normal Discord turn in 2026.5.7.

Impact and severity

Affected: Discord-backed OpenClaw sessions using openai-codex/gpt-5.5 primary with gpt-5.4 fallback.

Severity: Medium. The bot continues to answer, but from the fallback model, and users may not realize the configured primary is no longer being retried after a transient quota failure.

Frequency: Observed on the affected session after a usage_limit_reached/429 fallback event.

Consequence: The session stays on gpt-5.4 until manually reset/new-session cleanup, despite the configured primary being available again.

Additional information

This appears to be either a regression or an incomplete fix for #66895 on 2026.5.7. /new or /reset is expected to clear the auto override based on current source and local emulation, but the normal next-turn primary retry described in the #66895 closure note did not occur in the observed Discord session.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

After a transient primary quota failure recovers, the next normal turn should revalidate or retry the configured primary openai-codex/gpt-5.5, or at least expire/clear the modelOverrideSource="auto" fallback pin automatically. This is also consistent with the closure note on #66895, which says #69365 clears modelOverrideSource: "auto" before normal model selection on the next turn so the configured primary is retried.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: Auto rate-limit fallback override still pins Discord session to fallback after primary recovers