OpenRouter Fusion Flash API: Status, Einrichtung und Lösungen für 400-Fehler

Wer nach der OpenRouter Fusion Flash API sucht, will meist entweder das schnelle Fusion-Preset nutzen oder einen HTTP-400-Fehler beheben. In der offiziellen Dokumentation steht zwar openrouter/fusion-flash, in der Live-Modellsuche kann der Eintrag jedoch fehlen. Prüfe den Alias deshalb vor der Integration in deinem Account.

Ist OpenRouter Fusion Flash tatsächlich verfügbar?

Die offizielle Dokumentation zum Fusion Router führt openrouter/fusion-flash als eigene Model-Slug auf. Der Alias wird dort als Fusion mit dem standardmäßig aktivierten Preset general-fast beschrieben. Dieses Preset ist auf schnellere, agentische Interaktionen ausgelegt und verwendet ein Panel, das für gleichmäßigere Latenzen zusammengestellt wird.

Im selben offiziellen Leitfaden wird Standard-Fusion als Ablauf mit parallel antwortenden Panel-Modellen, einem Analysten zum Abgleich von Konsens und Abweichungen sowie einem äußeren Modell für die finale Antwort erklärt. Fusion Flash ist dabei das schnellere Preset dieses zusammengesetzten Routers – kein einzelnes Provider-Modell.

Der für diesen Leitfaden am 11. September 2026 abgerufene Live-Modellkatalog von OpenRouter enthielt openrouter/fusion, aber keinen separaten Eintrag für openrouter/fusion-flash. Ein Nutzer meldete auf X genau dieses Verhalten:

„In der Dokumentation steht, dass openrouter/fusion-flash als separat gelistetes Modell mit einem eigenen /api/v1/models-Eintrag geführt wird. API-Aufrufe liefern derzeit jedoch einen 400-Fehler: fusion-flash ist keine gültige Modell-ID.“ – @PeterDaveHello

Das ist ein Nutzerbericht und keine Bestätigung von OpenRouter. Die offizielle Dokumentation beschreibt Fusion, aber für diesen Leitfaden wurde keine offizielle Ankündigung gefunden, die einen separaten Rollout oder Rückzug von Fusion Flash bestätigt. Die sicherste Schlussfolgerung lautet daher: dokumentiert, aber vor der Integration live prüfen.

Was du vor der Code-Analyse prüfen solltest

Rufe den Modellkatalog mit demselben Schlüssel und in derselben Umgebung auf, die auch deine Anwendung verwendet:

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

Durchsuche das JSON nach der exakten Zeichenfolge openrouter/fusion-flash. Leite die Verfügbarkeit nicht aus einer Modellseite, einer SDK-Autovervollständigung oder einer zwischengespeicherten Integration ab. Die OpenRouter-Dokumentation zu Modellen behandelt den Katalog als Quelle für aktuelle Modell-IDs und unterstützte Parameter.

Ein Blick auf die offizielle Statusseite lohnt sich ebenfalls. Ein grüner Plattformstatus beweist allerdings nicht, dass ein bestimmter Router-Alias gerade funktioniert. Das Status-Dashboard meldet übergreifende Komponenten wie Chat API und Data API; ein Alias-spezifischer Katalog- oder Konfigurationsfehler kann bestehen, während die allgemeine Chat API weiterhin läuft.

Minimale Einrichtung der OpenRouter Fusion Flash API

Beginne mit der kleinstmöglichen Chat-Completions-Anfrage. So bleiben SDK-Adapter, Tool-Schemas, Streaming und individuelle Fusion-Einstellungen aus dem ersten Test heraus.

export OPENROUTER_API_KEY="your-key"

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion-flash",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word: ready"
      }
    ],
    "stream": false
  }'

Der Code zeigt Endpoint und Header. Lass stream: false beim ersten Test aktiviert, damit sich der vollständige Fehler-Body leichter untersuchen lässt.

Wenn der Alias in /api/v1/models auftaucht und diese Anfrage erfolgreich ist, füge die Felder deiner Anwendung einzeln wieder hinzu. Fehlt der Alias, solltest du nicht weiter an Prompts drehen oder dieselbe Anfrage wiederholen. Teste stattdessen die dokumentierte Entsprechung:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion",
    "plugins": [
      {"id": "fusion", "preset": "general-fast"}
    ],
    "messages": [
      {"role": "user", "content": "Reply with the word: ready"}
    ],
    "stream": false
  }'

Dieser Fallback prüft, ob die Fusion-Route und das schnelle Preset erreichbar sind. Er beweist jedoch nicht, dass Alias und explizite Konfiguration in jedem Backend-Detail identisch behandelt werden.

Systematische Analyse von 400-Fehlern bei der OpenRouter Fusion Flash API

