Modell-Ausfallsicherung

Eine gute Ausfallsicherung ist wie die Notstromversorgung in einem Krankenhaus. An normalen Tagen redet kaum jemand darüber. Dann flackert das Licht, irgendwo bricht etwas weg, und plötzlich ist der Sinn glasklar.

Genau das ist die Aufgabe von Modell-Failover in OpenClaw. Dein Agent sollte nicht einfrieren, nur weil ein Provider timed out, ein Auth-Profil an eine Quota-Grenze stößt oder ein Modell plötzlich Unsinn liefert. Ein belastbares Setup bleibt in Bewegung.

Dieser Guide zeigt dir, wie OpenClaw Failover aktuell behandelt, was zuerst erneut versucht wird, wann Modelle gewechselt werden und wie du eine Fallback-Kette konfigurierst, die hilft statt Chaos zu erzeugen.

Was OpenClaw tut, bevor es aufgibt

Die aktuellen OpenClaw-Dokumente beschreiben Failover als zweistufigen Prozess:

1. Auth-Profil-Rotation innerhalb des aktuellen Providers
2. Modell-Fallback zum nächsten Modell in deiner konfigurierten Kette

Diese Reihenfolge ist wichtig. Wenn dein Anthropic-Setup mehrere Auth-Profile hat, versucht OpenClaw zuerst dort den gesünderen Pfad, bevor es zu einem anderen Provider oder Modell springt. Das ist sauberer, oft günstiger und meist schneller als ein sofortiger Provider-Wechsel.

Warum dieses Design klüger ist als blindes Retrieschleifen

Das frühe Internet wurde belastbar, weil Pakete um kaputte Knoten herumgeroutet werden konnten, statt auf einem perfekten Pfad zu bestehen. OpenClaw nutzt dieselbe Idee für Modell-Ausführung. Es geht nicht davon aus, dass die erste Route immer gesund bleibt. Es hält einen geordneten Ausweg bereit.

Das ist besser als blinde Retry-Loops. Blinde Retries kosten Zeit, verbrennen Rate Limits und lassen Nutzer auf eine stehende Sitzung starren. Geordnetes Failover trifft eine Entscheidung: erst die naheliegende sichere Option probieren, dann weiterziehen.

Der Runtime-Ablauf in einfachem Deutsch

Für normale Textläufe beschreiben die aktuellen Docs diese Reihenfolge:

• Den aktiven Modell- und Auth-Zustand der Sitzung auflösen
• Die Kandidatenkette aus Primary-Modell plus konfigurierten Fallbacks bauen
• Den aktuellen Provider mit Auth-Rotationsregeln probieren
• Nur dann zum nächsten Modell weitergehen, wenn der Provider-Pfad mit einem failover-würdigen Fehler erschöpft ist
• Das gewählte Fallback vor dem Retry als Override speichern, damit der Rest der Sitzung denselben sicheren Pfad sieht
• Nur die fallback-eigenen Felder zurückrollen, falls auch dieser Kandidat scheitert

Der feine Unterschied ist das Speichern. OpenClaw schaltet nicht nur für eine Antwort um und vergisst es wieder. Es kann das Fallback als automatisches Sitzungs-Override markieren. So wird das bekannte Problem-Primary nicht beim nächsten Turn sofort wieder angetippt.

Grundkonfiguration für Fallbacks

Wenn du Failover willst, definiere es bewusst. Das Grundmuster ist simpel:

{
  agents: {
    defaults: {
      model: {
        primary: "anthropic/claude-sonnet-4-6",
        fallbacks: [
          "openai/gpt-5.5",
          "openrouter/moonshotai/kimi-k2"
        ],
      },
    },
  },
}

Betrachte die Reihenfolge als Betriebsentscheidung, nicht als Deko.

• Fallback 1: das Modell, dem du am meisten vertraust, wenn das Primary schlingert
• Fallback 2: das Modell, das den Dienst am Leben hält, wenn beide Premium-Pfade wegkippen
• Spätere Einträge: nur dann, wenn du einen echten Grund hast und sie getestet wurden

Mehr Optionen sind nicht automatisch besser. Lange Ketten verstecken Probleme und machen das Verhalten schwerer vorhersehbar.

Auth-Rotation kommt zuerst

OpenClaw trennt Provider-Auth von Modell-Auswahl. Klingt trocken. Ist es nicht. Wenn du mehrere API-Keys oder OAuth-Profile für denselben Provider betreibst, kann OpenClaw erst zwischen ihnen rotieren, bevor der Provider komplett verlassen wird.

Die Docs nennen außerdem eine Sitzungs-Stickiness-Regel: Sobald OpenClaw ein Auth-Profil für eine Sitzung gewählt hat, bleibt es in der Regel dabei, bis die Sitzung zurückgesetzt wird, eine Compaction den Zustand verändert oder das Profil in Cooldown geht. Das hält Provider-Caches wärmer und vermeidet unnötiges Hin-und-her.

Wann Auth-Reihenfolge wichtig wird

Wenn ein Profil dein bezahlter Produktionspfad ist und ein anderes nur dein Backup, dann mach das explizit. Hoffnung ist keine Konfiguration.

