Fallback-Modelle einrichten, damit Claude Code bei Overload nicht stehenbleibt

Du sitzt mitten in der Arbeit, gibst einen Prompt ein, und Claude Code antwortet mit overloaded. Das Modell ist gerade ausgelastet, zu viele Leute gleichzeitig, und dein Turn bricht ab. Bei Opus passiert das öfter als bei den kleineren Modellen, weil Opus die teuerste und am stärksten nachgefragte Stufe ist. Anthropic hat die Rate-Limits für Claude Code zuletzt verdoppelt, was hilft, aber das Problem ist damit nicht weg.

Statt jedes Mal von Hand das Modell zu wechseln, kannst du Claude Code sagen, dass es bei einem ausgelasteten Modell automatisch auf das nächste ausweicht. Dafür gibt es seit Version 2.1.166 die fallbackModel-Einstellung, mit der du eine Kette aus bis zu drei Modellen baust. Fällt das erste aus, kommt das zweite, dann das dritte. Du merkst im besten Fall gar nicht dass etwas passiert ist, außer dass die Antwort von einem anderen Modell kommt. Ich zeige in zehn Schritten wie du das einrichtest, und genauso wichtig, was die Kette nicht abfängt.

1. Verstehen wann der Fallback überhaupt greift

Der Fallback ist für einen ganz bestimmten Fall gebaut: das primäre Modell ist überlastet oder gerade nicht verfügbar. Das ist der overloaded-Fehler. Genau dann probiert Claude Code das nächste Modell in deiner Kette.

Es ist kein Allheilmittel gegen jeden Fehler. Das ist die wichtigste Sache, die du gleich am Anfang verstehen solltest, sonst wunderst du dich später. Auf die Ausnahmen komme ich in Schritt 7.

2. Version prüfen

Die Kette aus mehreren Fallback-Modellen gibt es ab 2.1.166. Pruef kurz:

claude --version

Älter? Dann zuerst updaten, siehe Claude Code Update-Strategie. Das Update lohnt sich hier wirklich, denn vor 2.1.166 gab es nur einen einzelnen Fallback, und der griff nicht in interaktiven Sessions.

3. Eine sinnvolle Kette überlegen

Bevor du irgendwas in eine Datei schreibst, ueberleg dir die Reihenfolge. Die Logik ist simpel: oben das Modell das du eigentlich willst, darunter Ausweichoptionen die immer noch gut genug sind und seltener ausgelastet.

Eine typische Kette für jemand der normal auf Opus arbeitet sieht so aus: zuerst Opus, dann Sonnet, dann Haiku. Opus ist die stärkste Stufe und am häufigsten überlastet, Sonnet ist der solide Mittelweg, Haiku ist der Budget-Tier der fast immer verfügbar ist. So fällst du im Notfall lieber auf ein schwächeres Modell als gar keine Antwort zu bekommen. Wer die Unterschiede zwischen den Stufen nochmal sauber haben will, schaut in Level 1 Lektion Modelle im Vergleich.

4. Die Einstellung eintragen

Die fallbackModel-Einstellung kommt in deine settings.json. Global liegt die unter ~/.claude/settings.json, projektbezogen unter .claude/settings.json im Repo. Du trägst bis zu drei Modelle ein, die in dieser Reihenfolge probiert werden.

{
  "fallbackModel": ["sonnet", "haiku"]
}

Den genauen Model-Identifier nimmst du aus der aktuellen Doku, die Strings ändern sich mit jeder Modell-Generation. Wenn du unsicher bist welcher Name aktuell gilt, schau im Changelog oder in der Settings-Doku nach, beide sind unten verlinkt.

5. Den Fallback auch für einzelne Sessions setzen

Du musst es nicht fest in die Settings schreiben. Für einen einzelnen Lauf gibt es das Flag:

claude --fallback-model sonnet

Seit 2.1.166 wirkt dieses Flag auch in interaktiven Sessions, nicht mehr nur im Headless-Modus. Das ist praktisch, wenn du nur für heute eine Ausweichoption willst, ohne deine globale Config anzufassen.

