Reliability and Routing13. Oktober 2026Flatkey Team

OpenRouter down? Wie Sie ohne Codeänderungen auf einen Ausfall umschalten

Prüfen Sie, ob OpenRouter ausgefallen ist, unterscheiden Sie Provider-Fehler von Plattformstörungen und schalten Sie mit base_url, Retries, Provider-Fallback und Model-Fallback um.

Wenn Menschen nach OpenRouter Down suchen, brauchen sie in der Regel schnell zwei Antworten: Ist OpenRouter tatsächlich ausgefallen, und wie halte ich Anfragen am Laufen, ohne meine App neu zu schreiben?

Die sicherste Antwort ist, nicht panisch im Code auf andere Modelle umzuschalten. Bestätigen Sie zuerst, ob das Problem OpenRouter-weit, anbieterspezifisch, kontospezifisch oder durch Ihre eigene Retry-Warteschlange verursacht wird. Verlegen Sie dann Failover in die Konfiguration: Statusprüfungen, Retry-Budgets, Provider-Fallback, Modell-Fallback und eine austauschbare, OpenAI-kompatible base_url.

Prüfdatum: 13. Oktober 2026. Betrachten Sie diesen Artikel nicht als Beweis dafür, dass OpenRouter gerade jetzt ausgefallen ist. Prüfen Sie die OpenRouter-Statusseite und Ihre eigenen Logs, bevor Sie einen Incident auslösen.

Die Kurzantwort

Wenn OpenRouter ausgefallen ist oder wenn eine OpenRouter-Route fehlschlägt, verwenden Sie diese Reihenfolge:

Prüfen Sie https://status.openrouter.ai/ und Ihre Fehlerlogs.
Trennen Sie OpenRouter-Plattformfehler von Upstream-Modell-/Provider-Fehlern.
Beachten Sie Retry-After bei 429, 503 und 402-Antworten mit In-Flight-Budget.
Behalten Sie provider.allow_fallbacks aktiviert, sofern keine Compliance-Regel etwas anderes verlangt.
Fügen Sie Modell-Fallbacks über die Anfragekonfiguration hinzu, sofern der Vertrag zur Antwortqualität dies zulässt.
Platzieren Sie Ihr API-Gateway oder Ihren Backup-Endpunkt hinter einer Umgebungsvariable, damit Sie base_url ohne Änderung des Anwendungscodes umschalten können.

Dieser letzte Punkt ist der eigentliche "ohne Codeänderungen"-Schritt. Ihre Anwendung sollte den Endpunkt aus der Konfiguration lesen:

OPENAI_BASE_URL=https://openrouter.ai/api/v1
OPENAI_API_KEY=...

Während eines Incidents wird Ihre operative Änderung zu:

OPENAI_BASE_URL=https://router.flatkey.ai/v1
OPENAI_API_KEY=...

Ihr SDK-Code bleibt derselbe.

Ist OpenRouter ausgefallen?

Schließen Sie OpenRouter Down nicht aus einer einzigen fehlgeschlagenen Anfrage. Eine fehlgeschlagene Anfrage kann bedeuten:

Symptom	Wahrscheinlicher Umfang	Was zuerst prüfen
Incident auf der Statusseite	OpenRouter-Plattform	Statusseite, Incident-Zeitleiste, öffentliche Updates
`502 Bad Gateway`	Das gewählte Modell/der Provider könnte ausgefallen sein	Modell, Provider-Metadaten, Fallback-Berechtigung
`503 Service Unavailable`	Kein Provider erfüllt Ihre Routing-Regeln	Provider-Einschränkungen, `only`, ZDR, Parameteranforderungen
`429 Too Many Requests`	Rate-Limit oder Provider-Kapazität	`Retry-After`, Queue-Parallelität, Provider-Fallback
`402 Payment Required`	Credits oder In-Flight-Ausgabenbudget	`Retry-After`, Kontostand, Schlüssellimits
`403 Forbidden`	Budget, Berechtigungen, Moderation, Guardrail	`error.metadata`, Workspace-/Schlüsselrichtlinie
Streaming startet, dann erscheint ein Fehlerereignis	Provider ist nach HTTP `200` fehlgeschlagen	SSE-Body prüfen, nicht nur den anfänglichen HTTP-Status

