Problem
When a model fallback occurs mid-session (e.g., primary model times out and the system falls back to the next configured model), the user receives no notification. The session continues seamlessly in appearance, but:
- The user doesn't know the model changed. There's no visual indicator, system message, or alert.
- The fallback model receives conversation history but not the full system prompt context. Workspace files (SOUL.md, AGENTS.md, etc.) that were injected at session boot are not re-injected for the fallback model. The new model knows what was said but not who it is or what the operating rules are.
This causes gradual behavioral drift — wrong tone, bypassed protocols, unexpected writes — with no visible seam between the primary and fallback model. The user notices something is "off" but can't pinpoint why.
Evidence
- OpenClaw's model-failover system handles the runtime mechanics correctly: auth profile rotation, exponential cooldown,
FallbackSummaryError, session override coordination — all thorough and well-documented.
- The gap is in the user-facing layer: there's no notification event and no context re-injection hook.
- I configured
model-fallback-alert as an internal hook, but it can't fire because there's no model:fallback event type available to hooks.
- I've experienced multiple "session went crazy" incidents that traced back to silent fallback — the session appeared normal but the model had changed without re-receiving the system prompt personality and operating rules.
- The model-failover docs track
providerOverride, modelOverride, and authProfileOverride per session — but these are runtime routing fields, not context/identity fields.
Proposed Solution
Two additions:
1. Fallback Notification Event
When runWithModelFallback() advances to a new model candidate, emit an observable event (e.g., model:fallback) that:
- Is available to the internal hook system
- Can optionally inject a system message into the session transcript (e.g., "⚠️ Session switched from claude-opus-4-6 to gemini-3.1-pro-preview due to timeout")
- Can be configured per user preference: off / system-message-only / channel-alert
2. System Prompt Re-injection on Model Switch
When a fallback model takes over mid-session, re-inject the workspace boot context (the same files loaded during session initialization) so the new model has the full operating context, not just conversation history.
Options:
- Automatic — always re-inject on model switch
- Configurable — opt-in via something like
agents.defaults.reinjectContextOnFallback: true
- Scoped — only re-inject specific files (e.g., SOUL.md + AGENTS.md, not full workspace)
Workaround
I built a custom model-fallback-alert hook entry (enabled in config under hooks.internal.entries), but it has no effect because there's no fallback event that hooks can subscribe to. Currently the only mitigation is monitoring session output for behavioral drift manually.
Impact
This is the highest-impact gap I've found in intensive daily use. Every behavioral issue I've debugged — wrong tone, protocol violations, unexpected file writes — has traced back to a model operating without its identity/rules context after a silent fallback.
Environment
- OpenClaw 2026.4.10 (npm, macOS)
- Multi-provider fallback chain: Anthropic → Google → OpenAI → xAI → Anthropic (Sonnet)
- Heavy use of workspace files for agent identity and operating rules
Problem
When a model fallback occurs mid-session (e.g., primary model times out and the system falls back to the next configured model), the user receives no notification. The session continues seamlessly in appearance, but:
This causes gradual behavioral drift — wrong tone, bypassed protocols, unexpected writes — with no visible seam between the primary and fallback model. The user notices something is "off" but can't pinpoint why.
Evidence
FallbackSummaryError, session override coordination — all thorough and well-documented.model-fallback-alertas an internal hook, but it can't fire because there's nomodel:fallbackevent type available to hooks.providerOverride,modelOverride, andauthProfileOverrideper session — but these are runtime routing fields, not context/identity fields.Proposed Solution
Two additions:
1. Fallback Notification Event
When
runWithModelFallback()advances to a new model candidate, emit an observable event (e.g.,model:fallback) that:2. System Prompt Re-injection on Model Switch
When a fallback model takes over mid-session, re-inject the workspace boot context (the same files loaded during session initialization) so the new model has the full operating context, not just conversation history.
Options:
agents.defaults.reinjectContextOnFallback: trueWorkaround
I built a custom
model-fallback-alerthook entry (enabled in config underhooks.internal.entries), but it has no effect because there's no fallback event that hooks can subscribe to. Currently the only mitigation is monitoring session output for behavioral drift manually.Impact
This is the highest-impact gap I've found in intensive daily use. Every behavioral issue I've debugged — wrong tone, protocol violations, unexpected file writes — has traced back to a model operating without its identity/rules context after a silent fallback.
Environment