openclaw - 💡(How to fix) Fix [Bug]: Rate limit fallback references wrong models - session model switch corrupts fallback chain

Bug type

Behavior bug (incorrect output/state without crash)

Summary

Multiple agents are showing the error message referencing gpt-5.5 rate limits even when their primary model is NOT gpt-5.5. This appears to be a manifestation of issue #56958 where the session's live/persisted model selection conflicts with the fallback decision, causing the error message to reference the wrong model.

Environment

• OpenClaw version: 2026.5.12
• Channel: stable
• OS: Linux (x64)
• Install method: npm global

Steps to reproduce

1. Configure multiple agents with different primary models:

   • main: primary = zai/glm-5.1, fallbacks = [openai-codex/gpt-5.5, zai/glm-5]
   • infralover: primary = zai/glm-5-turbo, fallbacks = [openai-codex/gpt-5.5, zai/glm-5.1]
   • docclaw: primary = zai/glm-5-turbo (no fallbacks)
   • cornelio: primary = openai-codex/gpt-5.5, fallbacks = [zai/glm-5-turbo, zai/glm-5.1]

2. Trigger rate limit conditions on ZAI models (glm-5-turbo hits weekly/monthly limit)

3. Observe error messages that incorrectly reference gpt-5.5 rate limits for agents NOT using gpt-5.5 as primary

Expected behavior

When an agent's primary model hits a rate limit:

1. If fallbacks are configured, the system should actually execute the fallback model
2. Error messages should reference the agent's actual primary model, not an unrelated model
3. Agents with working fallbacks should continue operating, not show "All models failed"

Actual behavior

Observed Error Message

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

⚠️ Cron job "Daily Full Backup" failed: FallbackSummaryError: All models failed (2): zai/glm-5-turbo: 429 Weekly/Monthly Limit Exhausted. Your limit will reset at 2026-05-19 05:18:33 (rate_limit) | openai-codex/gpt-5.5: You've reached your Codex subscription usage limit. Next reset in 2 days, May 15 at 3:40 PM GMT-3. Run /codex account for current usage details. (rate_limit)

Problem Analysis

The error message shows:

1. zai/glm-5-turbo rate limit (expected for infralover)
2. openai-codex/gpt-5.5 Codex subscription limit (UNEXPECTED - this is NOT in infralover's fallback chain)

This suggests the bug from #56958 is still present:

• The system correctly decides to fallback
• But the session's live/persisted model selection switches the run back to a different model
• The fallback chain gets corrupted and picks models from other agents' configs

Agent Config Excerpt

{
  "infralover": {
    "model": {
      "primary": "zai/glm-5-turbo",
      "fallbacks": ["openai-codex/gpt-5.5", "zai/glm-5.1"]
    }
  },
  "docclaw": {
    "model": "zai/glm-5-turbo"
  }
}

Default Fallback Chain

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "zai/glm-5.1",
        "fallbacks": [
          "zai/glm-5",
          "openai-codex/gpt-5.5",
          "zai/glm-5-turbo",
          "zai/glm-4.7-flash",
          "zai/glm-4.7",
          "openai/gpt-5.4"
        ]
      }
    }
  }
}

Impact and severity

High - Multiple agents become completely non-functional when ANY model in the fallback chain hits a rate limit, even if that model is not the agent's configured primary. This defeats the purpose of having per-agent fallback configurations.

Additional information

This appears to be the same root cause as #56958:

• Failover decision is made correctly
• But "live session model switch" overrides the fallback before execution
• Result: the fallback never actually runs, and the error aggregates from multiple unrelated models

Related Issues

• #56958 - Model fallback does not actually execute after rate_limit when session is pinned to primary model (STILL OPEN)
• #62332 - rate_limit errors do not trigger model fallback (CLOSED but may have regression)
• #28925 - 429 rate limit error does not trigger fallback model (CLOSED)

Workaround Attempted

None successful yet. Even agents with local models as fallbacks fail because the fallback chain appears to be getting corrupted by the live session model switch mechanism.