OpenRouter Provider Routing erklärt: Update Oktober 2026

OpenRouter hat sein Standard-Routing am 28. Oktober 2026 neu aufgestellt: Die Zeit bis zum ersten Token sank um 16,9 %, insgesamt traten 67 % weniger 429-Fehler auf, dafür wurden Requests rund 6 % teurer. Das automatische Routing kann dich weiterhin unbemerkt zu einem kostspieligeren Provider schicken. Genau deshalb ist der Trade-off wichtiger als die Schlagzeile.

Der neue Router von OpenRouter wählt nicht mehr einfach den Anbieter mit dem günstigsten Input-Token-Preis. Stattdessen schätzt er, was eine gute Antwort tatsächlich kostet – inklusive Preis, Wartezeit und Retries – und schickt den Request an den Provider mit den niedrigsten Routing Costs.

Das Fazit in 30 Sekunden – mit Zahlen belegt

OpenRouter optimiert das Provider-Routing jetzt auf Routing Cost statt auf den Prompt-Token-Preis. Die Änderung greift automatisch, wenn ein Request kein explizites provider.sort, provider.order, provider.only oder provider.ignore setzt. Sie betrifft laut OpenRouter-Ankündigung außerdem rund 77 % des Traffics, der an Modelle mit mehreren Providern geht.

Die Ergebnisse stammen aus einem einwöchigen Switchback-Test mit 24 Millionen Requests und 103 Milliarden Input-Tokens. Die Hälfte lief über den alten, die andere Hälfte über den neuen Router.

\*Die Anteile der Requests und die Rückgänge bei den Event-Zahlen werden beide in der Ankündigung genannt: Die 67 % und 47 % beziehen sich auf alle 429-Events beziehungsweise alle Retries – nicht auf das Verhältnis der Trefferquoten, da ein Request mehrere Fehler auslösen kann.

Laut Ankündigung sank das vom Client gemessene TTFT-p95 von 6.032 ms auf 4.504 ms. Das p50 für den gesamten Request fiel von 4,00 s auf 3,24 s. Die in fehlgeschlagenen Versuchen verlorene Zeit ging von 349 ms auf 242 ms pro Request zurück.

Unterm Strich: Für interaktive Chats und Agents lohnt sich der neue Standard, wenn rund 6 % höhere Kosten vertretbar sind. Bei großen Batch-Jobs, bei denen jeder Cent zählt, ist das preisbasierte Routing die bessere Wahl.

Routing Cost einfach erklärt

Routing Cost beantwortet für jeden Provider zwei Fragen: Was kostet ein Versuch – und wie oft funktioniert er? Das Beispiel von OpenRouter: Ein Versuch kostet $0.40, weitere $0.60 entsprechen der Wartezeit. Das ergibt $1.00, geteilt durch eine Erfolgswahrscheinlichkeit von 80 % also $1.25 pro erfolgreicher Antwort. Der Anbieter mit den niedrigsten Kosten bekommt mehr Traffic.

In die Berechnung fließen drei Faktoren ein:

1. Effektiver Preis statt Listenpreis. OpenRouter schätzt anhand des aktuellen Traffics die Input- und Output-Tokens und berücksichtigt dann die tatsächliche Cache-Trefferquote sowie die Token-Preise des jeweiligen Providers. Das Rechenbeispiel aus der Ankündigung: 40.000 uncached Inputs zu $2.00/M ($0.080) plus 60.000 gecachte Inputs zu $0.50/M ($0.030) plus rund 4.000 Outputs zu $8.00/M ($0.032) ergeben $0.142. Ein Provider mit günstigen Input-Tokens, aber teuren Cache- oder Output-Tokens verliert dadurch seinen Preisvorteil.
2. Wartezeit als Kostenfaktor. Der Durchsatz wird Ende-zu-Ende als Output-Tokens pro Sekunde berechnet und enthält die Zeit bis zum ersten Token. Beispiel: 5 Sekunden bis zum ersten Token plus 500 Tokens in weiteren 5 Sekunden ergeben 50 Tok/s. Der Router rechnet die Wartezeit mit einem modellspezifischen Satz um, der sich an typischen Provider-Preisen und Geschwindigkeiten orientiert. Die Zeit bis zum ersten Token wird stärker gewichtet, weil Agentenketten bei jedem Schritt darauf warten.
3. Kosten durch Fehler. Ein 429 bedeutet, dass der Provider den Request abgewiesen hat. Die Wartezeit bis zur Ablehnung fällt trotzdem an, anschließend muss der Request woanders erneut gesendet werden. Im Beispiel ergeben 2,50 Wartezeit plus eine Strafe bei einer Rate von 0,4 % zusätzliche 0,01. Zuverlässigkeitsfehler werden mit einer etwa achtmal höheren Strafe bewertet: Eine Fehlerquote von 1 % erhöht die Kosten um rund 8 %. Provider, die deutlich schlechter als ihre Konkurrenten abschneiden, erhalten bis zur Erholung keinen Traffic mehr. Auch die Qualität fließt ein: Bei 95 % korrekt formatierten Tool-Calls steigen die Kosten um etwa 5 %. Markierte Provider werden laut Ankündigung nur noch mit Test-Traffic berücksichtigt.

