OpenRouter erklärt: Eine API für jedes LLM - und was das für EU-Teams bedeutet

Wer mit großen Sprachmodellen baut, kennt den Schmerz: Jeder Anbieter hat sein eigenes SDK, seine eigene Authentifizierung, seine eigenen Rate Limits, seine eigenen Eigenheiten. Wer von einem Modell auf ein anderes wechseln oder sich gegen einen Ausfall absichern will, schreibt Integrationscode neu. OpenRouter ist eine der populärsten Antworten auf dieses Problem. Doch für ein europäisches Unternehmen sind „in San Francisco beliebt“ und „darf man Kundendaten durchschicken“ zwei sehr verschiedene Fragen.

Dieser Beitrag behandelt beide Hälften. Zuerst, was OpenRouter eigentlich ist und wie es unter der Haube funktioniert. Dann der Teil, der für uns in Europa am meisten zählt: die Konkurrenz, wer EU-basiert und wer US-basiert ist, und was das für DSGVO und Datenresidenz bedeutet.

Eine Anmerkung zu den Quellen. Fast alles über OpenRouters eigenes Verhalten stammt unten aus OpenRouters öffentlicher Dokumentation. Sie ist maßgeblich dafür, was OpenRouter zu tun angibt, ist aber nicht unabhängig geprüft. Selbst-attestierte Aussagen kennzeichnen wir deshalb als solche. Die Angaben zur Konkurrenz stammen größtenteils aus Marketing-Seiten der Anbieter und sollten vertraglich bestätigt werden, bevor du dich darauf verlässt.

Was OpenRouter ist

OpenRouter ist ein einheitliches API-Gateway (manchmal auch Aggregator oder LLM-Router genannt), das zwischen deiner Anwendung und den Modellanbietern sitzt. Statt OpenAI, Anthropic, Google, Mistral, diverse Llama-Hosts und dutzende weitere einzeln zu integrieren, integrierst du OpenRouter einmal und erreichst sie alle über einen einzigen Endpunkt.

Drei Eigenschaften machen es aus:

• Eine Schnittstelle für 400+ Modelle über 60+ Anbieter. Ein Account, ein API-Key, eine Abrechnungsbeziehung erreicht die große Mehrheit der kommerziell verfügbaren Modelle. (Die Zahlen sind OpenRouters eigene und wachsen über die Zeit.)
• Drop-in-Kompatibilität mit OpenAI. OpenRouter implementiert die OpenAI-API-Spezifikation, sodass das offizielle OpenAI-SDK direkt funktioniert. In den meisten Codebasen ist die Umstellung eine Änderung der Basis-URL und des Modellnamens, kein Neuschrieb.
• Eine Routing-Schicht, kein Modell. OpenRouter trainiert nichts Eigenes. Es ist Infrastruktur: Es leitet deine Anfrage an einen Upstream-Anbieter weiter und streamt die Antwort zurück.

Das mentale Modell kennst du bereits von Payment-Gateways oder CDNs: ein einziger Integrationspunkt, der eine fragmentierte Anbieterseite abstrahiert.

Wie es funktioniert

Routing und Load Balancing

Dasselbe Modell wird oft von mehreren Anbietern zu unterschiedlichen Preisen und Zuverlässigkeiten bereitgestellt. Standardmäßig macht OpenRouter preisbasiertes Load Balancing: Zuerst fällt jeder Anbieter heraus, der in den letzten 30 Sekunden einen nennenswerten Ausfall hatte, dann wird unter den übrigen gewichtet nach dem inversen Quadrat des Preises ausgewählt. In OpenRouters eigenem Beispiel wird ein Anbieter mit $1 pro Million Tokens etwa 9× wahrscheinlicher gewählt als einer mit $3 (denn 1/3² = 1/9). Du kannst all das überschreiben: eine Anbieter-Reihenfolge festlegen, eine Preisobergrenze setzen oder stattdessen nach Durchsatz oder Latenz sortieren.

Fallbacks

