LLM-Fallback einrichten: So bleibt deine KI-App online, wenn OpenAI oder Claude ausfällt

Kurz erklärt

Kurz erklärt: Ein LLM-Fallback schaltet automatisch auf ein zweites Modell eines anderen Anbieters um, sobald das Hauptmodell einen Serverfehler (5xx), ein Rate-Limit (429) oder einen Timeout liefert. Entscheidend sind drei Dinge: ein Ausweichmodell mit ähnlicher Qualität, ein eigener Zugang direkt beim zweiten Anbieter und ein Test, der den Umschaltweg regelmäßig prüft.

Welche Fehler einen Fallback auslösen sollten

Nicht jeder Fehler ist ein Grund umzuschalten. Ein 400er (z. B. zu langer Prompt) scheitert beim Ausweichmodell genauso. Umschalten lohnt sich nur bei Fehlern, die beim Anbieter liegen.

5xx und Verbindungsabbrüche

Der Anbieter ist gestört. Hier hilft nur ein anderer Anbieter. In den letzten [EIGENE ZAHL] Tagen hat BreakerBay bei [ANBIETER] [EIGENE ZAHL] Störungen der API-Komponenten erfasst (SLA-Historie).

429 – Rate Limits

Du hast dein Kontingent erreicht. Ein kurzer Retry mit Wartezeit reicht oft; bleibt der Fehler, wechselst du das Modell.

Timeouts

Die Antwort kommt zu spät für deine Anwendung. Lege den Timeout nach deinem Nutzererlebnis fest, nicht nach dem Standardwert der SDK. In der Praxis haben sich 8 bis 12 Sekunden für interaktive User-Anfragen bewährt. Dauert eine Antwort länger, brechen Nutzer meist ohnehin ab.

Was ein Fallback nicht abfängt

Zwei Ausfallarten sieht kein automatischer Fallback: Das Modell antwortet formal erfolgreich, aber schlechter – oder es wird für alle gesperrt. Das zweite ist 2026 tatsächlich passiert: Anthropic hat zwei Modelle wegen US-Exportkontrollen knapp drei Wochen lang abgeschaltet. Dagegen hilft nur eine zweite Modellfamilie, die du vorab mit deinen eigenen Prompts getestet hast.

Das richtige Ausweichmodell wählen

Das Ausweichmodell sollte drei Bedingungen erfüllen: anderer Anbieter, vergleichbares Kontextfenster, akzeptabler Preis. In der Modellübersicht siehst du für jedes Modell Preis pro 1 Mio. Tokens und Kontextfenster mit Stand und Quelle.

[EIGENES BEISPIEL: welche Paarung du selbst nutzt und warum]

Direkt zum Anbieter oder über einen Router?

Ein Router wie OpenRouter ist bequem, ist aber selbst ein Ausfallpunkt. Mein Rat: Hauptmodell und Ausweichmodell direkt beim Anbieter anbinden und den Router höchstens als letzte Stufe nutzen. Genau diese Variante ist im Generator voreingestellt.

Code: Fallback in 60 Sekunden

Wähle im Fallback-Generator dein Haupt- und Ausweichmodell, die Auslöser (Ausfall, Timeout, 429) und dein Framework. Du bekommst fertigen Code für TypeScript, Python, Vercel AI SDK und LiteLLM (Python, YAML, JSON).

// Generated by BreakerBay — fallback chain · https://breakerbay.io/fallback
// Fallback chain (OPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY)
import OpenAI from "openai";

const TIERS = [
  {
    "provider": "OpenAI",
    "model": "gpt-6.1-terra-pro",
    "baseURL": "https://api.openai.com/v1",
    "apiKeyEnv": "OPENAI_API_KEY"
  },
  {
    "provider": "Anthropic",
    "model": "claude-haiku-5-5",
    "baseURL": "https://api.anthropic.com/v1/",
    "apiKeyEnv": "ANTHROPIC_API_KEY"
  },
  {
    "provider": "OpenRouter",
    "model": "openai/gpt-6.1-terra-pro",
    "baseURL": "https://openrouter.ai/api/v1",
    "apiKeyEnv": "OPENROUTER_API_KEY"
  }
];
const TIMEOUT_MS = 15000;
const RETRIES_PER_MODEL = 1;

const clients = TIERS.map((tier) => new OpenAI({ baseURL: tier.baseURL, apiKey: process.env[tier.apiKeyEnv] }));

function shouldFallback(err: any): boolean {
  const status = err?.status ?? err?.response?.status;
  if (status === 429) return true; // rate limited
  if (status >= 500 || err?.code === "ECONNRESET") return true; // provider outage
  if (err?.name === "AbortError" || err?.name === "APIConnectionTimeoutError") return true; // latency timeout
  return false;
}

export async function complete(messages: OpenAI.Chat.ChatCompletionMessageParam[]) {
  let lastErr: unknown;
  for (const [i, tier] of TIERS.entries()) {
    for (let attempt = 0; attempt <= RETRIES_PER_MODEL; attempt++) {
      try {
        const client = clients[i];
        if (!client) throw new Error("Missing client for fallback tier");
        return await client.chat.completions.create({ model: tier.model, messages }, { timeout: TIMEOUT_MS });
      } catch (err) {
        lastErr = err;
        if (!shouldFallback(err)) throw err;
      }
    }
  }
  throw lastErr;
}

Fallback testen, bevor es ernst wird

Setze in der Testumgebung einen ungültigen API-Key für das Hauptmodell – der Fallback muss greifen.

Simuliere einen Timeout mit einem sehr niedrigen Wert.

Vergleiche die Antworten beider Modelle mit [EIGENE ZAHL] typischen Prompts aus deiner Anwendung.

Lass dich über Alerts in Slack oder per E-Mail benachrichtigen, wenn ein Anbieter gestört ist.

Häufige Fragen

Kostet ein Fallback zusätzlich?

Nur, wenn er greift. Dann zahlst du die Preise des Ausweichmodells; fehlgeschlagene Anfragen beim Hauptanbieter werden in der Regel nicht berechnet. Prüfe den Preisunterschied im Kostenrechner.

Wie viele Ausweichmodelle brauche ich?

Für die meisten Anwendungen reicht eines bei einem anderen Anbieter. Eine dritte Stufe lohnt sich bei Anwendungen, die ohne KI gar nicht funktionieren.

Sollte ich bei 429 sofort umschalten?

Nein. Erst ein bis zwei Wiederholungen mit Wartezeit, dann umschalten.

Funktioniert das auch mit Streaming?

Ja, aber ein Abbruch mitten im Stream erfordert, dass du die Anfrage beim Ausweichmodell neu startest. Bricht ein Token-Stream ab, empfiehlt es sich, die unvollständige Ausgabe clientseitig zu verwerfen und die Anfrage nahtlos an das Ausweichmodell zu übergeben, anstatt Bruchstücke anzuzeigen.

Brauche ich LiteLLM dafür?

Nein. Der Generator erzeugt auch reinen TypeScript- oder Python-Code ohne zusätzliches Gateway.