Grok-Cutover ohne großen Knall
TL;DR
Der Modellwechsel war nur die sichtbare Überschrift. Stabil wurde der Cutover erst, als die Script-Crons vom LLM-Default getrennt, Hermesto-Altzustände geleert und Night-Action-Berichte auf einen klaren Output-Vertrag gezogen wurden.
Basis in den Logs
- Grok-vs-Qwen-A/B-Test und Direct-Runner-Migration vom 27. bis 29. Mai 2026.
- Night-Action- und Cron-Watchdog-Nachlauf am 29. Mai 2026.
Was gemacht wurde
- OpenClaw-Default und Hermesto auf Grok über xAI gezogen.
- Aktive Script-Runner-Crons vom alten DashScope-Dauerpfad entkoppelt.
- Night-Action-Report-only-Lanes mit einem klaren Ergebnisvertrag versehen.
- Watchdog-Warnungen so gehärtet, dass optionale Scraper-Teile nicht den ganzen Morgen rot färben.
Verifiziert
- Mehrere Live-Telegram-Smokes und CEO-Zyklen wurden zugestellt.
- Night Action stand am 29. Mai 2026 nach dem Nachlauf auf grün.
- Der Watchdog-Dry-Run meldete keine offenen Issues.
Warum
Ein Modellwechsel ist erst dann wirklich erledigt, wenn die Betriebswege danach weniger fragil sind als vorher. Der Fortschritt lag deshalb nicht in der neuen Modellzeile, sondern in den klareren Verträgen rund um Cron, Telegram und Nachtläufe.
Grok-Cutover ohne großen Knall
Der sichtbare Schritt war simpel: OpenClaw sollte nicht mehr dauerhaft am Alibaba-/DashScope-Pfad hängen, sondern Grok über xAI nutzen.
Der eigentliche Schritt war weniger simpel.
Ein Agentensystem hängt nie nur an einem Modellnamen. Es hängt an Crons, alten Sessions, Watchdogs, Markdown-Formatierungen, Fallbackketten, Telegram-Zustellung und an der Frage, welche Aufgaben überhaupt ein Sprachmodell brauchen. Genau dort wurde der Cutover interessant.
Weg vom Modell als Allzweck-Router
Vor dem Umbau liefen viele Jobs formal über einen LLM-AgentTurn, obwohl sie inhaltlich nur deterministische Skripte starten mussten: Scraper, Datenabgleiche, Statuschecks.
Das ist bequem, aber teuer und fragil. Ein Modellwechsel betrifft dann plötzlich auch Aufgaben, die gar keine Modellleistung brauchen.
Die bessere Grenze ist: Datenjobs laufen direkt. Das Modell kommt erst dort dazu, wo wirklich Synthese, Entscheidung, Priorisierung oder Sprache nötig ist.
Hermesto musste den alten Zustand vergessen
Der Cutover war nicht mit einer Config-Zeile erledigt. Einige Telegram- und Hermes-Sessions trugen noch alte Provider-Zustände mit sich. Dadurch sah der neue Lauf von außen aus wie Grok, versuchte innen aber noch über einen alten Alibaba-Kontext zu sprechen.
Das war eine gute Erinnerung: Stateful-Systeme brauchen bei Provider-Wechseln nicht nur neue Defaults, sondern auch einen sauberen Session-Schnitt.
Der Morgen danach
Die erste Nacht zeigte genau die Sorte Fehler, die man bei so einem Wechsel sehen will: nicht still, sondern sichtbar.
Drei Night-Action-Blöcke wurden rot, obwohl sie im Kern eher an einem unklaren Report-only-Prompt hingen. Der Watchdog meldete zusätzlich falsche Warnungen, weil ein Log-Pattern zu breit matchte. Und ein Scraper hatte den wichtigsten Teil geschafft, schrieb aber wegen eines optionalen Nachlaufs keinen Erfolgsmarker.
Das wurde nicht als "Grok ist kaputt" behandelt, sondern als Betriebsvertrag-Problem:
- Report-only heißt jetzt: Aufgabe bearbeiten, Ergebnis strukturiert liefern.
- Watchdog-Pattern müssen präzise sein, nicht nur substring-schnell.
- Optionale Scraper-Teile dürfen einen erfolgreichen Kernlauf nicht komplett rot färben.
Was bleibt
Der Cutover ist damit kein finales Siegel, sondern ein besserer Beobachtungszustand.
Grok trägt jetzt echte Telegram- und Night-Action-Pfade. Die lauten Scheinfehler sind leiser. Die direkte Script-Ausführung reduziert unnötige Modellabhängigkeit. Und die finale Abo-Entscheidung wird erst nach ein paar echten Läufen getroffen, nicht aus Euphorie am ersten grünen Morgen.
Das ist der richtige Fortschritt: weniger Show, mehr Betriebssicherheit.