openclaw - ✅(Solved) Fix [Bug]: Primary model not respected after fallback in OpenClaw 2026.4.2 [1 pull requests, 1 comments, 2 participants]

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…
GitHub stats
openclaw/openclaw#59928Fetched 2026-04-08 02:38:44
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
Timeline (top)
labeled ×2commented ×1cross-referenced ×1

Version
OpenClaw 2026.4.2

Summary
A session does not reliably return to or stay on the configured primary model after fallback occurs. Even with openai-codex/gpt-5.4 configured as primary, the active session continues using a fallback model.

Minimal config

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai-codex/gpt-5.4",
        "fallbacks": [
          "amazon-bedrock/minimax.minimax-m2.5",
          "openrouter/openrouter/free"
        ]
      }
    },
    "list": [
      {
        "id": "main",
        "model": "openai-codex/gpt-5.4"
      }
    ]
  }
}

Observed examples

  • Fallback model got stuck on amazon-bedrock/minimax.minimax-m2.5
  • After removing MiniMax from fallbacks, session used openrouter/openrouter/free instead of primary

Impact

  • Users cannot trust the configured primary model to remain active.
  • Model selection in the UI/session appears inconsistent after failover.

Root Cause

Version
OpenClaw 2026.4.2

Summary
A session does not reliably return to or stay on the configured primary model after fallback occurs. Even with openai-codex/gpt-5.4 configured as primary, the active session continues using a fallback model.

Minimal config

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai-codex/gpt-5.4",
        "fallbacks": [
          "amazon-bedrock/minimax.minimax-m2.5",
          "openrouter/openrouter/free"
        ]
      }
    },
    "list": [
      {
        "id": "main",
        "model": "openai-codex/gpt-5.4"
      }
    ]
  }
}

Observed examples

  • Fallback model got stuck on amazon-bedrock/minimax.minimax-m2.5
  • After removing MiniMax from fallbacks, session used openrouter/openrouter/free instead of primary

Impact

  • Users cannot trust the configured primary model to remain active.
  • Model selection in the UI/session appears inconsistent after failover.

Fix Action

Fixed

PR fix notes

PR #59959: fix: preserve selected session model after fallback

Description (problem / solution / changelog)

Summary

  • Problem: session control paths and the session list kept preferring persisted runtime model fields after a fallback run, so a fallback model could look like the selected model and stick across follow-up control operations.
  • Why it matters: after one fallback, switching or resetting a session could continue to reflect the fallback model instead of the configured primary or explicit session override.
  • What changed: resolveSessionModelRef() and resolveLiveSessionModelSelection() now prefer explicit session overrides ahead of runtime model fields, and sessions.list now surfaces the selected override model while preserving runtime identity behavior when no override exists.
  • What did NOT change (scope boundary): this PR does not redesign fallback notices or add separate selected-vs-active model fields to the gateway session payload.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #59928
  • Related #59928
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

  • Root cause: src/gateway/session-utils.ts resolved the effective session model by preferring persisted runtime fields before session overrides, and src/agents/live-model-switch.ts mirrored that precedence for live selection.
  • Missing detection / guardrail: regression tests covered runtime-first behavior, but there was no test asserting that explicit session overrides remain authoritative after a fallback run.
  • Prior context (git blame, prior PR, issue, or refactor if known): issue #59928 reported the stuck-fallback behavior; this PR addresses the verified control-path cause in the current code.
  • Why this regressed now: persisted runtime fields were treated as the effective session model instead of last-run identity.
  • If unknown, what was ruled out: the generic fallback runner itself was not changed here; the verified issue was in session model resolution and session row rendering.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file: src/gateway/session-utils.test.ts, src/agents/live-model-switch.test.ts
  • Scenario the test should lock in: a session with a configured override and persisted fallback runtime fields should still resolve and report the selected override model.
  • Why this is the smallest reliable guardrail: the bug lives in small model-resolution helpers used by gateway control paths and the session list.
  • Existing test that already covers this (if any): existing helper tests covered runtime/model parsing and were updated to assert the corrected precedence.
  • If no new test is added, why not: N/A

User-visible / Behavior Changes

  • Session control paths now respect the configured primary or explicit session override after a fallback run.
  • The session list reports the selected override model instead of showing the persisted fallback runtime model as current.

Diagram (if applicable)

Before:
[fallback run persists runtime model] -> [session control paths read runtime fields first] -> [fallback looks like selected model]

After:
[fallback run persists runtime model] -> [session control paths read selected override/default first] -> [fallback stays runtime-only identity]

Security Impact (required)

  • New permissions/capabilities? (Yes/No) No
  • Secrets/tokens handling changed? (Yes/No) No
  • New/changed network calls? (Yes/No) No
  • Command/tool execution surface changed? (Yes/No) No
  • Data access scope changed? (Yes/No) No
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS: macOS 25.3.0
  • Runtime/container: local Node/Bun repo workflow
  • Model/provider: N/A
  • Integration/channel (if any): gateway session model resolution
  • Relevant config (redacted): agent default primary plus session override with persisted runtime fallback fields

Steps

  1. Configure a primary model and at least one fallback model.
  2. Persist a session override or switch the session back to the primary model after a fallback run.
  3. Read the session via gateway control paths or sessions.list.

