So überlebt deine KI-App, wenn ein Modell plötzlich verschwindet

Jeder Entwickler, der auf KI aufbaut, lernt irgendwann dieselbe Lektion auf die harte Tour: Das Modell, von dem du abhängst, ist nicht garantiert da. Es kann bei Lastspitzen rate-limitiert werden, eine Verweigerung zurückgeben, in einen Überlastungsfehler laufen oder — wie es Claude Fable 5 im Juni 2026 passierte — aus Gründen, die nichts mit deinem Code zu tun haben, komplett abgeschaltet werden. Die Apps, die solche Momente überstehen, sind nicht die mit dem besten Prompt. Es sind die, die mit dem Wegfall des Modells gerechnet haben.

Dieser Leitfaden führt durch einen praktischen, mehrschichtigen Ansatz für Resilienz, der funktioniert, egal ob du einen Anbieter direkt aufrufst oder über ein Gateway routest.

Schritt 1: Kodiere nie ein einzelnes Modell fest

Die häufigste Schwachstelle ist ein Modellname, der direkt in einen Request eingebacken ist. In dem Moment, in dem dieser String nicht mehr funktioniert, schlägt jeder Aufruf fehl. Definiere deine Modelle stattdessen als Konfiguration — eine kleine Prioritätenliste, keine Konstante:

MODEL_CHAIN = [
    "claude-opus-4-8",      # primary
    "claude-sonnet-4-6",    # same provider, cheaper/faster
    "gpt-5.5",              # different provider entirely
]

Diese eine Änderung bedeutet, dass ein Anbieterwechsel während eines Vorfalls eine Konfigurationsänderung ist, kein Code-Deploy. Beachte, dass der dritte Eintrag ein anderer Anbieter ist. Fallbacks innerhalb desselben Anbieters schützen dich davor, dass ein einzelnes Modell ausfällt; anbieterübergreifende Fallbacks schützen dich davor, dass der gesamte Anbieter ausfällt — oder per Anordnung offline genommen wird.

Schritt 2: Nutze eine Fallback-Kette, keinen einzelnen Versuch

Das Muster ist einfach: Probiere jedes Modell der Reihe nach, wechsle bei einem Fehler zum nächsten und gib nur dann einen Fehler aus, wenn die gesamte Kette erschöpft ist.

def call_with_fallback(messages):
    last_error = None
    for model in MODEL_CHAIN:
        try:
            return client.complete(model=model, messages=messages)
        except (RateLimitError, OverloadError, RefusalError) as e:
            last_error = e
            continue  # try the next model
    raise AllModelsFailedError(last_error)

Worauf du zurückfällst, ist entscheidend. Dasselbe Modell bei einem transienten overloaded-Fehler (HTTP 529) nach einem kurzen Backoff erneut zu versuchen, ergibt Sinn. Aber ein Authentifizierungsfehler oder ein fehlerhafter Request schlägt bei jedem Modell identisch fehl — solche sollten sofort auftauchen, statt deine ganze Kette zu verbrennen.

Schritt 3: Stütze dich auf die Plattform, wenn sie Fallbacks nativ anbietet

Du musst das nicht immer von Hand bauen. Mehrere Plattformen erledigen es nun serverseitig:

• Anthropics API hat einen Beta-Parameter fallbacks ergänzt, der einen abgelehnten Request in einem einzigen Roundtrip auf einem alternativen Modell erneut versucht — Fable 5 war beispielsweise so konfiguriert, dass es auf Opus 4.8 zurückfiel, wenn seine Klassifizierer einen Request ablehnten. Die Abrechnung folgt dem Modell, das die Antwort tatsächlich geliefert hat.
• OpenRouter lässt dich ein models-Array in Prioritätsreihenfolge übergeben; es schaltet automatisch um bei Kontextlängen-Fehlern, Moderations-Flags, Rate-Limits und Ausfällen und berechnet dir den Tarif des Modells, das geantwortet hat.
• LiteLLM liefert einen Router mit eingebauten Retries, Fallbacks und Load-Balancing über Deployments und Anbieter hinweg, den du für maximale Kontrolle selbst hostest.

Ein Gateway wie OpenRouter oder LiteLLM gibt dir einen einheitlichen Endpunkt über viele Anbieter hinweg, sodass ein anbieterübergreifender Fallback nur ein weiterer Eintrag in einer Liste ist statt ein zweites zu integrierendes SDK.

Schritt 4: Füge einen Circuit Breaker hinzu, um schnell zu scheitern

Wenn ein Modell offensichtlich ausgefallen ist, willst du nicht, dass jeder Request auf dessen Timeout wartet, bevor er durchfällt. Ein Circuit Breaker verfolgt jüngste Fehler und überspringt, sobald eine Schwelle überschritten ist, das defekte Modell für eine Abkühlphase vollständig. Produktionsteams im Jahr 2026 landen üblicherweise bei etwa fünf aufeinanderfolgenden Fehlern, um den Breaker auszulösen, und einer Abkühlphase von rund 60 Sekunden, bevor sie die Wiederherstellung testen. Solange der Breaker offen ist, geht der Traffic direkt zum nächsten Modell in der Kette — keine vergeudete Latenz.

Schritt 5: Lege fest, was "degradiert" für dein Produkt bedeutet

Der Rückfall auf ein günstigeres Modell ist nicht kostenlos — die Qualität sinkt, und deine Prompts können sich anders verhalten. Plane dafür:

• Teste deine Prompts gegen jedes Modell in der Kette. Ein für ein Modell abgestimmter Prompt kann auf seinem Fallback merklich schlechtere Ausgaben erzeugen.
• Sag dem Nutzer, wenn du degradiert hast, falls es relevant ist (z. B. "läuft im Schnellmodus"), statt still Ergebnisse niedrigerer Qualität auszuliefern.
• Protokolliere, welches Modell jeden Request tatsächlich bedient hat, damit du nach einem Vorfall sehen kannst, wie viel Traffic die Fallbacks aufgefangen haben.

Das Fazit

Resilienz ist kein Feature, das du nach dem Launch dranschraubst — es ist ein kleines Maß an Struktur, das du früh hinzufügst: Konfiguration statt Konstanten, eine Prioritätenkette statt eines einzelnen Aufrufs, ein Circuit Breaker, um schnell zu scheitern, und getestete Prompts auf jeder Ebene. Die Teams, deren Apps während der Fable-5-Abschaltung im Juni online blieben, hatten kein Glück. Sie hatten schlicht bereits die Frage beantwortet, die sich jeder KI-Entwickler am ersten Tag stellen sollte: Was passiert, wenn dieses Modell morgen nicht mehr da ist?