In den Fehlerdokumenten von OpenRouter steht, dass 502 bedeuten kann, dass das gewählte Modell ausgefallen ist oder eine ungültige Antwort zurückgegeben hat, während 503 bedeuten kann, dass kein verfügbarer Modell-Provider die Routing-Anforderungen erfüllt. Dieselben Dokus sagen, dass OpenRouter bei 429, 503 und einigen 402-Antworten mit In-Flight-Budget Retry-After zurückgeben kann. Quelle: OpenRouter errors and debugging.

OpenRouter hatte in der Vergangenheit bereits öffentliche Ausfälle. Der Postmortem-Bericht vom 17. und 19. Februar 2026 beschreibt API-Ausfälle durch eine Caching-Abhängigkeit eines Drittanbieters und weist darauf hin, dass einige Nutzer während des Incidents verwirrende 401-Fehler sahen. Dieser historische Beitrag ist nützlicher Kontext, aber kein Beweis für einen aktuellen Ausfall. Quelle: OpenRouter-Ausfall-Postmortem.

Die ersten fünf Minuten: Triage bei OpenRouter-Ausfall

Verwenden Sie diese Checkliste, bevor Sie Traffic umleiten.

Minute	Aktion	Entscheidung
0-1	Prüfen Sie die OpenRouter-Statusseite und Ihre Alarmzeitleiste.	Wenn die Statusseite einen Incident bestätigt, gehen Sie zur Failover-Bereitschaft über.
1-2	Gruppieren Sie Fehler nach Statuscode, Modell, Provider, Route und SDK.	Wenn nur ein Modell/Provider ausfällt, vermeiden Sie Annahmen über die gesamte Plattform.
2-3	Prüfen Sie `Retry-After`, Retry-Anzahl und Queue-Parallelität.	Stoppen Sie Retry-Stürme, bevor Sie weiteren Fallback-Traffic hinzufügen.
3-4	Vergleichen Sie bezahlte, kostenlose, Batch- und Agent-Workloads.	Bewahren Sie interaktiven Traffic vor Hintergrundjobs.
4-5	Wählen Sie die kleinste Failover-Maßnahme, die die nutzerseitige Arbeit wiederherstellt.	Bevorzugen Sie Provider-Fallback vor Cross-Model-Fallback; bevorzugen Sie den Konfigurationswechsel vor dem Code-Deployment.

Der wichtigste Fehler während eines OpenRouter Down-Incidents ist, jeden Worker sofort erneut versuchen zu lassen. Ein Retry-Sturm kann aus einem einzigen Provider-Fehler in Ihrer eigenen App ein plattformweites Warteschlangenproblem machen.

Failover ohne Codeänderungen

Das Muster ohne Codeänderung ist einfach: Behalten Sie die SDK-Nutzung stabil und machen Sie die Route konfigurierbar.

import OpenAI from "openai";

export const ai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: process.env.OPENAI_BASE_URL,
});

Dann halten Sie die Auswahl des Endpunkts in der Umgebung, in der Bereitstellungskonfiguration, in Feature-Flags oder in Ihrem Secret Manager fest:

ai_gateway:
  primary:
    base_url: https://openrouter.ai/api/v1
    key_env: OPENROUTER_API_KEY
  backup:
    base_url: https://router.flatkey.ai/v1
    key_env: FLATKEY_API_KEY
  switch_policy:
    trigger: confirmed_platform_incident_or_error_budget_exhausted
    owner: on_call_engineer
    rollback: after_30_minutes_below_error_threshold

Das funktioniert, weil der Schnellstart von OpenRouter sagt, dass seine API über das OpenAI SDK verwendet werden kann, indem man das SDK auf OpenRouter ausrichtet. Genau diese Integrationsform macht ein Backup-OpenAI-kompatibles Gateway praktisch. Quelle: OpenRouter quickstart.

Verwenden Sie Provider-Fallback, bevor Sie Modelle ändern

Wenn OpenRouter erreichbar ist, aber ein Provider Probleme hat, ist Provider-Fallback die risikoärmste Maßnahme. Sie behalten denselben Modellvertrag bei und lassen das Routing einen anderen zulässigen Provider versuchen.

