OpenRouter Fusion: Kosten nach Panel-Größe und Token-Verbrauch

Auf der OpenRouter-Modellseite kann ein Fusion-Aufruf kostenlos aussehen und trotzdem ein Mehrfaches einer normalen Completion kosten. Der Grund: Die OpenRouter-Fusion-Kosten setzen sich aus mehreren zugrunde liegenden Modellaufrufen zusammen – es gibt keinen eigenständigen Preis pro Fusion-Token. Entscheidend sind die Größe des Panels und das Token-Volumen. Beides bestimmt, ob sich die zusätzliche Prüfung tatsächlich lohnt.

OpenRouter Fusion: die wichtigste Kostenentscheidung

OpenRouter Fusion ist normalerweise teurer, als ein vergleichbares Modell einmalig aufzurufen. In der Dokumentation zum Fusion Router von OpenRouter ist standardmäßig ein Panel aus drei Modellen sowie ein Analyseaufruf vorgesehen. Zusammen entspricht das ungefähr dem 4- bis 5-Fachen der Kosten einer einzelnen Completion mit demselben Prompt.

Ein günstiges Panel kann gegenüber einem Premium-Modell trotzdem die bessere Wahl sein, wenn die höhere Qualität Nacharbeit spart. Fusion ist aber eine Abwägung zwischen Kosten und zusätzlicher Prüfung – kein automatisch günstigeres Modell.

Abgerechnet wird ein Modell-Stack, kein Fusion-Token

Auf der Fusion-API-Seite von OpenRouter wird Fusion als Router dargestellt. Für den Router-Alias stehen dort null Kosten für Prompt und Completion. Das bedeutet, dass Fusion selbst keinen separaten Standardtarif hat – nicht, dass die zugrunde liegende Inferenz kostenlos ist.

Der dokumentierte Ablauf sieht so aus:

1. Der Prompt wird an jedes ausgewählte Panel-Modell gesendet.
2. Ein Analyse- oder Bewertungsmodell vergleicht die Antworten des Panels.
3. Das äußere Modell erstellt die finale Antwort.

Für die Budgetplanung eignet sich folgende Formel:

Fusion-Kosten = Summe der Kosten aller Panel-Modelle
               + Kosten des Analyse-/Bewertungsmodells
               + mögliche Kosten des finalen äußeren Modells laut Integration

Wie genau abgerechnet wird, hängt davon ab, ob Fusion über das Modell-Alias openrouter/fusion oder als Server-Tool openrouter:fusion aufgerufen wird. Aus der angezeigten $0-Zeile des Routers lässt sich die Endabrechnung nicht ableiten. Prüfe stattdessen den tatsächlichen Generation-Eintrag und den Datensatz in OpenRouter Activity.

OpenRouter dokumentiert 1 bis 8 Analysemodelle. Das Standard-Panel besteht aus drei Modellen. Durch die Konfigurationen „Quality“, „Budget“ und eigene Zusammenstellungen gibt es deshalb keinen universellen Fusion-Preis pro einer Million Tokens.

Die Panel-Größe erhöht die Kosten linear – bis der Bewertungsaufwand wächst

Wenn jedes Panel-Modell denselben Prompt erhält und ungefähr gleich viel ausgibt, verursacht jedes zusätzliche Panel-Mitglied in etwa einen weiteren Modellaufruf. OpenRouter weist ausdrücklich darauf hin, dass die Kosten linear mit der Panel-Größe steigen.

Die reine Zahl der Aufrufe unterschätzt allerdings die Kosten des Bewertungsmodells, weil dessen Eingabe mit den Panel-Antworten wächst:

C(n) = n × Cp + Cj(n) + Co

Dabei steht n für die Anzahl der Panel-Modelle, Cp für die durchschnittlichen Kosten einer Panel-Antwort, Cj(n) für die Kosten des Bewertungsmodells einschließlich seiner wachsenden Eingabe und Co für die Kosten der äußeren Antwort, sofern diese anfällt.

Die Schätzung von 4 bis 5× für das standardmäßige Drei-Modelle-Panel ist damit ein besserer Planungswert als die $0-Anzeige des Routers. Der Multiplikator kann steigen, wenn das Bewertungsmodell teuer ist, die Antworten lang ausfallen oder das äußere Modell eine weitere kostenpflichtige Completion erzeugt.

Ein Rechenbeispiel mit anpassbaren Preisen

Nutze dieses Schema mit den aktuellen Preisen der von dir ausgewählten Modelle. Die folgenden Werte sind illustrative Annahmen und keine OpenRouter-Preise: 10.000 Eingabe-Tokens, 2.000 Ausgabe-Tokens pro Panel-Antwort, 6.000 Tokens für die Eingabe des Bewertungsmodells und 1.000 Ausgabe-Tokens für dessen Antwort.

