# Backup-Modelle für KI-Agenten: So bleibt Ihr Agent aktiv, wenn ein Modell ausfällt

> So funktionieren Backup-Modelle für KI-Agenten, welche Fehler einen Fallback auslösen sollten, warum sich das Backup anders verhält und wie Sie es vor einem Ausfall testen.

Last updated: 2026-09-28T14:00:00

Canonical URL: https://crevio.co/de/blog/ai-agent-backup-models

*Zuletzt aktualisiert: September 2026. Statusseiten, Incident Reports und Dokumentationen geprüft am 28. September 2026.*

**Das Modell Ihres Agenten wird ausfallen – und das Backup-Modell, das Sie dafür eingerichtet haben, wird sich nicht wie das Modell verhalten, mit dem Sie getestet haben.** Am 28. September 2026 wies die Statusseite der Claude API für die vorangegangenen 90 Tage eine Verfügbarkeit von 99,52 % aus. Das klingt fast perfekt, bis man nachrechnet: 0,48 % von 90 Tagen entsprechen in einem Quartal ungefähr 10 Stunden mit eingeschränktem oder nicht verfügbarem Service. Ein Backup-Modell für KI-Agenten sorgt dafür, dass Ihr Agent diese Stunden übersteht. Unsauber eingerichtet, sorgt es aber auch dafür, dass eine Aufgabe auf einem Modell, das noch niemand ausprobiert hat, unbemerkt nur halb abgeschlossen wird.

Dieser Leitfaden richtet sich an Geschäftsinhaber und Betreiber, die Agenten nach Zeitplan oder im direkten Kundenkontakt einsetzen. Sie erfahren, was ausfällt, welche Fehler einen Wechsel auslösen sollten, wie die gängigen Routing-Tools damit umgehen und wie Sie Ihren Fallback testen, bevor Sie ihn benötigen.

- **Drei verschiedene Fehler sehen von außen gleich aus:** Ausfälle, Rate Limits und eingestellte Modelle. Nur bei einigen davon ist ein Backup-Modell die richtige Lösung
- **Erst wiederholen, dann wechseln.** Viele Fehler verschwinden nach einem kurzen erneuten Versuch oder bei einem anderen Host, auf dem dasselbe Modell läuft
- **Ein Backup-Modell ist keine direkt austauschbare Kopie.** Neuere Modelle lehnen Parameter ab, die ältere noch akzeptiert haben, der Tool-Aufruf unterscheidet sich und der aufgewärmte Prompt-Cache ist nicht mehr vorhanden
- **Fallbacks kosten pro Schritt mehr als erwartet,** weil das Backup mit einem leeren Cache startet
- **Ein ungetesteter Fallback ist reine Spekulation.** Erzwingen Sie absichtlich einen Fehler, führen Sie echte Aufgaben mit dem Backup aus und protokollieren Sie, welches Modell geantwortet hat

## Was ist ein Backup-Modell für einen KI-Agenten?

Ein Backup-Modell für einen KI-Agenten, oft als LLM-Fallback bezeichnet, ist ein zweites Modell, das im Voraus eingerichtet wird und übernimmt, wenn das Hauptmodell des Agenten nicht antworten kann. Der Wechsel erfolgt normalerweise automatisch: Ein Router oder Gateway erkennt den Fehler, sendet dieselbe Anfrage an das nächste Modell in einer Liste und gibt die Antwort zurück, als wäre nichts passiert.

Es ist eine von vier Schutzebenen – und sollte die dritte sein, zu der Sie greifen, nicht die erste:

| Ebene | Funktion | Behebt | Ändert das Modell? |
|---|---|---|---|
| **Erneuter Versuch** | Sendet dieselbe Anfrage nach kurzer Wartezeit erneut | Kurzzeitige Spitzen, einmalige Timeouts | Nein |
| **Host-Failover** | Sendet die Anfrage an einen anderen Anbieter, bei dem dasselbe Modell läuft | Ausfall eines Rechenzentrums oder Hosts | Nein |
| **Modell-Fallback** | Sendet die Anfrage an ein anderes Modell | Komplette Ausfälle, erschöpfte Kontingente | Ja |
| **Geplanter Wechsel** | Stellt den Agenten absichtlich auf ein neues Modell um | Einstellungen und Abkündigungen | Ja, dauerhaft |