Die Routing-Dokumentation von OpenRouter sagt, dass Anfragen standardmäßig über die besten Provider hinweg load-balanced werden, um die Verfügbarkeit zu maximieren, und dass das provider-Objekt allow_fallbacks enthält, standardmäßig auf true. Die Doku warnt außerdem davor, dass das Setzen von sort oder order das Load-Balancing-Verhalten ändert und harte Provider-Filter den Routing-Spielraum verringern können. Quelle: OpenRouter provider routing.

Beginnen Sie mit diesem:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [{ "role": "user", "content": "..." }],
  "provider": {
    "allow_fallbacks": true
  }
}

Seien Sie während eines Vorfalls dabei vorsichtig:

{
  "provider": {
    "only": ["one-provider"],
    "allow_fallbacks": false
  }
}

Striktes Routing kann für Compliance, Datenaufbewahrung, Region oder Preispolitik korrekt sein. Aber striktes Routing ist keine Zuverlässigkeitseinstellung. Wenn Sie striktes Routing für sensible Workloads benötigen, erstellen Sie einen separaten nicht sensiblen Pfad, der freier auf einen Ausfall umschalten kann.

Modell-Fallback nur hinzufügen, wenn die Ausgaben austauschbar sind

Modell-Fallback ist stärker als Provider-Fallback. Er kann die App am Leben halten, wenn das Primärmodell ausgefallen ist, durch Rate-Limits gebremst wird oder blockiert ist, aber er kann auch Stil der Ausgabe, Latenz, Kosten, Kontextlänge, Tool-Verhalten und Evaluationsergebnisse verändern.

Die Modell-Fallback-Dokumentation von OpenRouter sagt, dass der Parameter models es Ihnen erlaubt, Modell-IDs in Prioritätsreihenfolge anzugeben. Wenn das erste Modell einen Fehler zurückgibt, versucht OpenRouter das nächste Modell. Die Doku nennt Rate-Limiting und Ausfallzeiten unter den Fehlern, die Fallback auslösen können. Quelle: OpenRouter model fallbacks.

Verwenden Sie Modell-Fallback für Aufgaben mit einem lockeren Äquivalenzvertrag:

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-4o",
    "google/gemini-2.5-pro"
  ],
  "messages": [{ "role": "user", "content": "Fassen Sie diesen Support-Thread zusammen." }]
}

Vermeiden Sie stilles Modell-Fallback bei Aufgaben, bei denen das exakte Modell Teil der Produktzusage ist:

Workload	Haltung zu Modell-Fallback
Interne Zusammenfassung	Mit Bewertung und Logging meist sicher
Planung eines Coding-Agents	Möglich, aber Tool-Call-Verhalten und Befolgung von Anweisungen testen
Strukturierte Extraktion	Nur wenn Schemas und Validierung bestehen
Für Kunden sichtbare kreative Texte	Möglich, aber mit Stilunterschieden rechnen
Regulierte oder vertragliche Ausgabe	Modelle nicht stillschweigend ändern
Benchmarking oder Evals	Kein Fallback, außer der Fallback ist das Testobjekt

Eine praktische Vorfallrichtlinie

Diese Richtlinie ist absichtlich unspektakulär. Sie hält die Reaktion auf OpenRouter Down betriebsfähig statt dramatisch.

openrouter_down_policy:
  status_checks:
    - openrouter_status_page
    - synthetic_chat_completion
    - provider_error_rate_by_model
    - queue_retry_rate

  retry_budget:
    max_attempts: 3
    honor_retry_after: true
    jitter: true
    stop_retrying_on:
      - invalid_credentials
      - spent_budget
      - moderation_block
      - bad_request

  provider_fallback:
    default_allow_fallbacks: true
    loosen_provider_constraints_for:
      - non_sensitive_batch_jobs
      - internal_tools
      - support_summaries

  model_fallback:
    require_contract: equivalent_quality_or_validated_schema
    log_selected_model: true
    disallow_for:
      - evals
      - compliance_outputs
      - customer_promises_about_exact_model

  base_url_failover:
    primary: OPENAI_BASE_URL
    backup_env: OPENAI_BACKUP_BASE_URL
    switch_owner: on_call_engineer
    switch_requires:
      - confirmed_status_incident_or_internal_error_budget
      - rollback_plan
      - public_request_log_enabled

Die wichtigsten Felder, die protokolliert werden sollten, sind:

