OpenRouter: ein API-Schlüssel vor jedem Modell im Katalog

OpenRouter ist eine gehostete Routing-Schicht für Modell-APIs: ein einziger OpenAI-kompatibler Endpunkt, der jede Anfrage dorthin weiterreicht, wo das gewählte Modell gerade gehostet wird. Das Unternehmen betreibt keine eigenen Modelle, und die Preisseite formuliert es so, dass Inference zum Listenpreis des Anbieters abgerechnet wird, während die Plattformgebühr beim Kauf von Credits anfällt. Die Position dieses Tests: der billigste Weg, einen wechselnden Katalog hinter einem Schlüssel zu versammeln — und die teuerste Abhängigkeit, die man wieder loswird, sobald jeder Dienst diesen Dialekt spricht.

Es besetzt den Platz, den ein selbst gehostetes Gateway besetzen würde, und konkurriert mit LiteLLM, Portkey und der Gewohnheit, jeden Anbieter direkt anzusprechen. Der Unterschied liegt in der Verantwortung, nicht in den Features. Ein Gateway ist ein Prozess, den man ausrollt, patcht und skaliert; OpenRouter ist ein Dienst im Anfrageweg jedes Aufrufs des Produkts — Verfügbarkeit, Datenschutz und Preisgestaltung werden damit zu fremden Problemen. Genau das wird hier gekauft.

Was es ist

Das Unternehmen leitet seit 2023 Traffic und beschreibt das Produkt als einheitliche Schnittstelle für hunderte Modelle. Die dokumentierte Oberfläche ist bewusst klein: ein Endpunkt, ein Schlüssel, ein Modell-Slug und ein paar optionale Routing-Hinweise. Gesundheit der Anbieter, Preisvergleich und Failover passieren auf der anderen Seite dieses Aufrufs.

• Nur gehostet: es gibt keine selbst gehostete Variante, das Produkt ist der Endpunkt https://openrouter.ai/api/v1.
• 500+ Modelle von 80+ Anbietern auf den bezahlten Plänen; der Free-Plan zeigt 25+ kostenlose Modelle von 4 Anbietern.
• OpenAI-kompatible Chat-Completions, dazu eine Anthropic-Messages-Route, eine Responses-API, Embeddings und Batches.
• Modell-Fallbacks über ein models-Array: Das nächste Modell wird versucht, wenn das erste fehlschlägt, rate-limitet wird oder die Moderation ablehnt.
• Anbietersteuerung pro Anfrage — order, only, ignore, Quantisierungsfilter sowie Sortierung nach Preis, Durchsatz oder Latenz.
• Bring-your-own-key-Routing: die ersten 25.000 USD Listenpreis-Inference pro Monat auf einem Anbieterschlüssel ohne OpenRouter-Gebühr.
• Activity-Logs mit Export auf jedem Plan, Aufzeichnung pro Generation und Trace-Export nach Datadog, Grafana Cloud, Langfuse, OpenTelemetry, Snowflake oder ein Webhook.

Wie es funktioniert

Die Standardstrategie ist preisbasiertes Load-Balancing. Der Router verwirft zuerst Anbieter mit einem deutlichen Ausfall der letzten 30 Sekunden, wählt dann unter den stabilen nach dem Kehrwert des Quadrats des Preises und behält den Rest als Fallback: zwischen einem Endpunkt für 1 USD und einem für 3 USD pro Million Tokens wird das billige neunmal häufiger zuerst versucht. Jede explizite sort- oder order-Angabe schaltet dieses Balancing ab — der Schalter, der aus einem kostensoptimierenden Router einen vorhersagbaren macht.

Der Preis des Hops

Jeder Aufruf kreuzt jetzt zwei Netze statt eines. Die FAQ zur Preisseite sagt unverhohlen, dass Routing die Zuverlässigkeit verbessert, die Latenz aber von Modell, Anbieter und Region abhängt, und die Empfehlung für konstante Latenz lautet: Modell und Anbieter pinnen. Der zusätzliche Hop ist neben einer Generierung von Sekunden vernachlässigbar und neben einer Klassifikation unter einer Sekunde nicht: Pinnen liefert das Verhalten einer direkten API plus einer Rundreise.

