Problem

When a model fallback occurs mid-session (e.g., primary model rate-limits and the fallback chain fires), three user-facing gaps compound into a single failure mode: the session silently changes personality.

Originally filed as part of #65824 (item 1) and #65812, audited against 2026.4.15. Re-audited against 2026.5.7 — all three gaps confirmed still present.

What 2026.5.7 gets right

The internal observability is significantly improved since our original filing:

• Dedicated fallback module. model-fallback-DIXhOaxb.js (was inline) now has structured fallback step fields, attempt tracking, and chain-position logging.
• Verbose fallback notice. buildFallbackNotice() emits ↪️ Model Fallback: <active> as a lifecycle-stream event on transition.
• Fallback lifecycle events. fallback_cleared emitted on recovery — useful for debugging.

Credit where due: the fallback internals are now well-structured and debuggable. The gaps are in the user-facing layer.

Remaining gaps

Gap A: Non-verbose users see nothing

agent-runner.runtime-DQsCsHUA.js:3929-3937 — buildFallbackNotice() is gated behind if (verboseEnabled). On default settings, a mid-session switch from Opus to Gemini is invisible.

We understand the verbose gate is probably a deliberate UX choice to avoid noise. A lightweight opt-in — something like agents.defaults.fallback.notify: true or a one-line non-verbose notice — would bridge this for users who want awareness without full verbose output.

Gap B: No workspace-context re-injection on fallback

contextInjection: "continuation-skip" (the recommended default for token efficiency) does not re-inject bootstrap context when the model changes mid-session. The skip logic at selection-BeP8qtCb.js:4586-4587 checks bootstrapMode and hasCompletedBootstrapTurn but not model-change state.

Result: the fallback model inherits conversation history but not SOUL.md / AGENTS.md / workspace persona. This is the root of the "session suddenly feels different" class of incident.

Gap C: No event type for user hooks

model_fallback_decision at model-fallback-DIXhOaxb.js:202 is a log event (subsystem logger), not a plugin hook event. There's no model:fallback or equivalent in the plugin hook system, so user plugins can't react to fallback transitions.

Workaround

• Gap B: contextInjection: "always" re-injects on every turn, covering fallback turns — at a token cost. Our canon-guardian plugin (shared in [Show and Tell] canon-guardian: selective workspace canon re-injection on model switch / native fallback / restart #75750) selectively re-injects only on model switch, new session, and periodic safety net, covering the gap at ~2-4% of turns.
• Gap A/C: No automated workaround possible. Manual behavioral-drift monitoring.

Proposed solution

1. Opt-in fallback notification: agents.defaults.fallback.notify config field. When enabled, inject a one-line system message on model switch (e.g., "⚠️ Session switched from claude-opus-4-7 to gemini-3.1-pro-preview due to timeout"). Not verbose-gated.
2. Context re-injection on model change: When continuation-skip is active and the model changes, treat the next turn as a bootstrap turn for context injection purposes. Check model-change state alongside bootstrapMode / hasCompletedBootstrapTurn in the skip logic.
3. Plugin hook event: Expose model:fallback (or equivalent) to the plugin hook system so user plugins can react to transitions.

Impact

Highest. Every "my agent changed personalities" report we've seen traces back to the re-injection gap. Affects every user running a fallback chain with contextInjection: "continuation-skip".

Environment

• OpenClaw 2026.5.7 (eeef486) · macOS arm64
• 4-provider fallback chain (Anthropic → Google → OpenAI → xAI)
• Heavy use of workspace files for agent identity and operating rules