Hier liegt die eigentliche Stärke in Sachen Zuverlässigkeit. Provider-Failover ist standardmäßig aktiv: Liefert der gewählte Anbieter einen Fehler, versucht OpenRouter transparent dasselbe Modell beim nächsten Anbieter. Darüber hinaus sind Fallbacks auf Modellebene optional: Du kannst eine Kette wie „erst Claude, dann GPT, dann Llama“ definieren, sodass eine einzelne Anfrage sanft degradiert, statt zu scheitern. Du kannst das auch abriegeln (allow_fallbacks: false), um das Routing auf explizit freigegebene Anbieter zu beschränken.

Preise und das Sternchen hinter „kein Aufschlag“

OpenRouters charakteristisches Preisversprechen lautet kein Aufschlag auf die Inferenz: Du zahlst denselben Token-Preis, den du auch direkt beim zugrunde liegenden Anbieter zahlen würdest. Unabhängige Reviews bestätigen, dass die Katalogpreise den veröffentlichten Preisen der Anbieter entsprechen.

Doch „kein Aufschlag“ heißt nicht „keine Gebühren“, und fürs Budget macht das einen echten Unterschied:

• Eine Gebühr von ~5,5 % auf Guthabenkäufe (mit einem Minimum von aktuell rund $0,80) beim Aufladen per Karte.
• Eine ~5 % Krypto-Aufladegebühr als Alternative.
• Eine ~5 % BYOK-Gebühr (siehe unten), wobei die ersten ~1 Million BYOK-Anfragen pro Monat kostenlos sind.

Die Token-Ökonomie ist also tatsächlich Durchleitung; die Plattform verdient an der Geldbewegung und am BYOK-Komfort, nicht an den Tokens. Präsentierst du einem Stakeholder „kein Aufschlag“ ohne diese Gebühren, kalkulierst du zu knapp.

BYOK (Bring Your Own Key)

Du kannst deine eigenen Anbieter-API-Keys hinterlegen (z. B. deinen bestehenden Azure-OpenAI- oder Anthropic-Key). OpenRouter verschlüsselt sie und nutzt sie für Anfragen an diesen Anbieter, sodass die Nutzung auf dein Anbieter-Konto, deine Rate Limits und oft deine verhandelten Preise oder Compliance-Bedingungen geht. Die ~5 % BYOK-Gebühr greift oberhalb des Freikontingents. Eine scharfe Kante: Standardmäßig fällt OpenRouter auf seine geteilten Endpunkte zurück, wenn dein Key scheitert, es sei denn, du setzt explizit „immer meinen Key für diesen Anbieter verwenden“.

Die Vorteile

• Eine Integration, der ganze Markt. Modelle hinzufügen oder tauschen, ohne Integrationscode anzufassen. Das sichert dich gegen Vendor Lock-in und gegen Preis- oder Policy-Änderungen einzelner Anbieter ab.
• Echte Ausfallsicherheit. Anbieterübergreifendes Failover bündelt die Verfügbarkeit vieler Anbieter. Hat ein Host einen Vorfall, läuft dein Traffic weiter.
• Schnelles Experimentieren. Ein neu erschienenes Modell auszuprobieren ist eine einzeilige Änderung. Das ist unbezahlbar in einem Markt, der alle paar Wochen einen neuen Stand der Technik liefert.
• Hebel zur Kostenkontrolle. Preisobergrenzen und preisgewichtetes Routing jagen automatisch dem günstigsten tragfähigen Host hinterher.
• Vernünftige Datenschutz-Defaults. Zero Data Retention der Prompt-Inhalte ist der Standard, kein Upsell (mehr dazu unten).

Die Nachteile

• Eine weitere Abhängigkeit im kritischen Pfad. Ein Gateway, das jedem Modell vorgelagert ist, ist auch ein Single Point of Failure und eine neue Vertrauensgrenze. Seine eigene Verfügbarkeit und Sicherheit begrenzen nun deine.
• „Kein Aufschlag“ hat trotzdem Gebühren. Die Guthaben- und BYOK-Gebühren übersieht man leicht.
• Latenz-Overhead. Ein zusätzlicher Hop kostet Millisekunden. Meist vernachlässigbar, gelegentlich nicht. Auf latenzkritischen Pfaden solltest du messen.
• Heterogenes Anbieterverhalten. Das „gleiche“ Modell kann sich über Upstream-Hosts hinweg unterschiedlich verhalten (Quantisierung, Kontextgrenzen, Feature-Support). Anbieter zu fixieren hilft, bringt aber etwas der Komplexität zurück, der du entgehen wolltest.
• Der große Punkt für uns: Datenresidenz ist standardmäßig nicht EU. Siehe nächster Abschnitt.