Zwei Schutzmechanismen verhindern, dass der gesamte Traffic bei einem einzigen Gewinner landet, so OpenRouter: Jeder Provider erhält weiterhin einen kleinen Traffic-Anteil, damit eine Erholung sichtbar wird. Gleichzeitig fährt der Router den Traffic bei fehlerhaften Providern zurück, lernt deren Kapazitätsgrenzen und verteilt Überschüsse auf andere Anbieter.

Warum das Standard-Routing in Produktions-Apps trotzdem Probleme macht

Berichte von Nutzern zeigen vier wiederkehrende Fehlerbilder, die der Preis pro Token allein nicht abbildet.

Tool-Call-Ketten können Schemas beschädigen

Bei mir hat nicht der Preis eines einzelnen Providers das Tool-Calling kaputtgemacht, sondern der Wechsel mitten im Request.

— u/Michael_Jeffords, Thread zu Providern, die man meiden sollte, auf r/openrouter

Die Qualitätsbewertung basiert derzeit hauptsächlich auf korrekt formatierten Tool-Calls und Markierungen aus Genauigkeits-Benchmarks, laut Ankündigung. Ein Wechsel mitten im Gespräch kann dennoch Quantisierung oder Verweigerungsverhalten verändern, denn die Provider-Qualität unterscheidet sich und manche Anbieter liefern stärker quantisierte Varianten aus.

Cache-Verlust treibt die Rechnung hoch

Ein Thread dokumentiert Kontexte mit rund 700.000 Tokens, bei denen erwartete, gecachte Requests für $0.20 nach einem Provider-Wechsel plötzlich fast $2.00 kosteten. Dahinter steckt das Muster, wegen kaputtem Caching „10- bis 32-mal mehr zu bezahlen“. Der neue Router bindet eine Unterhaltung an ihren ursprünglichen Provider, solange der Cache warm ist, und wählt den Anbieter algorithmisch nur für den ersten Request aus – laut OpenRouters cache-bewusstem Routing. Beim Fallback auf einen anderen Provider geht diese Bindung jedoch verloren. Nutzer, die das Problem gelöst haben, setzen deshalb einen Provider mit Sticky Sessions fest.

Ich halte es für einen ziemlich grundlegenden Fehler von OR, dass man das vorher manuell konfigurieren muss.

— u/welcome_to_milliways, Thread zu kaputtem Caching auf r/openrouter

Teurer Fallback ohne Hinweis

In einem Produktionsbericht verlagerte sich ein Teil des Traffics unbemerkt von Sonnet zu Opus – bei einem etwa fünfmal höheren Listenpreis. Während die Uptime weiterhin grün war, stieg der Gesamtverbrauch von $184/hr auf $412/hr, laut @CarbonOnX. Der neue Router macht diesen Zielkonflikt transparent: Ein schnellerer und zuverlässigerer Provider kann den günstigsten Anbieter zu Recht überholen.

429er trotz bezahltem Account

Ein aufgeladenes OpenRouter-Konto erhöht nicht die Kapazität beim Upstream-Provider, wie Nutzer in diesem 429-Thread erklären. Ein 429 zeigt an, dass der gemeinsame Pool dieses Providers für das Modell ausgelastet ist. Der Umbau reduzierte die Zahl der 429-Events im Test zwar um 67 %, in der Produktion bleibt das Festlegen oder Ausschließen des betroffenen Providers aber die Lösung. Einstiegshilfe ist OpenRouter-429-Fehler beheben; für das ältere, preisgewichtete Standard-Routing gibt es den OpenRouter-Auto-Router-Guide.

Drei Routing-Setups, die in der Praxis funktionieren

