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

Wenn OpenClaw unter Windows nach der Einrichtung sofort schief wirkt, liegt das laut drei offenen GitHub-Issues derzeit nicht zwingend am API-Key. Die Berichte deuten eher auf einen Fehlerverbund aus Onboarding, Provider-Wechsel und Session-State hin. Für Entwickler ist das relevant, weil derselbe Ablauf wie ein lokaler Konfigurationsfehler aussieht, obwohl offenbar mehrere Zustände gegeneinander laufen.

Nach Angaben in den drei Issues stammen die Reproduktionen aus einem HeraldLabs-Beta-QA-Bericht vom 30. Mai 2026. Getestet wurde auf Windows 11 Version 25H2 und dem PowerShell-Installweg; die Meldungen beziehen sich ausdrücklich auf denselben OpenClaw-Release-Stand. Gerade diese klar beschriebene Umgebung macht die Fälle als Muster interessant: nicht als loser Einzelfund, sondern als wiederholbarer Einstiegspfad, der an mehreren Stellen kippt.

Schon der Start kann in die falsche Richtung laufen

Laut Issue #88371 kann der Windows-QuickStart den ersten Chat auf ein kostenpflichtiges Anthropic-Modell setzen, ohne vorab deutlich zu machen, dass dafür Guthaben nötig ist. Im dokumentierten Ablauf scheiterte der Bootstrap-Versuch an zu wenig Credit, während das Gateway anthropic/claude-opus-4-7 als aktives Modell ausgab.

Der technische Defekt ist damit noch nicht zwangsläufig eine kaputte Installation. Aus Nutzersicht sieht es aber genau so aus: Setup abgeschlossen, Chat gestartet, sofort ein Abbruch. Laut Issue musste der Test mit einem LiteLLM-Beta-Key entblockt werden. Die eigentliche Konsequenz ist deshalb nicht nur eine Fehlermeldung, sondern ein schlechter Diagnosepunkt direkt zu Beginn: Ist Windows das Problem, OpenClaw oder schlicht die Abrechnung des gerade aktiven Providers?

Beim Provider-Wechsel kann Anzeige und Laufzeit auseinanderfallen

Issue #88372 beschreibt den kritischeren Fall. Dem Report zufolge kann ein Provider-Wechsel unter Windows alte Modell- und Provider-Referenzen stehen lassen. Im Repro zeigte die TUI groq/llama-3.3-70b-versatile als aktiven Pfad, während der Request mit einem Google-Authentifizierungsfehler scheiterte.

Genau an dieser Stelle wird aus einer Konfigurationspanne ein Vertrauensproblem. Wenn die Oberfläche Groq signalisiert, die Fehlermeldung aber aus Googles Richtung kommt, sucht man an der falschen Stelle weiter. Laut Issue blieb der Zustand selbst dann bestehen, als per CLI auf litellm/openclaw-beta umgestellt und agents.defaults.model.primary neu gesetzt wurde. Der Bericht nennt dabei weiter veraltete Referenzen, unter anderem bei agents.defaults.model.primary und in models.providers.litellm.models[].id.

Auch der dokumentierte Reparaturweg spricht für einen tieferen State-Fehler statt für einen simplen Bedienfehler. Laut Issue half am Ende nur manuelles Bearbeiten der Konfiguration in Notepad plus das Löschen von ~\\.openclaw\\agents\\main\\sessions\\sessions.json, bevor Gateway und TUI neu gestartet wurden. Der gemeldete Aufwand lag bei mehr als einer Stunde und zusätzlicher Team-Unterstützung. Für jemanden, der OpenClaw gerade erst bewertet, ist das kein Detail, sondern der Punkt, an dem das Tool unzuverlässig wirkt.

Der vorgesehene Reparaturpfad ist vorhanden, aber schwer zu erkennen

Issue #88373 ergänzt das Bild. Laut dem Report gibt es zwar einen Weg, den Provider nach dem Onboarding zu wechseln, er ist aber unter Windows nicht klar ausgeschildert. Der Befehl openclaw onboard --auth-choice groq-api-key legt nahe, dass direkt die passende Credential-Abfrage folgt. Stattdessen landet man laut Issue bei der Wahl zwischen “Review and update” und “Start fresh”. Wer dort falsch abbiegt, bekommt keine API-Key-Abfrage zu sehen.

Für sich genommen wäre das vor allem UX-Reibung. Im Zusammenhang mit den beiden anderen Berichten wird daraus aber ein operatives Problem: Wenn ein teures Modell ohne klare Vorwarnung aktiv werden kann und der sichtbare Weg zum Provider-Wechsel nicht sauber führt, bleibt der ganze Einstieg halbtransparent. Dann scheitert nicht nur ein Chat, sondern auch die Selbstreparatur.

Die drei Issues zeigen denselben Bruch im Onboarding

Zusammengenommen erzählen die Berichte von einem gemeinsamen Kern: OpenClaw behandelt Provider-Auswahl, Modell-Defaults, Session-Zustand und UI-Signale laut den Issues noch nicht als eine einzige konsistente Onboarding-Transaktion. Genau daraus entsteht die Fehlerkette. Ein kostenpflichtiger Default sieht wie ein Installationsfehler aus. Ein Provider-Wechsel aktualisiert offenbar nicht alle wirksamen Referenzen. Und der Korrekturpfad ist so benannt, dass man ihn nicht sicher als Reparaturwerkzeug erkennt.

Für Entwickler ist daran vor allem eine Frage praktisch: Woran erkenne ich, ob mein Setup wirklich falsch ist oder ob OpenClaw gerade seinen eigenen Zustand nicht sauber umstellt? Die drei Reports liefern dafür eine brauchbare Faustregel. Wenn ein frisch eingerichteter Agent sofort an Billing scheitert oder nach einem Provider-Wechsel Fehlermeldungen aus einer anderen Modellfamilie auftauchen, spricht das laut der dokumentierten Repros eher für ein Onboarding- oder Session-State-Problem als für einen banalen Tippfehler im API-Key.

Die in den Issues angedeutete Richtung wirkt deshalb plausibel: ein Billing-Preflight vor Abschluss des Setups, ein echter Provider-Switch mit konsistenter Aktualisierung aller wirksamen Stellen, Cache-Invalidierung nach Auth-Änderungen und deutlichere Fehlermeldungen mit sichtbarer aktiver Route. Auch die Priorisierung passt dazu. Laut GitHub trägt Issue #88372 ein P1-Label und verweist auf impact:session-state sowie impact:auth-provider; Issue #88371 ist als P2, Issue #88373 als P3 markiert. Das legt nahe, dass nicht der sichtbare Stolperer am Anfang das größte Risiko ist, sondern der Moment, in dem Anzeige und tatsächlicher Request nicht mehr dieselbe Geschichte erzählen.

Für Windows-Nutzer bleibt damit vorerst ein nüchterner Schluss: Wenn OpenClaw nach der Einrichtung oder nach einem Provider-Wechsel widersprüchlich reagiert, lohnt sich der Blick auf Onboarding- und Session-State-Bugs mehr als die sofortige Jagd nach dem vermeintlich falschen Schlüssel. Genau dort entscheidet sich aktuell, ob OpenClaw als brauchbares Agenten-Frontend wirkt oder wie ein Tool, das seine Zustände nicht konsequent zusammenhält.