Summary

Provider switching after Windows onboarding can leave stale model/provider config and session cache behind. The visible active provider/model can disagree with the actual provider used for the request, producing misleading cross-provider errors.

In the HeraldLabs repro, the user switched across providers, but stale model references and session cache continued to force old provider/model paths until manual config editing and session file deletion.

Environment

• OS: Windows 11 Version 25H2
• OpenClaw: 2026.5.27 (27ae826)
• Node: v24.16.0
• Install method: PowerShell install script / QuickStart
• Terminal: Windows PowerShell
• Providers involved: Anthropic, Groq, HuggingFace, Google, LiteLLM beta key

Reproduction path A: partial provider config becomes unexpected fallback

1. Begin onboarding with one provider without valid credentials configured.
2. Continue through onboarding / attempt provider changes.
3. Later switch to another provider, e.g. Groq.
4. Start openclaw tui and send the bootstrap/first message.

Observed A

The TUI showed the active provider/model as Groq:

agent main | session main | groq/llama-3.3-70b-versatile | tokens ?/200k

But the request failed with a Google auth error:

Google Generative AI API error (401): Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. [code=UNAUTHENTICATED]

The error did not explain why Google was being used while the UI displayed Groq.

Reproduction path B: provider/model switch does not update all config/session references

1. Switch to LiteLLM beta key using:

   openclaw onboard --non-interactive --auth-choice litellm-api-key

2. Run openclaw tui.
3. Observe a 401/error for stale claude-opus-4-6 access.
4. Run:

   openclaw models set litellm/openclaw-beta
   openclaw config set agents.defaults.model.primary litellm/openclaw-beta

5. Inspect config: agents.defaults.model.primary is correct, but stale model IDs remain elsewhere.
6. Manually replace stale claude-opus-4-6 references in config.
7. Delete stale session cache:

   ~\.openclaw\agents\main\sessions\sessions.json

8. Restart gateway and run openclaw tui again.

Expected result

Switching provider/model should update all effective model references or clearly report the remaining stale reference. Gateway restart should not keep using an old session/provider cache after config changes.

Actual result

• Stale model references remained in at least:
  • agents.defaults.model.primary
  • models.providers.litellm.models[].id
• CLI config/model commands did not fully resolve the conflict.
• Session cache continued to use stale model/provider routing after gateway restart.
• The only working recovery was manual config editing in Notepad and deleting sessions.json.

Impact

High. A technically capable tester needed over an hour and direct team support to recover. A beginner user would likely abandon the install.

Suggested fix

• Add a provider-switch transaction that updates all effective config locations.
• Detect and warn on stale provider/model references after switching.
• Invalidate or refresh session model/provider cache after provider/auth changes.
• Add a documented Windows command for safe provider reset.
• Make cross-provider fallback errors include the active route and fallback reason.

Related

Related conceptually to #8190, but this is a concrete Windows onboarding/provider-switch repro with stale config references and session cache.

Source

HeraldLabs beta QA report from Miriam Peter, 2026-05-30.