Summary

When a session's declared primary + fallback chain all fail and a request succeeds against an undeclared provider (one that exists in models.providers but isn't listed in the agent's .model.fallbacks), the gateway caches that provider as the session's effective model. Every subsequent request in that session goes directly to the cached provider, bypassing the declared chain entirely. This persists until the gateway restarts — sessions are not re-evaluated.

Only indicator is model-snapshot events in ~/.openclaw/agents/*/sessions/*.jsonl. No visible gateway log, no Discord notification, no dashboard indicator. For long-running sessions (heartbeats, always-on agents), this can drift undetected for weeks.

Related to but distinct from #43945 (which is about subagent credential lookup specifically). This issue is about main-session drift after a fallback cascade.

Severity: privacy regression

An agent configured to use only local/private models can silently route content to any provider configured in models.providers, regardless of whether that provider was intended as a fallback. Users who configure models.providers for manual model selection via the control UI have no reason to expect those providers to become fallback targets after a network blip.

Steps to reproduce

Minimal config:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama/gemma4:31b",
        "fallbacks": ["ollama/qwen3:32b"]
      }
    }
  },
  "models": {
    "providers": {
      "ollama": {
        "apiKey": "ollama-local",
        "baseUrl": "http://127.0.0.1:11434",
        "api": "ollama"
      },
      "external-provider": {
        "apiKey": "<REAL_KEY>",
        "baseUrl": "https://some.external.api/v1",
        "api": "openai-completions"
      }
    }
  }
}

Note: external-provider is in models.providers but NOT in any .model.fallbacks. User intent: "I want this available for manual openclaw model set external-provider/foo but not as an automatic fallback."

Reproduction:

1. Start the gateway. Primary + fallback calls succeed against Ollama. Good.
2. Induce an Ollama failure (block 127.0.0.1:11434 temporarily, or kill Ollama, or simulate DNS failure with /etc/hosts).
3. Send a request to the agent. Primary fails. Fallback fails. Gateway reaches into models.providers and finds external-provider. Calls it. Success.
4. Restore Ollama. Send another request to the agent in the same session.
5. Observed: request goes directly to external-provider, no Ollama attempt.
6. Expected: gateway re-tries declared primary + fallback chain on each request (or at minimum on a new turn boundary).

Repeated turns continue to hit external-provider. Only a gateway restart (which creates new sessions) restores declared behavior.

Evidence from production incident

Key data points from a recent production occurrence (full forensics on request):

• Session JSONL file accumulated 585 calls to the cached non-Ollama provider over 7 days.
• Material cost impact routed through a third-party cloud model path we explicitly did not intend.
• model-snapshot events in the session file clearly record the drift (provider: ollama → provider: <other>), but no observability surface reflected it.
• Triggering failure was a single transient DNS blip during a regional WAN outage. The drift persisted for the entire 7 days because the long-running heartbeat session kept appending rather than rotating.

Proposed fix shape

Three possible behaviors, in order of caution:

(a) Re-probe declared chain on every new turn. On each user-visible message boundary, re-evaluate the declared primary → fallbacks chain before reusing the cached provider. Cheap (existing model probe), zero silent drift.

(b) Emit a visible provider-drift event when drift persists. Every turn where the effective model differs from the declared primary, emit a model_change or provider_drift event to the gateway log, Discord indicator, and control UI. Doesn't fix the behavior but surfaces it.

(c) Require explicit opt-in for session-level caching. Add gateway.sessionModelCaching: "declared-chain-only" | "last-success" | "off" config flag. Default to "declared-chain-only" — caching applies only to providers that are in the declared chain. Undeclared providers never persist across turns.

(c) would have prevented our incident entirely. (a) would have limited blast radius to a single turn. (b) alone wouldn't prevent the drift but would have made detection take hours instead of days.

Diagnostic tooling suggestion (independent of fix)

A command like openclaw sessions drift that greps all session files for model-snapshot events where provider differs from the agent's declared primary. Would surface existing stuck sessions without requiring a fix.

Other notes

• Not a duplicate of #43945 (that's about subagent auth specifically and hits a different code path).
• Related family of bugs: "silent fallback to cloud" — see #43945 for another instance.

Happy to provide the session JSONL excerpt (with API keys redacted) and the specific openclaw.json configuration that triggered the drift if helpful for a repro case.