Expected

  • Explicit session selection remains authoritative.
  • Runtime fallback identity does not replace the selected session model.

Actual

  • Before this fix, persisted runtime fields could continue to win and make the fallback model appear selected.

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Verified scenarios:
    • pnpm test -- src/gateway/session-utils.test.ts src/agents/live-model-switch.test.ts
    • pnpm check
    • pnpm build
  • Edge cases checked:
    • runtime model still resolves when no session override exists
    • session list keeps legacy/runtime identity behavior when no override exists
    • live model switching now keeps the explicit session override authoritative
  • What you did not verify:
    • live Control UI repro against a running OpenClaw instance
    • full pnpm test completion, because the suite currently fails on unrelated src/tts/status-config.test.ts expectations (provider: \"auto\" vs \"microsoft\") outside this touched surface

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes/No) Yes
  • Config/env changes? (Yes/No) No
  • Migration needed? (Yes/No) No
  • If yes, exact upgrade steps:

Risks and Mitigations

  • Risk: gateway session rows still expose a single model field, so this fix intentionally keeps runtime identity separate only where the selected override is present.
    • Mitigation: regression tests now lock in both override-first control resolution and the no-override runtime fallback behavior.

AI Assistance

  • This PR was prepared with AI assistance.
  • Testing level: locally verified with focused regression tests plus pnpm check and pnpm build.

Made with Cursor

Changed files

  • src/agents/live-model-switch.test.ts (modified, +29/-2)
  • src/agents/live-model-switch.ts (modified, +6/-2)
  • src/gateway/session-utils.test.ts (modified, +60/-1)
  • src/gateway/session-utils.ts (modified, +29/-19)

Code Example

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai-codex/gpt-5.4",
        "fallbacks": [
          "amazon-bedrock/minimax.minimax-m2.5",
          "openrouter/openrouter/free"
        ]
      }
    },
    "list": [
      {
        "id": "main",
        "model": "openai-codex/gpt-5.4"
      }
    ]
  }
}

---
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Version
OpenClaw 2026.4.2

Summary
A session does not reliably return to or stay on the configured primary model after fallback occurs. Even with openai-codex/gpt-5.4 configured as primary, the active session continues using a fallback model.

Minimal config

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai-codex/gpt-5.4",
        "fallbacks": [
          "amazon-bedrock/minimax.minimax-m2.5",
          "openrouter/openrouter/free"
        ]
      }
    },
    "list": [
      {
        "id": "main",
        "model": "openai-codex/gpt-5.4"
      }
    ]
  }
}

Observed examples

  • Fallback model got stuck on amazon-bedrock/minimax.minimax-m2.5
  • After removing MiniMax from fallbacks, session used openrouter/openrouter/free instead of primary

Impact

  • Users cannot trust the configured primary model to remain active.
  • Model selection in the UI/session appears inconsistent after failover.

Steps to reproduce

Steps to reproduce

  1. Configure openai-codex/gpt-5.4 as the primary model.
  2. Configure one or more fallback models.
  3. Start a normal session in the Control UI.
  4. Cause the primary model to fail once so fallback activates.
  5. After fallback succeeds, check the current model in the UI or via session status.
  6. Attempt to switch back to openai-codex/gpt-5.4.

Expected behavior

Expected behavior

  • The session should use openai-codex/gpt-5.4 by default.
  • Fallback should only be used when the primary fails.
  • After switching back, the current model should remain openai-codex/gpt-5.4.

Actual behavior

Actual behavior

  • The session keeps using the fallback model after fallback occurred.
  • Explicit switching back to openai-codex/gpt-5.4 appears inconsistent or temporary.
  • Removing one fallback causes another fallback to be used instead of the primary.

OpenClaw version

2026.4.2

Operating system

MacOS 26.4

Install method

npm install

Model

openai-codex/gpt-5.4, minimax/m2.5, openrouter/free

Provider / routing chain

openclaw -> openai-codex/gpt-5.4 -> minimax/m2.5

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The session may not reliably return to the primary model after a fallback occurs, suggesting an issue with the model switching logic.

Guidance

  • Verify the model switching logic to ensure it correctly reverts to the primary model after a fallback.
  • Check the configuration for any potential conflicts or overrides that might prevent the primary model from being used.
  • Test the session with different fallback models to see if the issue is specific to one model or a general problem.
  • Review the logs for any error messages or clues that might indicate why the primary model is not being used.

Example

No specific code example can be provided without more information on the implementation details, but reviewing the model switching logic and configuration is a good starting point.

Notes

The issue seems to be related to the model switching logic, but without more information on the implementation or logs, it's difficult to provide a more specific solution. The problem might be related to how the fallback models are configured or how the primary model is selected after a fallback.

Recommendation

Apply a workaround by manually switching back to the primary model after a fallback occurs, and investigate the model switching logic to identify and fix the root cause. This approach allows for temporary mitigation of the issue while a more permanent solution is developed.

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

Expected behavior

  • The session should use openai-codex/gpt-5.4 by default.
  • Fallback should only be used when the primary fails.
  • After switching back, the current model should remain openai-codex/gpt-5.4.

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 - ✅(Solved) Fix [Bug]: Primary model not respected after fallback in OpenClaw 2026.4.2 [1 pull requests, 1 comments, 2 participants]