OpenClaw stolpert unter Windows über Provider-Wechsel und teure Defaults

OpenClaw unter Windows kann nach einer scheinbar erfolgreichen Einrichtung sofort scheitern. Ein Chat bricht ab, ein Provider-Wechsel zeigt in der Oberfläche Erfolg, und die nächste Fehlermeldung kommt trotzdem aus einer anderen Modellfamilie. Drei offene GitHub-Issues beschreiben diesen Fehlerpfad.¹²³

Für die Diagnose zählt ein Abgleich: Welches Modell zeigt die Oberfläche an? Welche Route nennt der Fehler? Und hat der Wechsel wirklich alle gespeicherten Zustände erreicht?

Die Reproduktionen stammen laut Issues aus einem HeraldLabs-Beta-QA-Bericht vom 30. Mai 2026. Getestet wurde auf Windows 11 25H2 über den PowerShell-Installweg.¹²³ Für Windows-Nutzer ergibt sich daraus ein nützlicher Prüfpfad, wenn Provider-Anzeige und tatsächlicher Request auseinanderlaufen.

Ein Chat kann unerwartet Kosten auslösen

Issue #88371 beschreibt einen Windows-QuickStart, der einen neuen Chat auf ein kostenpflichtiges Anthropic-Modell setzen kann, ohne den nötigen Credit deutlich vorab zu erklären.¹ Im dokumentierten Ablauf scheiterte der Bootstrap-Versuch an zu wenig Guthaben, während das Gateway anthropic/claude-opus-4-7 als aktives Modell ausgab.¹

Aus Sicht eines neuen Nutzers sieht das wie eine kaputte Installation aus: Setup beendet, Chat gestartet, Abbruch. Im Bericht wurde der Test mit einem LiteLLM-Beta-Key fortgesetzt.¹

Prüfe vor der Fehlersuche den aktiven Provider und die Abrechnungsvoraussetzung. Das spart Zeit, wenn der Fehler aus dem gewählten Default statt aus Windows oder dem API-Key kommt.

Ein Provider-Wechsel kann am alten Zustand hängen bleiben

Issue #88372 beschreibt den kritischeren Fall. Dort zeigte die TUI groq/llama-3.3-70b-versatile als aktiven Pfad, während der Request an einem Google-Authentifizierungsfehler scheiterte.² Anzeige und Laufzeit erzählten also verschiedene Geschichten.

Wer auf Groq schaut und einen Google-Fehler erhält, sucht leicht am falschen Ende: bei Credentials, Netzwerk oder Providerkonto, obwohl noch alte Referenzen wirksam sein können.

Laut Issue blieb der Zustand auch nach einer CLI-Umstellung auf litellm/openclaw-beta und nach dem Setzen von agents.defaults.model.primary bestehen.² Der Report nennt veraltete Referenzen bei agents.defaults.model.primary und in models.providers.litellm.models[].id.²

Der dokumentierte Recovery-Pfad ist aufwendig: Konfiguration manuell bearbeiten, ~\.openclaw\agents\main\sessions\sessions.json löschen, Gateway und TUI neu starten.² Führe solche Eingriffe nur mit einer Sicherung der betroffenen Dateien aus. Wenn dein Setup produktive Zugangsdaten nutzt, prüfe außerdem, welche Provider-Informationen und Sessions nach dem Reset neu eingerichtet werden müssen.

Der Korrekturpfad ist unter Windows schwer erkennbar

Issue #88373 beschreibt einen weiteren Stolperstein im Onboarding. Der Befehl openclaw onboard --auth-choice groq-api-key führte im dokumentierten Ablauf nicht direkt zu einer passenden Credential-Abfrage. Stattdessen erschien die Wahl zwischen „Review and update“ und „Start fresh“.³

Das bleibt mehr als UX-Reibung, wenn ein Default bereits Kosten auslösen kann und ein späterer Wechsel nicht zuverlässig alle Zustände aktualisiert. Nutzer brauchen dann einen klaren Weg zurück in die Credential-Einrichtung.

So grenzt du den Fehler ein

Wenn OpenClaw nach Einrichtung oder Provider-Wechsel widersprüchlich reagiert, arbeite in dieser Reihenfolge:

1. Notiere das in der TUI angezeigte Modell und den Provider aus der Fehlermeldung.
2. Prüfe, ob beide Angaben zusammenpassen.
3. Kontrolliere die wirksamen Modell- und Provider-Einträge in der Konfiguration.
4. Sichere Session-Dateien, bevor du einen dokumentierten Reset ausprobierst.
5. Starte Gateway und TUI neu und teste mit einem absichtlich einfachen Prompt.

Ein Widerspruch zwischen Anzeige und Request ist der zentrale Befund. Er spricht laut den Repros eher für einen Onboarding- oder Session-State-Fehler als für einen Tippfehler im Schlüssel.²

Die Mindestregel für den Windows-Einstieg

Die drei Issues beschreiben dieselbe Schwachstelle aus verschiedenen Richtungen: Provider-Auswahl, Modell-Default, Session-Zustand und UI-Signal müssen beim Wechsel zusammen aktualisiert werden. Issue #88372 ist im Tracker als P1 mit Auswirkungen auf Session-State und Auth-Provider markiert.²

Für mich ist die Mindestregel klar: Vor einem Request muss die aktive Route sichtbar sein. Nach einem Provider-Wechsel müssen Anzeige, Konfiguration und tatsächlicher Request übereinstimmen. Bis das zuverlässig klappt, lohnt sich bei widersprüchlichen Fehlern der Blick auf den gespeicherten Zustand, bevor du stundenlang den falschen API-Key suchst.

Für den grundlegenden Ablauf hilft auch die OpenClaw-Tutorial-Serie.

Footnotes

1. https://github.com/openclaw/openclaw/issues/88371 ↩ ↩² ↩³ ↩⁴ ↩⁵

2. https://github.com/openclaw/openclaw/issues/88372 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

3. https://github.com/openclaw/openclaw/issues/88373 ↩ ↩² ↩³