Die EU-Frage: DSGVO und Datenresidenz

Hier muss eine europäische Beratung das Tempo drosseln, denn der bequeme Default und die konforme Konfiguration sind nicht dasselbe.

Wo OpenRouter steht

OpenRouter ist ein US-Unternehmen, und der Standard-Endpunkt ist nicht EU-resident. Für ein DSGVO-gebundenes Team ist das der Kern: Standardmäßig können Prompts (die regelmäßig personenbezogene Daten enthalten) auf US-Infrastruktur verarbeitet und an Upstream-Anbieter in diversen Jurisdiktionen geleitet werden.

OpenRouter bietet zwar eine Option für EU-In-Region-Routing über einen dedizierten Endpunkt eu.openrouter.ai. Laut Dokumentation werden Anfragen dort vollständig innerhalb der EU entschlüsselt und verarbeitet und nur an Anbieter geleitet, die in der Region operieren. Zwei wichtige Vorbehalte:

1. Es ist nur für Enterprise, auf Anfrage. Im Free-Account lässt es sich nicht einfach im Dashboard umlegen.
2. Es ist eine Selbstauskunft des Anbieters. In unserer Recherche hielt die stärkste Formulierung „Daten verlassen die EU nie“ einer unabhängigen Prüfung nicht stand. Behandle sie also als dokumentierte Zusage, die im AVV zu bestätigen ist, nicht als geprüfte Tatsache. EU-In-Region-Routing bietet zudem eine kleinere Modellauswahl als der globale Endpunkt.

Welche Datenschutz- und Logging-Kontrollen es gibt

Man muss OpenRouter zugutehalten: Die Datenschutz-Kontrollen sind granular und die Defaults sind vernünftig:

• Zero Data Retention (ZDR) standardmäßig. OpenRouter speichert deine Prompts oder Completions nicht, auch bei Fehlern nicht, es sei denn, du entscheidest dich dafür. Beachte: „Zero Retention“ deckt den Inhalt von Prompt/Completion ab; Metadaten der Anfrage (Token-Zahlen, Latenz, Zeitstempel) werden weiterhin aufbewahrt.
• Kontrollen pro Anfrage und pro Account. Du kannst ZDR-only-Endpunkte erzwingen (zdr: true), nur an Anbieter routen, die keine Daten sammeln (data_collection: "deny"), und ein kontoweites Training-Opt-out setzen, sodass OpenRouter nicht an Anbieter routet, die auf Eingaben trainieren.
• Jeder Upstream behält seine eigene Policy. OpenRouter aggregiert und zeigt die Retention-/Trainingsbedingungen jedes Anbieters, statt eine einzige durchzusetzen. „ZDR“ hängt also davon ab, welcher Anbieter die Anfrage tatsächlich bedient.

Zwei Opt-in-Logging-Mechanismen lassen sich leicht verwechseln, und der Unterschied ist rechtlich bedeutsam:

• Ein Daten-„Rabatt“-Schalter gibt dir ~1 % Nachlass, wenn du OpenRouter erlaubst, deine Prompts/Completions zur Produktverbesserung zu nutzen. Damit räumst du OpenRouter ein unwiderrufliches kommerzielles Nutzungsrecht an diesen Inhalten ein. Für Kundendaten: lass es.
• Ein separates Input & Output Logging erlaubt dir, Anfrage-/Antwortinhalte privat zum eigenen Debugging zu speichern, verschlüsselt at rest, ≥3 Monate aufbewahrt und ausdrücklich nicht fürs Training genutzt. (Dieses gilt nicht für eu.openrouter.ai-Traffic.)

