OpenRouter baut Anbieter-Routing um: Tempo und Zuverlässigkeit zählen, nicht nur der Preis

Warum reines Preis-Routing nicht genügte

Laut OpenRouter geht rund 77 % der Anfragen auf der Plattform an Modelle, die von mehr als einem Anbieter bereitgestellt werden. Enthält eine Anfrage weder eine explizite Sortierung noch eine Anbieterliste, muss der Router einen Anbieter auswählen. Bisher geschah das fast ausschließlich anhand des Preises für Eingabe-Tokens: Je günstiger ein Anbieter, desto größer sein Anteil am Traffic, und fehlgeschlagene Anfragen gingen an die nächstgünstigere Option.

Das Unternehmen erklärt, dass dies zwar die niedrigsten Preise im gesamten Ökosystem lieferte, aber Probleme verursachte. Günstige Anbieter setzten sich auch bei schlechtem Service durch, und Nutzer warteten auf Fallbacks. Die Rangfolgen waren statisch, ein Anbieter musste sich also stark verschlechtern, bevor der Traffic abwanderte. Anbieter konnten nur über Preissenkungen konkurrieren, was ihre Investitionen in Zuverlässigkeit unter Druck setzte. Außerdem ließ sich das System austricksen: Ein Anbieter konnte einen künstlich niedrigen Eingabepreis ausweisen und die Differenz über überteuerte Cache- oder Completion-Tokens wieder hereinholen.

So funktioniert die Routing Cost

Der neue Algorithmus überwacht jeden Anbieter fortlaufend und berechnet in Echtzeit eine Routing Cost. Sie umfasst den tatsächlichen Preis, die Kosten des Wartens auf eine Antwort und die Kosten für Wiederholungsversuche, wenn ein Anbieter ausfällt oder eine unbrauchbare Antwort liefert. OpenRouter fasst das in zwei Fragen: Was kostet ein Versuch, und wie oft funktioniert er?

• Effektiver Preis: berechnet aus dem zuletzt gemessenen Traffic, einschließlich der realen Cache-Trefferquote des Anbieters und des durchschnittlichen Mixes aus Eingabe- und Ausgabe-Tokens des Modells. Er kann stark vom Listenpreis abweichen.
• Durchsatz: gemessen in Ausgabe-Tokens pro Sekunde, Ende zu Ende. Ein schnellerer Anbieter kann mehr verlangen und trotzdem eine Anfrage gewinnen. Die Wartezeit wird mit einem pro Modell festgelegten Satz in Kosten umgerechnet.
• Time to first token: wird gesondert erfasst, weil interaktive Nutzung, etwa Agentensitzungen mit vielen aufeinanderfolgenden Tool-Aufrufen, am stärksten davon abhängt.
• Rate Limits: HTTP-429-Antworten schlagen mit der Wartezeit plus einem Aufschlag zu Buche, gewichtet danach, wie oft ein Anbieter limitiert.
• Zuverlässigkeit und Qualität: Auch ein fehlgeschlagener Versuch kostet Preis und Wartezeit, deshalb berechnet der Router die erwarteten Kosten, bis ein Versuch gelingt. Scheitert jeder fünfte Versuch, zahlt man 1,25 Versuche pro brauchbarer Antwort.

Bei der Qualität prüft das System derzeit vor allem, ob Tool-Aufrufe wohlgeformt zurückkommen; weitere Prüfungen sollen laut OpenRouter folgen. Ein Anbieter, der wegen fehlerhafter Tool-Aufrufe oder einer Benchmark-Genauigkeit deutlich unter dem erwartbaren Wert des Modells markiert wird, fällt weit zurück und erhält nur noch wenig Testtraffic, bis die Markierung aufgehoben wird.

Traffic-Verteilung und Leitplanken

Würde man alles an den einen besten Anbieter schicken, wäre dieser überlastet, deshalb wird der Traffic verteilt. Anbieter innerhalb eines Wettbewerbskorridors teilen sich den Großteil des Traffics, und ein kleiner Rückstand auf den Besten kostet nur wenig. Jenseits dieses Korridors fällt der Anteil schnell ab.

Es gelten drei Leitplanken. Eine Untergrenze gibt jedem Anbieter einen Mindestanteil an Traffic, damit Verbesserungen auffallen können; neue Endpunkte starten mit den typischen Werten des Modells. Ein Back-off reduziert den Traffic für Anbieter, die ausfallen oder Rate Limits auslösen. Eine Obergrenze spiegelt wider, wie viel Last ein Anbieter tragen kann, bevor er 429-Fehler zurückgibt; der Rest läuft zu anderen. Laut OpenRouter steigt die Obergrenze automatisch, wenn Kapazität hinzukommt.

Gemeldete Ergebnisse und was gleich bleibt

OpenRouter meldet Verbesserungen bei der TTFT (16,9 %), beim Durchsatz (16,3 %) und bei Kapazitätsfehlern (67 % weniger), bei nur geringfügig höheren Kosten (6,0 %). Das geschehe, bevor die Anbieter Zeit hatten, sich auf den neuen Algorithmus einzustellen.

Manches bleibt unverändert. Anfragen mit provider.order umgehen die neue Logik und folgen der angegebenen Reihenfolge, wobei preisbasiert der Standard ist. Wer provider.only oder provider.ignore setzt, bekommt den neuen Algorithmus auf die verbleibenden Anbieter angewendet, sofern mehr als einer übrig ist. Eine explizite provider.sort nach Preis, Durchsatz oder Latenz verwendet stattdessen diese Sortierung. Nur die erste Anfrage einer Konversation wird algorithmisch geroutet; die Konversation bleibt an diesen Anbieter gebunden, damit der Prompt-Cache warm bleibt, und weicht automatisch aus, falls der Anbieter nicht mehr verfügbar ist. Ein fehlgeschlagener Versuch wird beim nächstbestplatzierten Anbieter wiederholt.

Für Nutzer sind laut Unternehmen keine Code-Änderungen nötig, und reines Preis-Routing bleibt über Pinning und Sortierung weiterhin möglich. Für Anbieter verschiebt sich der Anreiz vom Unterbieten beim Preis hin zu schnellerer und zuverlässigerer Inferenz.