Feld	Warum es wichtig ist
`base_url`	Beweist, welches Gateway die Anfrage verarbeitet hat
`requested_model`	Zeigt das vom Aufrufer beabsichtigte Modell
`served_model`	Zeigt das tatsächlich nach dem Fallback verwendete Modell
`provider`	Trennt Plattformprobleme von Providerproblemen
`status_code`	Steuert Retry-/Failover-Entscheidungen
`retry_after`	Verhindert Retry-Stürme
`attempt`	Zeigt, ob Retries den Traffic verstärken
`fallback_reason`	Ermöglicht die Auswertung von Vorfällen
`cost`	Bestätigt, dass der Fallback keinen überraschenden Kostensprung verursacht hat
`request_id`	Ermöglicht Support und Engineering, eine Anfrage nachzuverfolgen

Wo Flatkey passt

Flatkey ist nützlich, wenn Sie das OpenRouter Down-Playbook außerhalb des Anwendungscodes leben lassen möchten. Die Positionierung des Projekts Flatkey ist ein einheitliches LLM-API-Gateway: ein Schlüssel, ein Guthaben und ein OpenAI-kompatibler Endpunkt für das Routing über offizielle Text-, Bild- und Videomodelle hinweg. In diesem Vorfallmuster liegt der praktische Nutzen im Betrieb:

Behalten Sie für Ihre App eine OpenAI-kompatible Client-Struktur bei.
Leiten Sie eine Workload über eine Backup-base_url, ohne die Anwendungslogik zu ändern.
Zentralisieren Sie Modell-Allowlists, Sub-Keys, Anforderungsprotokolle, Budgetkontrollen und Fallback-Richtlinien.
Vergleichen Sie das Verhalten des Gateways anhand von Request-Nachweisen statt anhand von Anekdoten.

Verschieben Sie nicht jede Workload während eines kleinen Vorfalls. Verschieben Sie zuerst eine repräsentative Workload, beobachten Sie Fehlerrate, Latenz, ausgewähltes Modell, Fallback-Grund und Kosten und entscheiden Sie dann, ob Sie den Wechsel ausweiten.

Nützliche weiterführende Lektüre:

OpenRouter Down FAQ

Ist OpenRouter gerade ausgefallen?

Prüfen Sie zuerst die OpenRouter-Statusseite. Dieser Artikel erklärt, wie Sie reagieren, wenn Suchanfragen nach OpenRouter Down auf einen echten Vorfall oder einen lokalen Provider-Ausfall verweisen; er behauptet nicht, dass OpenRouter gerade ausgefallen ist.

Was sollte ich zuerst tun, wenn OpenRouter ausgefallen ist?

Pausieren Sie aggressive Retries, prüfen Sie Statuscodes und schützen Sie den interaktiven Traffic. Wenn der Vorfall bestätigt ist, bevorzugen Sie Provider-Failover vor Model-Fallback und eine base_url-Konfigurationsumschaltung vor einem Code-Deployment.

Kann ich ohne Codeänderungen von OpenRouter auf einen anderen Dienst umschalten?

Ja, wenn Ihre App den OpenAI-kompatiblen Endpunkt bereits aus der Konfiguration liest. Legen Sie baseURL oder base_url hinter eine Umgebungsvariable, halten Sie die SDK-Aufrufstruktur stabil und wechseln Sie den Endpunkt in der Deployment-Konfiguration.

Sollte ich während eines Ausfalls OpenRouter-Model-Fallbacks verwenden?

Verwenden Sie Model-Fallbacks nur, wenn das Fallback-Modell für die Aufgabe akzeptabel ist. Sie sind für viele interne Workflows geeignet, aber nicht für Evals, regulierte Ausgaben oder Fälle, in denen Kunden ein bestimmtes Modell zugesichert wurde.

Was ist die sicherste langfristige Lösung für das OpenRouter-Down-Risiko?

Konzipieren Sie auf Routeneebene für Portabilität: konfigurierbare base_url, Logging auf Request-Ebene, Retry-Budgets, Provider-Failover, getestete Model-Fallback-Verträge und einen Backup-Pfad über ein OpenAI-kompatibles Gateway. Das Ziel ist nicht, jeden Ausfall zu vermeiden; es ist, das Failover langweilig zu machen.