Die Zwischenschaltung bleibt dort sichtbar, wo es zählt. Die Antwort benennt den Endpunkt, der die Anfrage tatsächlich bedient hat, und ein opt-in Header zeigt die Routing-Entscheidung in jeder Antwort — ein unerwarteter Anbieter taucht in einer Logzeile auf statt in einer Beschwerde.

• sort: price, throughput oder latency, und schaltet dabei das Load-Balancing ab.
• order: eine explizite Anbieterfolge, mit allow_fallbacks false, wenn nichts außerhalb versucht werden darf.
• require_parameters: nur Anbieter, die jeden Parameter der Anfrage unterstützen — strukturierte Outputs und Tool-Aufrufe werden so nicht still abgewertet.
• zdr und data_collection: nur Endpunkte ohne Datenaufbewahrung routen, oder nur Anbieter, die Eingaben nicht speichern.

Erste Schritte

Ein Schlüssel und ein POST. Free-Konten erhalten sofort einen funktionierenden Endpunkt: kostenlose Modelle sind auf 20 Anfragen pro Minute und 50 pro Tag begrenzt, und die Tagesgrenze steigt auf 1.000, sobald das Konto mindestens 10 USD an Credits gekauft hat.

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["~openai/gpt-sol-latest", "~anthropic/claude-sonnet-latest"],
    "messages": [
      { "role": "user", "content": "Summarise this stack trace in one sentence." }
    ],
    "provider": {
      "sort": "price",
      "require_parameters": true
    }
  }'

Die Antwort kommt in OpenAI-Form zurück, und das model-Feld benennt den Endpunkt, der sie tatsächlich geliefert hat. Nach diesem Modell wird die Anfrage auch abgerechnet, unabhängig davon, ob es zuerst in der Liste stand. Ein vorhandener OpenAI-Client braucht nur eine andere Base-URL; die Dokumentation zeigt denselben Tausch in Python und TypeScript.

Preise

Es gibt kein Abo, keine Mindestsumme und kein Lock-in. Credits kauft man vorab per Karte, AliPay oder USDC, und jede Anfrage bucht den Listenpreis vom Saldo ab; die Plattformgebühr — 5,5% bei Standard, 8% bei Business — fällt beim Kauf an, nie bei der Anfrage.

• Free: 25+ kostenlose Modelle, 4 Anbieter, Activity-Logs mit Export, 50 Anfragen pro Tag bei kostenlosen Modellen. Kein Auto-Routing, keine Budgets, kein Prompt-Caching.
• Standard: alle 500+ Modelle und 80+ Anbieter mit 5,5% Gebühr auf Credit-Käufe, dazu Auto-Routing, Budgets, Prompt-Caching, Management-API-Keys und fünf Workspaces.
• Business: derselbe Katalog mit 8%, In-Region-Routing in der EU oder den USA über eu.openrouter.ai und us.openrouter.ai, 1.000 Workspaces und Workload Identity Federation.
• Enterprise: verhandelte Gebühren, Rechnungen, SSO und SCIM, vertragliche SLAs sowie 200.000 USD BYOK-Listenpreis-Inference pro Monat, bevor 5% anfallen.

Steuerungsebene

Für Teams sind die entscheidenden Teile nicht im Request-Body. Workspaces, Budgets und Guardrails legen fest, wer was mit welchem Schlüssel aufrufen darf, und sie liegen in der Plattform statt im eigenen Code. Genau darin besteht der Sinn: Richtlinienänderungen sind keine Deployments mehr.

• Workspaces trennen Umgebungen: fünf bei Free und Standard, 1.000 bei Business, jeweils mit eigenen Schlüsseln und Limits, plus Credit-Cap pro Schlüssel.
• Guardrails hängen an Schlüsseln oder Mitgliedern und decken Ausgaben, Modellzugriff, Prompt-Injection-Muster und Regeln für sensible Informationen ab.
• Management-API-Keys erzeugen, listen und löschen Schlüssel programmatisch — der Schlüssellebenszyklus gehört damit in die CI statt in eine Gewohnheit im Dashboard.
• Broadcast schickt Traces nach Datadog, Grafana Cloud, Langfuse, OpenTelemetry, Sentry, Snowflake oder an einen beliebigen HTTP-Endpunkt, wodurch Ausgaben mit dem Rest des Stacks verknüpfbar werden.