Panel-Eingabe   = 10.000 × Summe der Panel-Eingabepreise
Panel-Ausgabe   = 2.000 × Summe der Panel-Ausgabepreise
Bewertungsinput = 6.000 × Eingabepreis des Bewertungsmodells
Bewertungsausgabe = 1.000 × Ausgabepreis des Bewertungsmodells
Fusion gesamt   = Panel-Eingabe + Panel-Ausgabe + Bewertungsinput + Bewertungsausgabe

Wenn ein einzelnes Basismodell dieselben 10.000 Eingabe- und 2.000 Ausgabe-Tokens verarbeitet, kannst du dessen Gesamtkosten direkt mit diesem Schema vergleichen. Bei einem Panel aus drei Modellen wird der Prompt in diesem Beispiel dreimal berechnet; zusätzlich verarbeitet das Bewertungsmodell einen separaten Kontext mit 6.000 Tokens. Passe die Annahmen an, wenn deine Prompts oder Antworten länger sind.

Unter der vereinfachten Annahme identischer Modellkosten ergibt sich folgende Struktur:

Das sind keine OpenRouter-Preise. Die Tabelle zeigt, warum die Panel-Größe schon vor dem Vergleich unterschiedlicher Modellpreise eine wichtige Rolle spielt. Ein teures Bewertungsmodell kann ein günstiges Panel überproportional verteuern; umgekehrt können besonders leistungsfähige Panel-Modelle die Kosten des Bewertungsmodells übersteigen.

Der Token-Verbrauch verändert den Vergleich auf zwei Arten

Der Token-Verbrauch wirkt sich bei Fusion stärker aus als bei einem einzelnen Aufruf: Der Prompt wird mehrfach verarbeitet, und das Bewertungsmodell erhält zusätzlich die generierten Antworten des Panels.

1. Eingabe-Tokens werden über das Panel vervielfacht

Sei I die Anzahl der Prompt-Tokens und Pi der Eingabepreis des Panel-Modells i:

Kosten der Panel-Eingabe = I × (P1 + P2 + ... + Pn)

Ein Prompt mit 10.000 Tokens, der an drei Panel-Modelle gesendet wird, erzeugt drei separate Eingabekosten – möglicherweise zu drei unterschiedlichen Preisen.

2. Auch Ausgabe-Tokens summieren sich

Erzeugt jedes Panel O Ausgabe-Tokens, entstehen im Panel ungefähr n × O Ausgabe-Tokens. Abgerechnete Reasoning-Tokens können den Abstand zusätzlich vergrößern, selbst wenn die sichtbaren Antworten gleich lang bleiben.

Anschließend liest das Bewertungsmodell diese Antworten:

Bewertungseingabe ≈ ursprünglicher Prompt + n × Panel-Ausgabe + Orchestrierungs-Overhead

Eine längere Antwort kann die Kosten also sowohl durch die einzelnen Panel-Antworten als auch durch den Eingabekontext des Bewertungsmodells erhöhen.

Eine brauchbare monatliche Schätzung lautet:

Monatliche Gesamtkosten ≈ Anfragen × (Panel-Eingabe + Panel-Ausgabe
                                   + Bewertungseingabe + Bewertungsausgabe
                                   + äußere Antwort)

Verwende für die konkrete Kalkulation die aktuellen Preise der Modell-IDs in deinem Panel. „Budget“ ist die Bezeichnung eines Presets und keine Garantie dafür, dass die Gesamtkosten unter denen jedes einzelnen Modells liegen.

Budget, Qualität oder doch ein einzelnes Modell?

Ein einzelnes Modell ist die richtige Wahl, wenn Geschwindigkeit, Wiederholbarkeit und planbare Abrechnung wichtiger sind als eine unabhängige Gegenprüfung. Das gilt etwa für Formatierung, Extraktion, Autovervollständigung, routinemäßige Umformulierungen und viele gewöhnliche Coding-Prompts.

Fusion lohnt sich eher, wenn ein übersehener Fehler teuer wäre: bei quellenintensiver Recherche, Expertenkritik, Due-Diligence-Prüfungen oder Entscheidungen mit widersprüchlichen Belegen. Starte mit dem kleinsten Panel, das die jeweilige Frage sinnvoll beantworten kann. Drei Modelle sind der dokumentierte Standard; acht ist das Maximum, keine Empfehlung.

Der relevante Vergleich lautet:

zusätzliche Fusion-Kosten
gegen
vermiedene Korrekturkosten + eingesparte Zeit für menschliche Prüfung + geringeres Fehlerrisiko

In einer separaten Benchmark-Ankündigung berichtet OpenRouter über eine DRACO-Evaluierung mit 100 Aufgaben. Eine Frontier-Fusion-Konfiguration erreichte dabei 69,0 %, ein Budget-Panel 64,7 %. Diese Werte sprechen für Anwendungsfälle in der intensiven Recherche. Sie sind aber keine Erfolgsquote für jeden Prompt und kein Beleg dafür, dass ein größeres Panel wirtschaftlicher ist.

