OpenRouter: eine API für 400+ Modelle und 60+ Anbieter

Was OpenRouter tatsächlich zusammenführt

Ich würde OpenRouter nicht als Neuigkeit bezeichnen: Im August 2026 ist es bereits eine etablierte Schicht zwischen Anwendung und Modellanbietern. Der praktische Nutzen ist einfach: ein API-Schlüssel, ein gemeinsames Anfrageformat und ein einheitliches Guthaben statt separater Integrationen mit OpenAI, Google, Anthropic und anderen Anbietern.

In aktuellen Beschreibungen des Dienstes ist von über 400 Modellen von mehr als 60 Anbietern die Rede. Diese Zahlen sollte man als Momentaufnahme des Katalogs und nicht als vertragliche Zusage verstehen: Modelle, Anbieter und Verfügbarkeit ändern sich laufend. Aus Engineering-Sicht ist wichtiger, dass eine Anwendung ein Modell wählen kann, ohne die gesamte Integration umzuschreiben.

Routing kann mehr als Modelle manuell umzuschalten. In der OpenRouter-Dokumentation zu Fallback-Routen wird ein Modell-Array beschrieben: Ist die primäre Option nicht verfügbar, rate-limitiert oder blockiert eine Anfrage durch Moderation, versucht das System die nächste. Schlägt auch der Fallback fehl, erhält der Client einen Fehler. Das ist Ausfallsicherheit, keine grenzenlose Magie.

Bei der Bezahlung lohnt sich der Blick ins Kleingedruckte. Die Preisseite von OpenRouter nennt einen kostenlosen Plan ohne Plattformgebühr, während die Gebührenankündigung für normale Aufladungen 5,5 % mit mindestens $0,80 ausweist. Für Kryptozahlungen werden 5 % ohne Mindestbetrag genannt.

Der Mindestbetrag fällt besonders bei kleinen Zahlungen auf: Bei einer Aufladung von $5 werden aus $0,80 Gebühr effektiv 16 %. Das ist nicht mehr „nur fünfeinhalb Prozent“, sondern ein spürbarer Preis für den Komfort.

Wo eine einheitliche API die Lage wirklich verändert

Der größte Gewinn liegt nicht in der Modellzahl, sondern in einer geringeren Kopplung der Anwendung an eine konkrete API. Komplexe und einfache Aufgaben lassen sich verschiedenen Modellen zuweisen, Routen bei Störungen ändern und Ausgaben zentral einsehen.

Die Bindung verschwindet jedoch nicht, sie verlagert sich eine Ebene höher. Statt von einem Modellanbieter hängt man vom Router, dessen Verfügbarkeit, Zahlungsrichtlinien und Auswahlmechanismus ab. Deshalb würde ich zuerst Latenz, Wiederholungsversuche, Fehlerbehandlung, das tatsächlich gewählte Modell sowie die Differenz zwischen erwarteten und endgültigen Kosten prüfen.

Im großen Maßstab bietet ein eigener Proxy wie LiteLLM oder lm-proxy mehr Kontrolle über Schlüssel, Budgets und Routingregeln, muss aber betrieben werden. Ein direkter Anbieter wie Deepinfra kann für eine kleine Modellauswahl einfacher sein. OpenRouter ist dort stark, wo schnelle Anbindung und breite Auswahl wichtiger sind als vollständige Kontrolle.

Das ist keine Abschaffung des Vendor Lock-in, sondern ein Tausch einer Abhängigkeit gegen eine andere, bequemere und besser beobachtbare. Die tatsächliche Qualität einer solchen Schicht zeigt sich nicht an der Zahl der Logos im Katalog, sondern daran, wie vorhersehbar sie sich bei einem Ausfall verhält.

Wir haben bereits erläutert, wie LLM-Proxys und Abstraktionsschichten den Vendor Lock-in bei der Arbeit mit verschiedenen Modellanbietern verringern können. Das ergänzt den Ansatz von OpenRouter direkt: Routing wird Teil der Architektur statt einer Bindung an eine einzelne API.