Ein 400-Fehler deutet meist auf eine Ablehnung der Anfrage oder des Providers hin; die genaue Ursache steht im Response-Body. Er ist etwas anderes als ein 500-Ausfall oder eine HTTP-200-Antwort, in der lediglich die interne Fusion-Operation fehlgeschlagen ist. Arbeite die folgenden Schritte in dieser Reihenfolge ab, damit jeder Test eine konkrete Frage beantwortet.

1. Den vollständigen Fehler-Body auslesen

Speichere die Antwort, statt nur 400 Bad Request zu protokollieren:

curl -i https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openrouter/fusion-flash","messages":[{"role":"user","content":"ready"}]}'

Achte auf Fehlercode, Fehlermeldung, Providernamen, Request- oder Generation-ID sowie zusätzliche Metadaten. „fusion-flash is not a valid model ID“ spricht für eine Abweichung zwischen Katalog und Rollout. „Provider returned error“ deutet darauf hin, dass die Anfrage einen Provider-Pfad erreicht hat, dort aber abgewiesen wurde. Ein allgemeiner 400-Fehler ohne Details ist ein guter Grund, den OpenRouter-Aktivitätsdatensatz zu prüfen, statt zu raten.

2. Die exakte Modell-ID bestätigen

Modell-IDs sind schreibungsabhängige Zeichenfolgen. Vergleiche die Anfrage mit der Live-Antwort von /api/v1/models – einschließlich Zeichensetzung und Schrägstrich. Entferne veraltete Aliase aus der Anwendungskonfiguration und ersetze sie nicht stillschweigend durch einen geratenen Gemini- oder anderen Flash-Modellnamen.

Eine hilfreiche Diagnosematrix sieht so aus:

3. Nicht unterstützte Felder entfernen

Sende zunächst nur model, messages, stream: false und die beiden erforderlichen Header. Führe die Felder anschließend in dieser Reihenfolge wieder ein:

1. temperature oder Reasoning-Einstellungen.
2. plugins und das Fusion-Preset.
3. Individuelle analysis_models oder ein Analysten-model.
4. tools und tool_choice.
5. Streaming sowie framework-spezifische Antwortoptionen.

Der Fusion-Leitfaden von OpenRouter dokumentiert analysis_models, model, preset, max_tool_calls, max_completion_tokens, reasoning und temperature. Ein Feld, das für einen Endpoint oder eine Modellfamilie dokumentiert ist, muss deshalb nicht automatisch für jedes vorgelagerte Modell gültig sein. Die OpenRouter-Referenz zu Modellen und die Metadaten zu den unterstützten Parametern des jeweiligen Modells sind die maßgeblichen Prüfstellen.

4. Tool- und Nachrichtenverlauf vereinfachen

Tool-fähige Clients können verwirrende 400-Fehler verursachen, wenn der finale Payload ein ungültiges JSON-Schema, einen nicht unterstützten Tool-Parameter oder eine unvollständige Folge aus Assistant- und Tool-Nachrichten enthält. Ein öffentlicher Bericht zu Hermes Agent dokumentierte OpenRouter-400-Fehler in Version 0.10.0 mit aktivierten Tools über mehrere getestete Modelle hinweg. Der Bericht vermutete als Ursache die standardmäßig aktivierten 28 Tools, enthielt aber weder einen erfolgreichen Kontrolltest ohne Tools noch eine bestätigte Root Cause. Sieh dir Issue #13927 daher als Ansatz zur Reproduktion an – nicht als Beleg dafür, dass jeder Fusion-Flash-400-Fehler durch Tools entsteht.

Teste zur Eingrenzung alle drei Varianten:

• Sende denselben Prompt ohne tools.
• Sende ein einzelnes minimales Tool mit einem einfachen Objekt-Schema.
• Starte eine neue Unterhaltung ohne vorherige Tool-Aufrufe oder Tool-Ergebnisse.

Wenn die minimale Textanfrage und die reduzierte Tool-Anfrage funktionieren, füge die Tools einzeln wieder hinzu. Schlägt nur ein langer Tool-Verlauf fehl, während eine frische Anfrage erfolgreich ist, kürze oder fasse den Verlauf zusammen, bevor du das Modell selbst untersuchst.

5. Alias-, Router- und Provider-Fehler auseinanderhalten

Fusion kann Panel-Modelle, ein Analystenmodell und ein äußeres Antwortmodell einbeziehen. Ein Fehler in einem internen Aufruf sieht daher nicht zwingend wie ein normaler Single-Model-Fehler aus. Laut OpenRouter-Dokumentation solltest du Generation- und Aktivitätsdaten prüfen, um zu sehen, was tatsächlich ausgeführt wurde. Das Feld model in der normalen Antwort kann das konkrete äußere Modell nennen; allein daraus lässt sich jedoch nicht beweisen, ob Fusion verwendet wurde.