6. Testen ohne auf den nächsten Overload zu warten

Du willst nicht erst beim nächsten echten Overload merken, dass deine Kette nicht stimmt. Der pragmatische Test: setz als primäres Modell kurz einen Namen den es nicht gibt, oder ein Modell auf das du keinen Zugriff hast, und schau ob Claude Code sauber auf den ersten Fallback springt. Wenn das klappt, weißt du dass die Kette greift. Danach stellst du das richtige primäre Modell zurück.

7. Was die Kette nicht abfängt

Hier ist die Stelle an der die meisten falsche Erwartungen haben. Der Fallback greift bei overloaded und bei nicht verfügbar. Er greift nicht bei diesen Fehlern:

Auth-Fehler, also ein abgelaufener Token oder fehlende Berechtigung. Rate-Limit-Fehler, wenn du dein eigenes Kontingent gesprengt hast. Request-Size-Fehler, wenn dein Prompt oder Kontext schlicht zu groß ist. Und Transport-Fehler, also Netzwerkprobleme. Diese vier kommen sofort bei dir an, ohne Umweg über ein anderes Modell, weil ein anderes Modell sie genauso ablehnen würde. Claude Code probiert bei einem unerwarteten, nicht wiederholbaren API-Fehler den Turn zwar einmal auf dem Fallback-Modell erneut, aber die genannten vier Fehlertypen schlagen direkt durch.

Das ist gut so. Es wäre Unsinn, bei einem abgelaufenen Token drei Modelle durchzuprobieren. Aber du musst es wissen, sonst suchst du den Fehler an der falschen Stelle.

8. Mit Kostenkontrolle kombinieren

Ein Fallback auf ein günstigeres Modell ist nebenbei auch ein Kostenhebel. Wenn deine Kette von Opus auf Sonnet fällt, wird der Turn billiger, nicht teurer. Aber Vorsicht in die andere Richtung: eine Kette die nach unten zeigt ist gut, eine die aus Versehen ein teureres Modell als Fallback hat, kostet dich im Overload-Fall mehr. Bau die Kette also immer absteigend.

Wer seine Ausgaben grundsätzlich im Griff haben will, kombiniert das mit dem Playbook Cost-Controls für den Daily Driver. Fallback und Budget-Limits arbeiten gut zusammen.

9. Die Modell-Namen aktuell halten

Das ist die Falle die dich in ein paar Monaten erwischt. Modell-Namen veralten. Wenn eine neue Generation rauskommt und die alte abgeschaltet wird, zeigt deine Kette plötzlich auf ein Modell das es nicht mehr gibt, und der Fallback läuft ins Leere. Setz dir das auf den Schirm: bei jeder größeren Modell-Migration auch die fallbackModel-Einträge durchgehen. Wie so eine Migration abläuft, steht im Playbook Opus 4.8 Migration.

10. Realistisch bleiben, wann es sich lohnt

Wenn du viel auf Opus arbeitest und regelmäßig overloaded siehst, ist die Kette ein klarer Gewinn, du verlierst keine Turns mehr. Wenn du sowieso meist auf Sonnet oder Haiku unterwegs bist, die selten ausgelastet sind, brauchst du das kaum. Und wenn deine Abbrüche in Wahrheit Auth- oder Netzwerkprobleme waren, hilft dir der Fallback gar nicht, dann gehörst du eher in das Playbook Claude Code spinnt nach einer Config-Änderung und schaust dort Schritt 9.

Was als nächstes

Wenn du gerade dabei bist dein Setup robuster zu machen, ist das Companion-Playbook Claude Code spinnt nach einer Config-Änderung der nächste logische Schritt, denn nicht jeder Abbruch ist ein Overload. Für den größeren Zusammenhang Modelle und Kosten lohnt Level 1 Lektion Modelle im Vergleich.

Source

• Claude Code Changelog, Version 2.1.166 (fallbackModel, --fallback-model in interaktiven Sessions, Fehler-Verhalten bei auth/rate-limit/request-size/transport): https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
• Claude Code Settings-Doku: https://code.claude.com/docs/en/settings