{
  auth: {
    order: {
      anthropic: [
        "anthropic:team-primary",
        "anthropic:backup-key"
      ],
    },
  },
}

Was typischerweise Failover auslöst

Auf Basis der aktuellen offiziellen Docs sind failover-würdige Fehler breiter als einfache HTTP-429-Antworten. OpenClaw kann bei diesen Fällen rotieren oder weiterfallen:

• Rate Limits: inklusive Concurrency-Grenzen und temporärer Usage-Windows
• Transiente Timeouts: wenn der Provider-Pfad überlastet oder instabil wirkt
• Auth-Fehler: abgelaufene oder unbrauchbare Credentials
• Manche Format- oder Stop-Reason-Fehler: wenn der Provider-Pfad für die Anfrage klar ungesund ist
• Billing-Sperren: wenn ein Profil faktisch außer Betrieb ist

Danach arbeitet OpenClaw mit exponentiellen Cooldowns. Laut aktuellem Doc sind das 1 Minute, 5 Minuten, 25 Minuten und dann maximal 1 Stunde. Genau so soll es sein. Ein schlechtes Profil soll erst einmal abkühlen. Es soll nicht in jedem Turn erneut Prügel beziehen.

Strikte Overrides sind absichtlich strikt

Das überrascht viele. Wenn du mit /model manuell ein Modell für die Sitzung auswählst, behandeln die aktuellen Docs das als User-Override und nicht als höfliche Empfehlung.

Anders gesagt:

• Konfigurierter Default: darf die Fallback-Kette durchlaufen
• Automatisches Runtime-Fallback: darf die konfigurierte Kette weitergehen
• Manuell gewähltes Sitzungsmodell: scheitert sichtbar, wenn genau dieses Modell nicht erreichbar ist

Das ist richtig so. Wenn du ausdrücklich ein bestimmtes Modell angefordert hast, wäre stilles Ersetzen verwirrend und manchmal riskant.

Cron-Jobs folgen einer leicht anderen Regel

Cron-Modellauswahl wird eher wie ein Job-Primary behandelt als wie ein manueller User-Override. Die aktuellen Docs sagen: Ein Modell im Cron-Payload nutzt weiterhin konfigurierte Fallbacks, außer du machst den Lauf ausdrücklich strikt.

{
  model: "openai/gpt-5.5",
  fallbacks: [],
}

Dieses kleine leere Array ist wichtig. Es sagt OpenClaw: "rette diesen Lauf nicht mit einem anderen Modell." Das ist nützlich für Tests, Audits und Jobs, bei denen exakte Reproduzierbarkeit wichtiger ist als Kontinuität.

So prüfst du deinen Failover-Zustand

Wenn du nicht sicher bist, was OpenClaw tun wird, prüfe es statt zu raten:

openclaw models status
openclaw models fallbacks list
openclaw models list

Die aktuellen CLI-Dokumente beschreiben openclaw models status als die Stelle, an der du Default-Modell, Fallback-Kette und Auth-Überblick zusammen siehst. Aktiviere Probes nur dann, wenn du wirklich Live-Checks brauchst, denn Probes sind echte Requests und können Tokens verbrauchen.

Praktische Regeln für bessere Fallback-Ketten

1. Mach dein Fallback nicht auf die falsche Weise schwächer

Günstiger ist okay. Zu schwach für Tools ist es nicht. Ein Fallback, das deine normale Prompt-Form nicht tragen kann, ist keine Resilienz. Es ist nur ein verzögertes Scheitern.

2. Verteile über Provider hinweg, wenn Uptime zählt

Wenn Primary und erster Fallback denselben Provider-Fehlerraum teilen, hast du ein Backup gebaut, das im selben brennenden Gebäude steht.

3. Halte den Prompt-Vertrag kompatibel

Wenn ein Modell in der Kette Tools, langen Kontext oder Bilder deutlich anders behandelt, teste es mit echten Workloads. Fallback bedeutet nicht nur Verfügbarkeit. Es bedeutet, denselben Job mit erträglicher Ergebnisqualität zu überleben.

4. Entscheide bewusst, wann strikt besser ist

Für Evaluierungen, regulierte Workflows oder Side-by-Side-Tests sind strikte Läufe sauberer. Für Support-Kanäle und nutzernahe Agenten gewinnt meist Kontinuität.

Häufige Fehler

• Gar keine Fallbacks: ein Provider-Wackler wird zum Totalausfall
• Zu viele Fallbacks: Debugging wird zu Archäologie
• Nur Fallbacks beim selben Provider: besser als nichts, aber schwächer als es aussieht
• Auth-Rotation vergessen: manchmal ist nicht der Provider kaputt, sondern nur ein Credential
• Glauben, dass manuelle Modellwahl sich selbst rettet: tut sie meist nicht, und das absichtlich

Zusammenfassung

Modell-Ausfallsicherung ist nicht da, damit dein Setup sophisticated aussieht. Sie ist da, damit dein Agent weiterläuft, wenn echte Systeme sich wie echte Systeme verhalten.

Setze ein starkes Primary. Ergänze eine kurze, bewusste Fallback-Kette. Teste sie mit echten Workloads. Und halte dich an das Sprichwort, das oft China zugeschrieben wird: Grabe den Brunnen, bevor du Durst hast.