Unterm Strich: OpenRouter lässt sich vertretbar konfigurieren, aber das DSGVO-sichere Setup ist der Enterprise-EU-Endpunkt plus ein Auftragsverarbeitungsvertrag (AVV), benannte Subauftragsverarbeiter sowie SCCs oder Data-Privacy-Framework-Abdeckung für alles, was den US-Default berührt. Das ist ein Beschaffungsgespräch, keine Checkbox.

Die Konkurrenz

OpenRouter ist der bekannteste Router, aber das Feld drumherum ist dicht besetzt. Grob gruppiert:

(Die Einordnungen oben stammen aus den Eigenangaben der Anbieter; prüfe die Details für deinen Anwendungsfall.)

Wer sitzt in der EU, wer in den USA?

• Die meisten reinen Router sind US-Firmen (OpenRouter, Together, Fireworks, Portkey, Vercel, Helicone). Sie lassen sich oft für EU-Regionen konfigurieren, aber EU-Residenz ist nicht ihre Standardhaltung.
• Es gibt eine echte EU-basierte Riege. Eden AI (Frankreich), Orq.ai (Niederlande) und EU-positionierte Router wie Requesty (Frankfurt-Endpunkt), Cortecs und EUrouter machen EU-Datenresidenz und einen DSGVO-AVV zu ihrem Aushängeschild. Wenn „Daten bleiben standardmäßig in Europa“ eine harte Anforderung ist, lohnt sich ein ernsthafter Blick. Allerdings sind ihre Modellkataloge typischerweise kleiner als der von OpenRouter.
• Self-Hosting umgeht die Frage. LiteLLM ist Open Source: Betreibe es in deiner eigenen EU-Cloud, und die Residenz ist dort, wo du deployst. Du tauschst Komfort gegen Kontrolle.
• Die Hyperscaler bieten die stärkste vertragliche Story. AWS Bedrock, Azure OpenAI und Google Vertex AI laufen alle in EU-Regionen mit Enterprise-AVVs. Bemerkenswert: AWS Bedrocks EU-Cross-Region-Inference-Profile garantieren, dass Anfragen aus einer EU-Region nur an andere EU-Regionen geleitet werden, also Residenz per Design statt per Konfiguration. Der Kompromiss ist eine engere Modellauswahl und mehr Einrichtungsaufwand, als ein Router ihn verlangt. Und es bleiben eben doch US-Unternehmen.

Wie wir bei vensas darüber denken

Eine einzige richtige Antwort gibt es nicht. Es kommt darauf an, ob das Risiko der Arbeitslast zur Haltung des Gateways passt. So rahmen wir es für Kunden:

• Prototypen, interne Tools, keine personenbezogenen Daten: OpenRouters Standard-Endpunkt ist schwer zu schlagen bei Geschwindigkeit und Breite. Genieße die Optionalität.
• Produktion mit personenbezogenen oder Kundendaten: Der Standard-Endpunkt ist vom Tisch. Wähle zwischen OpenRouters Enterprise-EU-Endpunkt, einem EU-basierten Gateway (Eden AI, Orq.ai, Requesty u. a.), einem self-hosted LiteLLM in deiner eigenen EU-Cloud oder einer Hyperscaler-EU-Region. Untermauere die Wahl mit einem AVV und einer dokumentierten Subauftragsverarbeiter-Liste.
• Trenne immer die beiden Fragen. „Welches Modell ist das beste?“ und „Wohin dürfen die Daten?“ sind unabhängig. Ein Gateway ist genau die Schicht, die dir erlaubt, die Antwort auf die erste Frage zu ändern, ohne die zweite neu zu verhandeln.

Der tiefste Wert eines Routers sind nicht günstigere Tokens, sondern Optionalität. In einem so volatilen Markt ist die Fähigkeit, Modelle und Anbieter ohne Neuschrieb zu tauschen, strategisch. Achte nur darauf, dass die Schicht, die du für Flexibilität gekauft hast, nicht klammheimlich zur Schicht wird, die personenbezogene Daten über den Atlantik schickt.