Die Reihenfolge ist wichtig, weil jeder Schritt weiter unten in der Tabelle das Verhalten Ihres Agenten stärker verändert. Ein erneuter Versuch ändert nichts. Ein anderes Modell verändert dagegen fast alles, wie die folgenden Abschnitte zeigen.

## Drei Arten, wie Ihr Hauptmodell ausfällt

### Ausfälle

Jeder große Anbieter hatte bereits Ausfälle, und die Incident Reports sind öffentlich. Am 11. Dezember 2024 waren [alle OpenAI-Dienste erheblich beeinträchtigt oder nicht verfügbar](https://status.openai.com/incidents/ctrsv3lwd797) – von 15:16 bis 19:38 Uhr Pacific Time, also 4 Stunden und 22 Minuten lang. Betroffen waren ChatGPT, die API und Sora. Ursache war ein neuer Telemetriedienst, der die Kubernetes-Control-Plane von OpenAI überlastete. Der Fehler trat nur in großen Clustern auf und wurde deshalb beim Testen nicht entdeckt.

![Incident auf der OpenAI-Statusseite vom 11. Dezember 2024, als behoben und vollständiger Ausfall markiert; angezeigt werden 9 betroffene API-Komponenten und 5 betroffene ChatGPT-Komponenten mit roten und gelben Statusbalken](https://crevio.co/vite/assets/openai-status-december-2024-incident-gqiohlkd.png)

Kürzere Ausfälle kommen weitaus häufiger vor. Am 4. März 2026 meldete OpenAI [30 Minuten lang erhöhte API-Fehlerraten](https://status.openai.com/incidents/01KJXQDJ6P1CG5YNXKZRY2H6RX/write-up), nachdem mehrere verzögerte Kapazitätsänderungen gleichzeitig ausgeführt worden waren und Inference-Engines außer Betrieb setzten. Die Statusseite von Anthropic zeigt dasselbe Muster: lange grüne Phasen mit einer stetigen Streuung kurzer roter und gelber Abschnitte.

![Claude-Statusseite mit „All Systems Operational“ und Verfügbarkeitsbalken für 90 Tage: claude.ai mit 99,43 %, Claude Console mit 99,95 % und Claude API mit 99,52 %](https://crevio.co/vite/assets/claude-status-page-eal06oie.png)

Ein 30-minütiger Ausfall fällt beim Chatten kaum auf. Für eine geplante Aufgabe, die genau in diesem Zeitraum startet, ist er jedoch sehr relevant – denn niemand ist da, um auf „Erneut versuchen“ zu klicken.

### Rate Limits und 429-Fehler

Ein 429-Fehler bedeutet, dass der Anbieter verfügbar ist, Ihre Anfrage aber gerade nicht bedient. Meist handelt es sich um ein Limit pro Minute: Die API von Anthropic verwendet einen [Token-Bucket, der kontinuierlich aufgefüllt wird](https://platform.claude.com/docs/en/api/rate-limits), und sendet einen `retry-after`-Header mit der Anzahl der Sekunden, die Sie warten sollten. So lange zu warten und dasselbe Modell erneut anzufragen, ist der richtige Schritt.

Allerdings ist nicht jeder 429-Fehler vorübergehend. Wenn eine Anthropic-Organisation ihr monatliches Ausgabenlimit erreicht, gibt die API einen 429-Fehler **ohne** `retry-after`-Header zurück. Die Dokumentation formuliert es unmissverständlich: „Erneute Versuche – einschließlich der automatischen Wiederholungen der SDKs – schlagen fehl, bis der Zugriff wiederhergestellt ist.“ Der Zugriff wird zu Beginn des nächsten Monats wieder freigeschaltet. Ein Agent, der jeden 429 als „warten und erneut versuchen“ behandelt, wird die ganze Nacht ein Limit abfragen, das sich möglicherweise erst in Wochen zurücksetzt.

### Abkündigungen und Einstellungen

Modelle werden nach einem Zeitplan eingestellt und fallen nicht allmählich aus. Die [Abkündigungsrichtlinie von Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) garantiert für öffentlich veröffentlichte Modelle eine Vorankündigung von mindestens 60 Tagen und stellt klar: „Anfragen an Modelle nach dem Einstellungsdatum schlagen fehl.“ Claude Opus 4.1 ist ein aktuelles Beispiel: Entwickler wurden am 5. Juni 2026 informiert, das Modell wurde am 5. August 2026 eingestellt.

![Seite der Claude Platform Docs zu Modellabkündigungen mit den Lebenszyklusphasen Active, Legacy, Deprecated und Retired sowie dem Hinweis, dass abgekündigte Modelle wahrscheinlich weniger zuverlässig sind als aktive Modelle](https://crevio.co/vite/assets/claude-model-deprecations-gt44ujck.png)

Die [Abkündigungsseite von OpenAI](https://developers.openai.com/api/docs/deprecations) sieht für allgemein verfügbare Modelle in der Regel eine Vorankündigung von mindestens sechs Monaten vor. Für Preview-Modelle gilt jedoch: Sie „können mit deutlich kürzerer Vorankündigung eingestellt werden, etwa zwei Wochen“. Im Juni 2026 kündigte OpenAI an, dass die GPT-5- und o3-Snapshots am 11. Dezember 2026 abgeschaltet werden. Ein Backup-Modell löst eine Einstellung nicht. Es kaschiert sie nur, bis auch das Backup eingestellt wird.

### Der Fehler, den kein Fallback auffängt

Der teuerste Fehler löst nie eine Fehlermeldung aus. 2025 veröffentlichte Anthropic [einen Postmortem-Bericht zu drei Infrastrukturfehlern](https://www.anthropic.com/engineering/a-postmortem-of-three-recent-issues), die die Antworten von Claude über Wochen beeinträchtigten. In der schlimmsten Stunde waren 16 % der Sonnet-4-Anfragen von einem dieser Fehler betroffen. Ein Grund, warum die Suche so lange dauerte: „Claude erholt sich oft gut von einzelnen Fehlern“, wodurch das Problem verborgen blieb.

Keine Fallback-Kette wird wegen einer schlechteren Antwort ausgelöst, denn auch eine schlechtere Antwort liefert weiterhin einen HTTP-Status 200. Dafür brauchen Sie [Stichproben der vom Agenten erzeugten Ergebnisse](/de/blog/human-in-the-loop-ai-agents), nicht Routing.

## Welche Fehler sollten auf ein Backup-Modell für KI-Agenten umschalten?

Lesen Sie den Fehler, bevor Sie reagieren. Dasselbe „Das Modell ist fehlgeschlagen“ kann bedeuten: fünf Sekunden warten, sofort wechseln oder Ihre eigene Anfrage korrigieren.

![Fünf Anbieterausfälle und die jeweils richtige Reaktion: bei einem 429 mit retry-after warten und erneut versuchen, bei einem 429 ohne retry-after zum Backup wechseln, bei 5xx-Fehlern oder Timeouts erst erneut versuchen, dann den Host wechseln und anschließend umschalten, bei einem 400-Fehler die Anfrage korrigieren und vor einer Einstellung das Ersatzmodell aktivieren](https://crevio.co/vite/assets/which-failures-need-a-backup-model-mvzdhotu.svg)

Zwei Zeilen verdienen einen genaueren Blick:

- **5xx-, Überlastungs- und Timeout-Fehler.** Die [Fehlerreferenz von Anthropic](https://platform.claude.com/docs/en/api/errors) führt einen `overloaded_error` für hohen Datenverkehr bei allen Nutzern auf. Die SDKs wiederholen vorübergehende Fehler bereits zweimal mit exponentiellem Backoff. Ein weiterer Versuch ist in Ordnung. Fünf Versuche machen aus einer 30-sekündigen Störung jedoch einen zehnminütigen Stillstand
- **400-Fehler.** Ein falscher Parameter oder eine fehlerhafte Anfrage schlägt auch beim Backup fehl, oft aus demselben Grund. Eine Ausnahme ist ein zu langer Prompt: Einige Router senden ihn stattdessen an ein Modell mit größerem Kontextfenster – ein Fallback, der tatsächlich hilft

## So funktionieren Fallback-Ketten und Routing

In den seltensten Fällen entwickeln Sie die Fallback-Logik selbst. Eine Routing-Schicht zwischen Ihrem Agenten und den Anbietern übernimmt das. Vier Lösungen sind besonders verbreitet:

| Tool | So richten Sie das Backup ein | Was löst den Wechsel aus? | Woran sehen Sie, welches Modell geantwortet hat? |
|---|---|---|---|
| **OpenRouter** | Ein `models`-Array in Prioritätsreihenfolge | Ausfallzeiten, Rate Limits, Fehler wegen der Kontextlänge, Moderationsmarkierungen | Das Feld `model` in der Antwort |
| **LiteLLM** | `fallbacks` sowie separate Fallbacks für Kontextfenster und Inhaltsrichtlinien | Rate Limits und Serverfehler, mit Abkühlphasen nach wiederholten Fehlern | Proxy-Logs und Callbacks |
| **Vercel AI Gateway** | Ein `models`-Array, kombiniert mit einem Anbieter-`order` | Jeder Fehler aller Anbieter für ein Modell | Eine Liste von `modelAttempts` in den Anbieter-Metadaten |
| **Cloudflare AI Gateway** | Eine Liste von Schritten auf dem Universal-Endpunkt | Fehler und Timeouts von Anfragen | Der `cf-aig-step`-Response-Header |

[Die Modell-Fallbacks von OpenRouter](https://openrouter.ai/docs/guides/routing/model-fallbacks) sind am einfachsten zu verstehen: Sie übergeben eine Liste von Modell-IDs, und „wenn das erste Modell einen Fehler zurückgibt, versucht OpenRouter automatisch das nächste Modell in der Liste“. Abgerechnet wird der Preis des Modells, das letztlich geantwortet hat. Das [Provider-Routing](https://openrouter.ai/docs/guides/routing/provider-selection) übernimmt separat das Host-Failover für dasselbe Modell. Standardmäßig werden Anbieter bevorzugt, die „in den letzten 30 Sekunden keine erheblichen Ausfälle verzeichnet haben“. `allow_fallbacks` bleibt aktiviert, sofern Sie es nicht ausschalten.

![Dokumentationsseite von OpenRouter zu Modell-Fallbacks: Der Parameter models versucht automatisch andere Modelle, wenn die Anbieter des primären Modells ausgefallen sind, ein Rate Limit erreicht wurde oder keine Antwort liefern](https://crevio.co/vite/assets/openrouter-model-fallbacks-docs-k3qy0sqx.png)

[Die Zuverlässigkeitseinstellungen von LiteLLM](https://docs.litellm.ai/docs/proxy/reliability) unterteilen das Problem genauer. Gewöhnliche `fallbacks` decken Rate Limits und Serverfehler ab, `context_window_fallbacks` leiten einen zu großen Prompt an ein größeres Modell weiter und `content_policy_fallbacks` fangen Fehler aufgrund von Inhaltsrichtlinien ab. `allowed_fails` und `cooldown_time` nehmen ein fehlerhaftes Modell vorübergehend aus dem Rotationsverfahren, damit ein überlasteter Anbieter nicht bei jeder Anfrage erneut belastet wird.

[Die Modell-Fallbacks des Vercel AI Gateway](https://vercel.com/docs/ai-gateway/models-and-providers/model-fallbacks) kombinieren beide Ebenen: Zuerst werden alle zulässigen Anbieter für das primäre Modell ausprobiert. Anschließend wird zum nächsten Modell im `models`-Array gewechselt und jeder Versuch protokolliert. Die [Fallbacks des Cloudflare AI Gateway](https://developers.cloudflare.com/ai-gateway/configuration/fallbacks/) funktionieren über den Universal-Endpunkt und geben in einem Header an, woher die Antwort stammt: `cf-aig-step: 0` bedeutet, dass das primäre Modell geantwortet hat, `1`, dass dies das erste Fallback war.

Für alle vier gilt jedoch eine wichtige Einschränkung. **Das Gateway ist ebenfalls eine Abhängigkeit.** Das eigene Netzwerk von Cloudflare hatte am [18. November 2025](https://blog.cloudflare.com/18-november-2025-outage/) von 11:20 bis 17:06 Uhr UTC einen größeren Ausfall, nachdem sich eine fehlerhafte Konfigurationsdatei im gesamten Netzwerk verbreitet hatte. Eine Fallback-Kette schützt Sie vor dem Ausfall eines Modellanbieters. Sie schützt Sie nicht vor der Schicht, die diese Kette ausführt.

## Warum sich ein Backup-Modell für KI-Agenten anders verhält

Ein Fallback, das eine Antwort liefert, hat die Aufgabe nicht unbedingt erledigt. Agenten sind in dieser Hinsicht anfälliger als Chatbots, weil sich ein Agent beim Wechsel mitten in einer mehrstufigen Aufgabe befindet und eine lange Historie von Tool-Aufrufen mitführt, die das neue Modell übernehmen muss.

![Was sich beim Wechsel eines Agentenmodells ändert: Beim Wechsel zu demselben Modell auf einem anderen Host bleiben Prompt-Verhalten, Tool-Call-Format, Parameter und Kontextfenster erhalten. Ein neueres Modell desselben Anbieters oder ein Modell eines anderen Anbieters verändert dagegen die meisten dieser Punkte, und jeder Wechsel verliert den aufgewärmten Prompt-Cache](https://crevio.co/vite/assets/what-changes-when-an-agent-switches-models-nxjdqm6x.svg)

### Parameter, die ein Modell akzeptiert und ein anderes ablehnt

Das kann sogar innerhalb eines Anbieters passieren. Laut den [Abkündigungshinweisen von Anthropic](https://platform.claude.com/docs/en/about-claude/model-deprecations) und der [Fehlerreferenz](https://platform.claude.com/docs/en/api/errors) gilt:

- Wenn Sie `temperature`, `top_p` oder `top_k` auf einen Wert ungleich dem Standard setzen, gibt Claude Opus 4.7 und höher einen 400-Fehler zurück
- Das Erzwingen eines bestimmten Tools mit `tool_choice` gibt bei Claude Opus 5.5, Sonnet 5.5 und Fable 5.1 einen 400-Fehler zurück
- Das Voranstellen des Beginns der Assistant-Antwort gibt bei Claude 4.6 und späteren Modellen einen 400-Fehler zurück

Eine Kette, die von einem älteren auf ein neueres, „besseres“ Modell wechselt, kann also sofort mit einem Fehler scheitern, den das primäre Modell nie erzeugt hat. Die Option [`require_parameters` von OpenRouter](https://openrouter.ai/docs/guides/routing/provider-selection) existiert teilweise genau deshalb: Sie leitet nur an Anbieter weiter, die jeden von Ihnen gesendeten Parameter unterstützen.

### Tool-Aufrufe und Prompts

Verschiedene Anbieter erwarten Tools, Ergebnisse und Reasoning in unterschiedlichen Formaten. Ein anbieterübergreifender Fallback hängt daher davon ab, dass das Gateway die Unterhaltung korrekt übersetzt. Selbst wenn das Format erhalten bleibt, ist das Backup nicht das Modell, auf dessen Verhalten Sie Ihre Anweisungen abgestimmt haben. Es ruft Tools möglicherweise in einer anderen Reihenfolge auf, bricht früher ab oder versteht „Fasse dich kurz“ als „Überspringe die Prüfung“. Bestimmte Reasoning-Daten werden überhaupt nicht übernommen: Anthropic weist darauf hin, dass ein Thinking-Block „von einem Modell, das das Zielmodell nicht lesen kann, verworfen wird“.

### Kontextfenster

Wenn das Backup weniger Kontext als das primäre Modell verarbeiten kann, ist ein langer Agentenlauf möglicherweise genau in dem Moment zu groß, in dem das Backup übernimmt. Deshalb führt OpenRouter Fehler wegen der Kontextlänge als Fallback-Auslöser auf, und LiteLLM stellt dafür eine eigene Fallback-Liste bereit. Nehmen Sie ein Backup mit mindestens so großem Kontextfenster wie das primäre Modell in die Kette auf oder lassen Sie den Agenten den älteren Verlauf vor dem Wechsel zusammenfassen.

## Was Fallbacks kosten

Ein Backup-Modell verändert die Rechnung auf drei Arten – und keine davon ist in einer Preisvergleichstabelle zu sehen.

**Der aufgewärmte Cache ist weg.** Prompt-Caching ist ein wesentlicher Grund dafür, dass Agenten bezahlbar bleiben: Anweisungen, Tool-Definitionen und Verlauf werden bei jedem Schritt erneut gesendet und meist zum Cache-Preis abgerechnet. Caches gehören zu einem bestimmten Modell bei einem bestimmten Anbieter. Deshalb verwendet OpenRouter [Sticky Routing](https://openrouter.ai/docs/guides/best-practices/prompt-caching), „um nach einer Anfrage mit Cache die folgenden Anfragen an denselben Anbieter-Endpunkt zu leiten“. Beim Wechsel wird der nächste Schritt zum vollen Preis abgerechnet. Beim [Listenpreis von Claude Sonnet 5.5](https://platform.claude.com/docs/en/about-claude/pricing) von 2,00 $ pro einer Million Input-Tokens beziehungsweise 0,20 $ aus dem Cache kostet ein Agentenverlauf mit 50.000 Tokens etwa 0,01 $ aus dem Cache und etwa 0,10 $ ohne Cache. Das ist pro Schritt zehnmal so viel, bis der eigene Cache des Backups warmgelaufen ist.

**Sie bezahlen das Modell, das geantwortet hat – mit dessen eigenen Tokens.** OpenRouter berechnet das Modell, das letztlich geantwortet hat. Ein Fallback auf ein teureres Modell kostet also mehr. Auch ein günstigeres Backup kann teurer werden, wenn es für den Abschluss zusätzliche Schritte benötigt. Token-Anzahlen lassen sich außerdem nicht direkt vergleichen: Auf der [Preisseite von Anthropic](https://platform.claude.com/docs/en/about-claude/pricing) steht, dass Claude-4.7-Modelle und spätere Modelle einen neuen Tokenizer verwenden, der für denselben Text ungefähr 30 % mehr Tokens erzeugt.

**Auch Wiederholungen werden abgerechnet.** Eine Anfrage, die mitten in einem Stream fehlschlägt, hat oft bereits kostenpflichtige Tokens erzeugt. Jeder erneute Versuch sendet außerdem den gesamten Kontext noch einmal. Wie sich das summiert, haben wir in [Betriebskosten von KI-Agenten](/de/blog/ai-agent-running-costs) beschrieben: Fehlgeschlagene Läufe und Endlosschleifen können als Ausreißer die Durchschnittskosten übersteigen.

Nichts davon spricht gegen Backups. Es spricht dafür, sie als Backups zu behandeln und alltägliche Fehler durch erneute Versuche und Host-Failover abzufangen, damit der teure Modellwechsel nur bei echten Ausfällen erfolgt.

## Testen Sie Ihren Fallback, bevor Sie ihn benötigen

Die meisten Fallback-Ketten werden zum ersten Mal während eines Incidents eingesetzt – der denkbar schlechteste Zeitpunkt, um festzustellen, dass das Backup Ihre Tools nicht aufrufen kann. Eine kurze Übung einmal pro Quartal und nach jeder Modelländerung deckt die meisten Probleme auf:

1. **Erzwingen Sie den Fehler.** Verweisen Sie das primäre Modell auf eine nicht existente Modell-ID oder verwenden Sie den Testschalter Ihres Routers. LiteLLM bietet in seinem SDK `mock_testing_fallbacks=True` an und empfiehlt für seinen Proxy, in einer Nicht-Produktionsumgebung einen echten Anbieterfehler auszulösen
2. **Führen Sie echte Aufgaben aus, keinen Hello-World-Prompt.** Nehmen Sie drei oder vier tatsächliche Aufgaben Ihres Agenten, darunter einen langen, toolintensiven Lauf, und lassen Sie sie vollständig mit dem Backup abschließen
3. **Vergleichen Sie die Ergebnisse.** Hat der Agent dieselben Tools aufgerufen, an derselben Stelle aufgehört und Ihre Formatierungsregeln befolgt? Lesen Sie die Transkripte, nicht nur die endgültige Antwort
4. **Bestätigen Sie, welches Modell geantwortet hat.** Prüfen Sie das Feld `model`, `modelAttempts` oder den Header `cf-aig-step` der Antwort. Eine Übung, bei der unbemerkt das primäre Modell geantwortet hat, beweist nichts
5. **Richten Sie Benachrichtigungen für Fallbacks ein.** Ein Backup, das täglich einspringt, ist kein Backup mehr. Es ist Ihr tatsächliches Modell – bei diesem Volumen ungetestet. Sie sollten davon wissen
6. **Tragen Sie Einstellungsdaten in Ihren Kalender ein.** Prüfen Sie die Abkündigungsseiten für das primäre Modell und das Backup und wechseln Sie deutlich vor einem der beiden Termine zum Ersatzmodell

Für geplante Aufgaben sollten Sie außerdem einen Plan für Läufe erstellen, die trotzdem fehlschlagen. Unser Leitfaden zum [Planen wiederkehrender Aufgaben für KI-Agenten](/de/blog/schedule-recurring-ai-agent-tasks) beschreibt, wie ein guter Fehler aussieht: ein Teilergebnis, eine verständliche Meldung und eine Aufgabe, die sich selbst beendet, statt endlos neue Versuche zu starten.

## So geht Crevio mit Modellausfällen um

[Crevio](https://crevio.co/) ist ein KI-Business-Builder: Sie beschreiben, was Sie verkaufen möchten, und sein Agent erstellt, startet und betreibt die nötigen Prozesse. Crevio wählt und betreibt die Modelle hinter diesem Agenten, sodass Sie keine Anbieter-Accounts, API-Schlüssel oder Modellversionen verwalten müssen. Hier erfahren Sie verständlich, was passiert, wenn ein Modell Probleme macht – einschließlich dessen, was Crevio nicht tut.

**Was Crevio heute tut:**

- **Dasselbe Modell automatisch erneut versuchen.** Wenn ein Modellaufruf wegen Überlastung, eines Rate Limits, eines Serverfehlers, eines Timeouts oder einer mitten im Stream abgebrochenen Antwort fehlschlägt, versucht der Agent es bis zu dreimal erneut und wartet dabei jedes Mal etwas länger (bis zu etwa 2, 4 und 8 Sekunden). Fehler, die sich durch erneute Versuche nicht beheben lassen, etwa eine fehlerhafte Anfrage, werden nicht wiederholt
- **Einen gerade ausgefallenen Host meiden.** Bei Modellen, die von mehreren Hosts bereitgestellt werden können, überspringt ein erneuter Versuch nach einem Host-Fehler den Host, der den Fehler gerade verursacht hat
- **Lange Unterhaltungen zusammenfassen.** Wenn eine Unterhaltung größer wird, als das Modell lesen kann, fasst der Agent den älteren Verlauf zusammen und versucht es noch einmal, statt abzubrechen
- **Die Modellliste bei jeder Veröffentlichung prüfen.** Bei jedem Update bestätigt Crevio, dass jedes vom Agenten benötigte Modell weiterhin angeboten wird. Fehlt eines, wird die Veröffentlichung als fehlgeschlagen markiert

![Crevio-Formular zum Erstellen einer neuen Aufgabe für eine tägliche Morning sales summary mit der Anweisung, anzugeben, welche Datenquelle nicht erreichbar war; eingestellt auf tägliche Wiederholung und Benachrichtigungen per In-App-Mitteilung und E-Mail](https://crevio.co/vite/assets/crevio-task-failure-notifications-cq6okyoe.png)

**Was passiert, wenn der Fehler bestehen bleibt:** Ein fehlgeschlagener Lauf einer geplanten Aufgabe wird über die in **Notify via** festgelegten Kanäle gemeldet – einschließlich dessen, was erledigt wurde und was schiefgelaufen ist. Eine wiederkehrende Aufgabe wird standardmäßig nach drei aufeinanderfolgenden fehlgeschlagenen Läufen automatisch deaktiviert und informiert Sie darüber, statt jeden Morgen unbemerkt fehlzuschlagen. In einem Live-Chat wird eine Antwort, bei der alle erneuten Versuche ausgeschöpft sind, einfach beendet. Sie senden die Nachricht dann erneut.

**Was Crevio noch nicht tut:** Der Crevio-Agent wechselt bei einem Ausfall des Hauptmodells nicht automatisch mitten in einer Aufgabe zu einem anderen Modell. Derzeit besteht der Schutz aus erneuten Versuchen und Host-Failover beim selben Modell. Sie können das Modell des Agenten außerdem nicht selbst auswählen und keinen eigenen Anbieter-API-Schlüssel hinterlegen. Wenn Sie eine fein abgestimmte Fallback-Kette über mehrere Anbieter benötigen, erhalten Sie diese Kontrolle mit einem Routing-Tool aus der Tabelle oben in Ihrem eigenen Stack.

[Crevio](https://crevio.co/) kann kostenlos gestartet werden. Der Starter-Tarif umfasst 20 KI-Credits pro Monat.

## FAQ

### Benötige ich ein Backup-Modell, wenn ich bereits ein KI-Gateway nutze?

Das Gateway ist der Ort, an dem Sie das Backup konfigurieren – es ist nicht selbst das Backup. Einige Gateways führen eigenständig erneute Versuche durch oder wechseln zwischen Hosts für dasselbe Modell. Ein Modell-Fallback findet jedoch nur statt, wenn Sie ein Backup angeben. Das Gateway ist außerdem eine zusätzliche Abhängigkeit. Prüfen Sie daher, wie es sich bei früheren Incidents verhalten hat.

### Sollte ein Backup-Modell für einen KI-Agenten von einem anderen Anbieter stammen?

Bei Ausfällen: ja. Ein Backup desselben Anbieters fällt häufig im selben Incident ebenfalls aus. Bei Rate Limits kann ein zweites Modell desselben Anbieters ausreichen, da Limits normalerweise pro Modell festgelegt werden. Der Nachteil ist die Kompatibilität: Je stärker sich das Backup vom primären Modell unterscheidet, desto gründlicher müssen Sie Prompts, Tool-Aufrufe und Parameter testen.

### Wie oft sollte ich meinen LLM-Fallback testen?

Führen Sie nach jeder Änderung am primären Modell, am Backup oder an den Anweisungen und Tools Ihres Agenten eine Übung durch, ansonsten mindestens einmal pro Quartal. Prüfen Sie dabei auch die Einstellungsdaten beider Modelle: Ein Backup, das eingestellt wurde, fällt genau dann aus, wenn Sie es benötigen.

## Ein Backup, das Sie nie ausgeführt haben, ist reine Spekulation

Ausfälle, Rate Limits und Einstellungen gehören inzwischen zum Alltag. Ein gutes Backup-Modell für KI-Agenten macht daraus einen etwas verspäteten statt eines ausgefallenen Morgenberichts. Der Nutzen liegt jedoch in der richtigen Reihenfolge: erst erneut versuchen, dann einen anderen Host verwenden, dann auf ein anderes Modell wechseln – und das nur mit einem Backup, das Sie bereits bei echter Arbeit beobachtet haben. Wenn Sie es nicht getestet haben, besitzen Sie keinen Fallback. Sie haben nur eine zweite mögliche Fehlerquelle.

## Weitere Blogbeiträge

- [Betriebskosten von KI-Agenten: Was ein Agent pro Monat wirklich kostet](/de/blog/ai-agent-running-costs)
- [So planen Sie wiederkehrende Aufgaben für KI-Agenten, die ohne Sie laufen](/de/blog/schedule-recurring-ai-agent-tasks)
- [KI-Agenten mit Human in the Loop: Was Sie freigeben und was automatisch laufen darf](/de/blog/human-in-the-loop-ai-agents)
- [KI-Agenten für Unternehmen: Was Sie zuerst einsetzen sollten – Abteilung für Abteilung](/de/blog/ai-agents-for-business)