Zero Data Retention läuft auf jedem Plan, kontoweit oder pro Anfrage mit zdr. Regionale Residenz ist das Feature, das nicht gratis ist: Prompts und Antworten in der EU oder den USA bleiben erst ab Business in der Region, damit ist für regulierte Anwendungen der 8%-Plan die Basis statt des Upgrades.

Wo es quietscht

Die Schwächen sind strukturell. Jede Anfrage hängt an der Verfügbarkeit eines Drittanbieters, und die Routing-Entscheidung bleibt unsichtbar, solange der Metadata-Header nicht aktiviert ist. Die Parameterunterstützung unterscheidet sich zwischen Anbietern desselben Modells: ein Aufruf über den einen Endpunkt kann über einen anderen still abgewertet werden, wenn require_parameters fehlt. Anbieterpreisänderungen gehen direkt durch — die FAQ stellt klar, dass zum neuen Satz abgerechnet wird —, und das Free-Angebot ist durch Rate-Limits begrenzt statt großzügig. Dazu die Eigentumsfrage: Bloomberg und der Wall Street Journal berichteten im August 2026, Stripe habe die Übernahme vereinbart — eine Erinnerung daran, dass die Schicht im Anfrageweg einen Eigentümer hat.

Der Vergleich, der zählt, betrifft die Verantwortung, nicht die Features. OpenRouter nimmt den Betrieb ab und fügt eine Prozentzahl plus eine Abhängigkeit hinzu; LiteLLM behält Schlüssel und Last in der eigenen Infrastruktur; die APIs der Anbieter bieten den kürzesten Weg und den geringsten Schutz, wenn ein Modell ausfällt. Für ein Produkt, das so oft das Modell wechselt, wie andere ein Preisseite ändern, ist dieser Schutz mehr wert als die Gebühr.

Fazit

OpenRouter beantwortet, wie viele Agents, Dienste und Teams Zugang zu einem sich schnell ändernden Modellkatalog bekommen, ohne ein Gateway zu betreiben. Es beantwortet nicht, wie man den Anfrageweg besitzt.

1. Nutzen, wenn der Modellkatalog schneller wechselt als die eigene Integration: ein Endpunkt und ein models-Array machen aus einer Anbieterbewertung einen Konfigurationswert.
2. Nutzen für Agent- und Coding-Agent-Lasten, bei denen die Rechnung über viele Modelle geht und ein Activity-Log mit Export mehr bringt als vier Anbieter-Dashboards.
3. BYOK nutzen, wenn Verträge oder Datenschutz eine direkte Beziehung zum Anbieter verlangen; Routing und Analyse bleiben, die ersten 25.000 USD Listenpreis-Inference pro Monat sind gebührenfrei.
4. Verzichten auf latenzkritischen Pfaden, die keinen Anbieter pinnen können: Verfügbarkeits-Routing ist das Produkt, und eine Anfrage, die den Endpunkt wechseln kann, ist eine Tail-Latenz, die niemand kontrolliert.
5. Verzichten, wenn ein Anbieter und ein Modell das ganze Produkt sind: ein SDK des Anbieters, direkte Abrechnung und keine Vermittler-Prozentzahl ist weniger Maschinerie für denselben Aufruf.

„Inference wird auf jedem Plan zum Listenpreis des Anbieters abgerechnet.“ die Preisseite Die Gebühr ist klein und nachvollziehbar; die Abhängigkeit ist der Teil, den man einpreisen muss, und der steht nirgends in der Liste.

Quellen

1. OpenRouter-Dokumentation: Quickstart
2. OpenRouter-Preise
3. OpenRouter-Dokumentation: Modell-Fallbacks
4. OpenRouter-Dokumentation: Provider-Routing
5. OpenRouter-Dokumentationsverzeichnis
6. Wikipedia: OpenRouter