Bei einem erfolgreichen Fusion-Lauf enthalten die dokumentierten Generationsmetadaten:

{
  "router": "openrouter/fusion"
}

Wenn du individuelle analysis_models angibst, entferne sie und teste das Preset erneut. Funktioniert das Preset, aber ein bestimmtes eigenes Modell nicht, liegt das Problem wahrscheinlich an den Parametern dieses Modells, seiner Provider-Verfügbarkeit oder den Kontextlimits. Schlagen alle Modelle nur über ein SDK fehl, vergleiche den tatsächlichen SDK-Payload mit dem funktionierenden cURL-Payload. OpenAI-kompatible Clients können Tools, Streaming-Flags, Antwortformate oder Nachrichten-Transformationen hinzufügen, die im Anwendungscode nicht sichtbar sind.

Wann du mit dem Wiederholen aufhören solltest

Automatische Retries lösen keine ungültige Modell-ID und keine deterministische Schema-Ablehnung. Ein als nicht wiederholbar markierter 400-Fehler sollte stattdessen einen klaren Fallback auslösen:

• Alias fehlt in der Modellsuche: auf openrouter/fusion mit general-fast wechseln oder ein bekanntes gewöhnliches Modell verwenden und den Katalog weiter beobachten.
• Payload-spezifischer 400-Fehler: die minimale Anfrage als Regressionstest behalten und das erste Feld korrigieren, durch dessen Hinzufügen der Fehler auftritt.
• Provider-spezifischer 400-Fehler: das betroffene Panel-Modell entfernen oder einen konfigurierten Fallback nutzen; die Provider-Antwort protokollieren.
• Übergreifender Vorfall der Chat API: die OpenRouter-Statusseite prüfen und den Rollout pausieren, statt die Anwendungslogik zu verändern.
• HTTP 200 mit internem Fehler: Panel-Fehler protokollieren und entscheiden, ob ein Teilergebnis akzeptabel ist; nicht als Authentifizierungsfehler klassifizieren.

Die offizielle Dokumentation zum Fusion Router schätzt, dass das standardmäßige Panel aus drei Modellen ungefähr 4–5 Mal so viel kostet wie eine einzelne Completion; die exakte Abrechnung hängt von den zugrunde liegenden Aufrufen ab. Ein Fallback schützt daher sowohl die Zuverlässigkeit als auch die Kosten, solange der Alias-Status unklar ist.

FAQ zur OpenRouter Fusion Flash API

Wie lautet die richtige OpenRouter-Fusion-Flash-Modell-ID?

Die offizielle Dokumentation führt openrouter/fusion-flash. Prüfe diese exakte Zeichenfolge vor dem Deployment mit GET /api/v1/models, da Dokumentation und Live-Suche vorübergehend voneinander abweichen können.

Ist Fusion Flash ein gewöhnliches schnelles Modell?

Nein. Es wird als Fusion mit dem Preset general-fast dokumentiert. Intern können trotzdem mehrere Modellaufrufe stattfinden. „Flash“ beschreibt also das Ziel einer geringeren Latenz, nicht die Ausführung in nur einem Aufruf.

Welchen Endpoint sollte ich verwenden?

Verwende https://openrouter.ai/api/v1/chat/completions mit Bearer-Authentifizierung und einem JSON-Body. Erfinde keinen eigenen Fusion-spezifischen URL-Pfad.

Kann ich Fusion zur Ausführung zwingen?

Die Fusion-Dokumentation unterstützt tool_choice: "required". Wenn Fusion das einzige verfügbare Tool ist, erzwingt das effektiv einen Tool-Aufruf. Sind weitere Tools vorhanden, bedeutet required lediglich, dass irgendein Tool aufgerufen werden muss – nicht zwingend Fusion.

Warum kann die OpenRouter-Statusseite grün sein, obwohl Fusion Flash 400 liefert?

Die Statusseite meldet übergreifende Dienstkomponenten. Ein fehlender Alias, eine ungültige Router-Konfiguration oder eine provider-spezifische Ablehnung kann eine einzelne Route beeinträchtigen, während die allgemeine Chat API weiter funktioniert.

Ist Fusion Flash kostenlos?

Gehe nicht davon aus. Die Fusion-Modellseite von OpenRouter erklärt, dass die zugrunde liegenden Panel- und Analysten-Completion zur Abrechnung beitragen, auch wenn der Router-Alias keinen eigenen Tokenpreis ausweist. Prüfe vor dem produktiven Einsatz die Aktivitätsdaten und die Preise der ausgewählten Modelle.

Nutze das schnelle Preset nur dann, wenn Live-Suche und minimale Anfrage dasselbe Ergebnis liefern. Andernfalls wechsle auf Standard-Fusion oder ein bekanntes Modell und sichere den fehlschlagenden Payload, statt blind weiter zu wiederholen.