Welches Setup passt, hängt davon ab, ob dir unkomplizierte Geschwindigkeit, ein striktes Kostenlimit oder deterministisches Verhalten wichtiger ist. Alle Varianten verwenden dasselbe provider-Objekt: provider.order umgeht die neue Logik und probiert die Provider in exakt dieser Reihenfolge. provider.only und provider.ignore filtern zunächst die Kandidaten; anschließend wählt der neue Algorithmus aus den verbleibenden Anbietern. Ein explizites provider.sort (price, throughput, latency) ersetzt die neue Standardlogik.

1. Beim neuen Standard bleiben (interaktive Chats und Agents)

Eine Codeänderung ist nicht nötig. Das passt zu nutzerorientierten Chats und mehrstufigen Agents, bei denen jeder Tool-Call auf das erste Token wartet. Dafür akzeptierst du rund 6 % höhere Kosten als Preis für weniger Latenz und Retries. Logge eine Woche lang den ausliefernden Provider – er steht in der API-Antwort und auf der Activity-Seite – zusammen mit TTFT-p50 und 429-Rate. Bleibt dein 429-Anteil nahe dem neuen Basiswert von rund 4 % und hält sich die Cache-Trefferquote, kannst du beim Standard bleiben. Dominiert ein Provider die Fehler oder bricht die Cache-Trefferquote ein, solltest du zu Setup 3 wechseln.

2. Den günstigsten Pfad festlegen (Batch-Jobs und Kostenlimits)

Wenn Kosten wichtiger sind als Geschwindigkeit, gibt es drei Möglichkeiten für preisorientiertes Routing:

{ "provider": { "sort": "price" } }

Alternativ hängst du :floor an den Model-Slug (meta-llama/llama-4-maverick:floor) oder stellst in den Account-Einstellungen den Standard-Sortiermodus auf price, laut FAQ der Ankündigung. Wichtig: :floor lässt zusätzlich Flex-Tier-Endpunkte zu, während das einfache sort dies nicht tut, laut OpenRouters Routing-Guide.

Kombiniere das mit einer Obergrenze:

{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }

Das eignet sich für große Prompts, kurze Ausgaben und günstige Retries.

3. Einen stabilen Provider festlegen (Produktion mit Cache oder Tool-Calls)

Lege einen Provider fest, wenn korrekte Ergebnisse, Cache-Treffer oder Compliance wichtiger sind als die Optimierung jedes einzelnen Requests:

{
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true,
    "require_parameters": true
  }
}

require_parameters schließt lediglich Endpunkte aus, denen erforderliche Request-Parameter fehlen. Einheitliches Tool-Call- oder Schema-Verhalten über mehrere Provider hinweg garantiert die Option nicht. Verwende order mit allow_fallbacks: false nur für Compliance- oder BYOK-Fälle, bei denen ein Ausfall besser ist als die Nutzung eines nicht freigegebenen Providers. In den meisten Apps solltest du Fallbacks erlauben, die Auswahl mit only/ignore einschränken und eine stabile session_id für die Wiederverwendung warmer Caches übergeben (Sticky Routing). Wenn ein Provider instabil läuft, blockiere ihn in den Guardrails und vergleiche die APIs der Anbieter direkt. Mehrere Nutzer berichten, dass der direkte Zugriff Probleme mit Langsamkeit und Caching beseitigte, sobald das Modell feststand (Beispiel-Thread).

Das automatische Routing ist besser als zuvor. Es ersetzt trotzdem nicht das Festlegen eines Providers, wenn ein einziger problematischer Wechsel mehr kostet als eine Woche mit leicht höheren Token-Preisen.

FAQ

Muss ich meinen Code ändern, um das neue Routing zu nutzen?

Nein. Requests ohne explizites Provider-sort, order, only oder ignore verwenden automatisch den neuen Router.

Wie behalte ich das reine Preis-Routing?

Setze provider.sort auf "price", hänge :floor an oder stelle den Account-Standard auf price.

Überschreibt das neue Routing meine Provider-Reihenfolge?

Nein. order umgeht den neuen Router. only/ignore filtern zuerst, danach wählt der neue Algorithmus aus.

Wird das neue Routing teurer?

Siehe die Fazit-Tabelle: Im Test lagen die Kosten um 6,0 % pro 1.000 Requests und um 7,3 % pro M Tokens höher.

Wie sehe ich, welcher Provider meinen Request tatsächlich ausgeliefert hat?

Prüfe das Feld provider in der API-Antwort sowie die Activity-Seite, laut OpenRouter-Dokumentation.

Warum bekomme ich trotz bezahltem Account weiterhin 429er?

Die Ursache sind gemeinsame Kapazitätslimits beim Upstream-Provider, nicht dein Kontostand. Lege den betroffenen Provider fest oder schließe ihn aus.