Vor dem Skalieren die tatsächlichen Kosten prüfen

Behandle den ersten Fusion-Einsatz als Messprojekt. Protokolliere:

1. IDs der Panel-Modelle und ID des Bewertungsmodells.
2. Eingabe-, Ausgabe- und Reasoning-Token, sofern diese Daten verfügbar sind.
3. Router-Metadaten als Bestätigung, dass Fusion tatsächlich ausgeführt wurde.
4. Gesamtkosten und Latenz.
5. Ob die finale Antwort den Aufwand für menschliche Korrekturen reduziert hat.

Die Fusion-Dokumentation weist darauf hin, dass die Generation-Metadaten "router": "openrouter/fusion" enthalten können. Das reguläre Feld model nennt lediglich das konkrete Modell, das die Anfrage bearbeitet. Es reicht nicht aus, um zu belegen, dass Fusion ausgeführt wurde.

Ein Nutzerbericht zeigt, wo Konfigurationsrisiken liegen:

„dieses \"Fusion\" ruft weiterhin Opus 4.8 als Bewertungsmodell auf. Ich sehe keine Möglichkeit, das zu deaktivieren.“ – @teortaxesTex auf X

Das ist ein Nutzerbericht und keine Preisregel von OpenRouter. Er zeigt jedoch, warum ein günstiges Panel nicht automatisch einen günstigen Lauf garantiert, wenn das Bewertungsmodell teuer ist oder die tatsächliche Konfiguration von den Erwartungen abweicht.

Für den produktiven Einsatz solltest du Panel und Bewertungsmodell fest vorgeben, sofern die API das erlaubt, Budgetlimits setzen und Fusion als bewussten Eskalationspfad nutzen – statt jede autonome Anfrage darüber laufen zu lassen.

FAQ zu den OpenRouter-Fusion-Kosten

Ist Fusion günstiger als ein einzelnes Modell?

Im Vergleich zu einem ähnlich teuren Einzelmodell normalerweise nicht. Gegenüber einem Premium-Modell kann Fusion günstiger sein, wenn ein Budget-Panel ausreichend gute Ergebnisse liefert. Entscheidend sind jedoch die Panel-Preise, die Kosten des Bewertungsmodells und der Token-Verbrauch.

Ist OpenRouter Fusion kostenlos?

Der Router-Alias kann in den eigenen Prompt- und Completion-Feldern $0 anzeigen. OpenRouter weist jedoch separat darauf hin, dass die zugrunde liegenden Panel- und Bewertungs-Completions abgerechnet werden. Ein normaler Fusion-Aufruf sollte daher nicht als kostenlos angesehen werden.

Wie viele Aufrufe erzeugt eine Fusion-Anfrage?

Der dokumentierte Ablauf umfasst N Panel-Aufrufe plus einen Analyseaufruf. Ob zusätzlich eine äußere Antwort anfällt, hängt von der Integration ab. Für das Standard-Panel mit drei Modellen nennt OpenRouter ungefähr das 4- bis 5-Fache einer vergleichbaren Completion.

Steigert ein größeres Panel immer den Nutzen?

Nein. Mehr Modelle können zusätzliche Perspektiven liefern, erhöhen aber auch Panel-Kosten, Bewertungskontext, Latenz und die Gefahr korrelierter Fehler. Vergrößere das Panel nur, wenn Tests mit zurückgehaltenen Beispielen zeigen, dass der Qualitätsgewinn die zusätzlichen Kosten übersteigt.

Wie lassen sich die OpenRouter-Fusion-Kosten schätzen?

Liste jeden zugrunde liegenden Modellaufruf auf, multipliziere die aktuellen Eingabe- und Ausgabepreise mit dem erwarteten Token-Verbrauch, berücksichtige die Bewertungseingabe einschließlich der Panel-Antworten und überprüfe das Ergebnis nach einem echten Aufruf in Activity. Ein Rechner eines Drittanbieters kann bei Szenarien helfen. Maßgeblich sind jedoch die aktuellen OpenRouter-Preise und dein Activity-Eintrag.

Die praktische Empfehlung

Nutze ein einzelnes Modell als Baseline. Schicke einen Holdout-Datensatz mit 20–50 Prompts sowohl durch diese Baseline als auch durch ein kleines Fusion-Panel. Behalte Fusion nur dann bei, wenn weniger faktische Korrekturen, weniger übersehene Belege oder weniger Prüfaufwand die zusätzlichen Panel- und Bewertungs-Tokens rechtfertigen.

Für die meisten Teams ist ein kostenbewusster Rollout daher klar strukturiert: ein Modell für Routineanfragen, Fusion mit kleinem Panel für unsichere oder besonders folgenreiche Entscheidungen und größere Panels nur dann, wenn der gemessene Mehrwert die Rechnung übersteht.