OpenRouter BYOK: Gebühren, Fallbacks und Key-Rotation (2026)

Ein OpenAI-Key kann korrekt eingerichtet sein, die Anfrage kann erfolgreich durchlaufen – und trotzdem sinkt dein OpenRouter-Guthaben. Denn BYOK bei OpenRouter ist kein einzelner Abrechnungsschalter: Providerkosten, Plattformgebühren und Fallback-Kapazitäten werden unterschiedlich abgerechnet. Außerdem gilt inzwischen eine Regel, die die frühere Antwort mit einer Million Anfragen abgelöst hat.

Als Erstes klären: Welche Belastung siehst du?

Mit OpenRouter BYOK nutzt eine Anfrage die in deinem Workspace hinterlegte Provider-Zugangsdaten, während OpenRouter API- und Routing-Schicht bleibt. Daraus ergeben sich drei voneinander getrennte Kostenpfade:

Die wichtigste Diagnosefrage lautet daher nicht: „Habe ich meinen Key hinterlegt?“ Sondern: „Welcher Provider hat diese Anfrage tatsächlich bedient?“ Ein konfigurierter Key kann an Rate Limits, fehlendem Upstream-Guthaben, Berechtigungen oder einem temporären Provider-Ausfall scheitern. Ist Fallback aktiviert, kann OpenRouter die Anfrage über einen anderen Provider abschließen und dafür dein OpenRouter-Guthaben belasten – wie die Support-Erklärung zu BYOK-Kosten beschreibt.

Was sich mit OpenRouter BYOK ändert – und was nicht

BYOK leitet berechtigten Traffic über deine Provider-Zugangsdaten, behält aber OpenRouter als API- und Routing-Schicht bei. Laut der BYOK-Dokumentation werden die Zugangsdaten verschlüsselt gespeichert und nur für Anfragen genutzt, die über den angegebenen Provider geroutet werden.

BYOK macht Inferenz nicht kostenlos: Der Provider rechnet die Modellnutzung weiterhin ab, und OpenRouter kann nach der jeweils geltenden Freigrenze zusätzlich eine Plattformgebühr berechnen. Ein eigener Key umgeht auch keine Datenschutzregeln auf Workspace-, Konto- oder Anfrageebene. Bleibt kein zulässiger Endpoint übrig, schlägt die Anfrage fehl – selbst wenn die Zugangsdaten gültig sind.

Die aktuelle BYOK-Gebühr richtet sich nach Inferenzwert, nicht nach Anfragen

Die aktuelle OpenRouter-Preisseite definiert die gebührenfreie BYOK-Freigrenze über den Listenpreiswert der Inferenz, nicht über die Zahl der Anfragen:

Für die Freigrenze zählt, was dasselbe Modell beim selben Provider auf OpenRouter regulär kosten würde – nicht zwingend der Preis auf deiner individuell ausgehandelten Provider-Rechnung. Nach Verbrauch der Freigrenze zieht OpenRouter die 5% BYOK-Gebühr von den OpenRouter-Credits ab; die Provider-Abrechnung bleibt davon getrennt.

Drei Kostenarten, die getrennt betrachtet werden sollten

1. Provider-Inferenzkosten: Der Provider rechnet mit dem Konto ab, das hinter den BYOK-Zugangsdaten steht.
2. BYOK-Plattformgebühr: Nach der aktuellen tarifabhängigen Freigrenze berechnet OpenRouter 5% und zieht diese von OpenRouter-Credits ab.
3. Fallback-Inferenzkosten: OpenRouter-Credits finanzieren eine Route über Provider-Kapazität von OpenRouter statt über den vorgesehenen BYOK-Pfad.

Davon getrennt sind Gebühren beim Kauf von Credits: Laut OpenRouter-Preisseite beträgt die Pay-as-you-go-Plattformgebühr 5.5%. Eine Aufladung belegt nicht, dass eine bestimmte Anfrage über Fallback lief.

Warum die alte Antwort mit 1 Mio. Anfragen noch in der Suche auftaucht

In einer Ankündigung vom Oktober 2025 nannte OpenRouter eine Million gebührenfreie BYOK-Anfragen pro Monat und anschließend 5% Gebühr. Diese Regel war die damalige Richtlinie in der datierten Ankündigung; auf der Seite steht inzwischen, dass sich die BYOK-Preise im August 2026 geändert haben. Für Kalkulationen solltest du die aktuelle Freigrenze auf Basis des Listenpreis-Inferenzwerts verwenden und das Abrufdatum dokumentieren.

Fallback entscheidet, ob BYOK eine harte Grenze bleibt

OpenRouter priorisiert standardmäßig erfolgreiche Anfragen. Der BYOK-Leitfaden beschreibt priorisierte Keys, gemeinsam genutzte OpenRouter-Endpoints und Fallback-Keys als unterschiedliche Stationen im Routing:

• Priorisierte BYOK-Keys werden in der festgelegten Reihenfolge versucht.
• Scheitern diese Versuche, kann OpenRouter gemeinsame Kapazität nutzen.
• Als Fallback markierte BYOK-Keys werden erst nach den gemeinsamen Endpoints versucht.
• Mehrere passende Keys für denselben Provider können nacheinander getestet werden.

Die Provider-Reihenfolge bringt eine weitere Besonderheit mit: Passende BYOK-Endpoints werden vor gemeinsamen Endpoints versucht, selbst wenn der Provider in deinem gewünschten order-Array weiter hinten steht. Eine Anfrage kann also früher einen BYOK-Key verwenden, als es deine allgemeine Provider-Reihenfolge erwarten lässt.

Verfügbarkeit oder planbare Abrechnung?

Die Dashboard-Option Always use for this provider verhindert, dass OpenRouter für denselben Provider seine eigenen gemeinsamen Zugangsdaten einsetzt. Sie ist jedoch kein globaler Schalter nach dem Motto „Niemals OpenRouter-Credits verwenden“. Laut dem Support-Artikel kann eine Anfrage dennoch von einem Anthropic-BYOK-Key zu einem anderen kompatiblen Provider wie Google Vertex wechseln, wenn providerübergreifender Fallback weiterhin möglich ist.

Wenn dir Abrechnungssicherheit wichtiger ist, beschränke die Anfrage selbst:

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

Mit provider.only wird ein Anthropic-Fehler zum API-Fehler, statt die Anfrage unbemerkt an einen anderen Provider weiterzuleiten. Das ist die passende Wahl für regulierte Workloads, providerspezifische Datenvereinbarungen oder Kostenberichte, bei denen jede Anfrage eindeutig einem Upstream-Konto zugeordnet werden muss. Für ein interaktives Produkt, bei dem Verfügbarkeit wichtiger ist als eine strikte Provider-Zuordnung, ist es dagegen ein schlechter Standard.

Ein Nutzer in r/openrouter beschrieb genau diese Steuerungsmöglichkeit:

„Du kannst in der Anfrage selbst Provider über order/only festlegen, damit ausschließlich deine BYOK-Provider verwendet werden.“ — u/Randomdotmath, Reddit thread

Gehört Fallback zu deinem Verfügbarkeitskonzept, solltest du dafür Budget einplanen. Gehört er nicht dazu, deaktiviere ihn an der Anfragegrenze.

Erst Activity prüfen, dann der Gebühr die Schuld geben

Laut der OpenRouter-FAQ zeigt Activity den Nutzungsverlauf und lässt sich nach Modell, Provider und API-Key filtern. Prüfe dabei:

1. Serving Provider: Entspricht er dem Provider deiner BYOK-Zugangsdaten?
2. Modell und Endpoint: Hat der Router einen anderen kompatiblen Endpoint gewählt?
3. API-Key der Anwendung: Welcher Key aus welcher Umgebung oder welchem Workspace hat die Anfrage ausgelöst?
4. Credit-Abzug: Handelt es sich um Inferenzkosten, eine BYOK-Gebühr oder eine auf eine Aufladung bezogene Kontobewegung?

Weicht der in Activity angezeigte Provider vom BYOK-Provider ab, untersuche zuerst den Fallback, bevor du Zugangsdaten änderst. Stimmen die Provider überein und liegt das Volumen nahe der Tarif-Freigrenze, ist die BYOK-Plattformgebühr der wahrscheinlichere Ansatzpunkt. So rotierst du keinen gültigen Key, um ein Routing-Problem zu lösen.

Ein produktionsreifes Key-Setup für sichere Rotation

Behandle den OpenRouter-Anwendungs-Key und die Upstream-BYOK-Zugangsdaten als getrennte Secrets mit unterschiedlichen Verantwortlichkeiten:

BYOK-Zugangsdaten einrichten und testen

Dieser kurze Ablauf sollte vor der Fehlersuche im Produktivtraffic stehen:

1. Füge die Provider-Zugangsdaten in den BYOK-Einstellungen des Workspace hinzu oder erstelle sie über die BYOK Management API.
2. Vergib einen Namen, der Provider, Umgebung und Zweck erkennen lässt.
3. Setze Filter für Modell, OpenRouter API-Key oder Mitglieder, bevor du die Workspace-Zugangsdaten teilst.
4. Platziere den Key im priorisierten Bereich; füge einen Fallback-Key nur hinzu, wenn seine Rolle für Abrechnung und Ausfälle eindeutig definiert ist.
5. Sende eine Testanfrage, prüfe den Serving Provider in Activity und entscheide anschließend, ob gemeinsamer Fallback aktiviert bleiben soll.

Bei Cloud-Providern sind Zugangsdaten nicht beliebig austauschbar:

Diese Vorgaben stammen aus der providerspezifischen BYOK-Dokumentation von OpenRouter. Ein gültiges Secret mit falschem Ressourcentyp, falscher Region, fehlendem Deployment oder unzureichenden Berechtigungen ist ein Konfigurationsfehler – kein Beleg dafür, dass BYOK nicht unterstützt wird.

Die BYOK-Einstellungen von OpenRouter unterstützen Filter für Model Slugs, OpenRouter-API-Key-Hashes und Workspace-Mitglieder. Jeder aktive Filter muss passen, damit Zugangsdaten berechtigt sind; die Dokumentation erlaubt bis zu 100 Einträge pro Filter. Nutze explizite Allowlists und teile große Teams besser auf mehrere Workspaces auf, statt einen einzelnen Credential-Satz immer weiter zu öffnen.

OpenRouter Application Key rotieren, ohne Provider-Keys anzutasten

Das Cookbook zur API-Key-Rotation von OpenRouter beschreibt BYOK-Provider-Zugangsdaten als dem OpenRouter-Konto zugeordnet, nicht einem bestimmten Application Key. Für eine Rotation ohne Ausfallzeit empfiehlt sich diese Reihenfolge:

1. Erstelle einen Ersatz-OpenRouter-Application-Key mit aussagekräftigem Namen und passendem Limit.
2. Lege ihn im Secret Manager ab und rolle ihn an alle Services, Jobs und Umgebungen aus, die den alten Key verwenden.
3. Bestätige in Activity, dass der Produktivtraffic den Ersatz-Key nutzt.
4. Lösche den alten Key erst, wenn die Migration vollständig abgeschlossen ist.

Die Dokumentation zu Management API Keys stellt klar, dass diese administrative Zugangsdaten sind und keine Completion-Endpoints aufrufen können. Der Ersatz-Key muss verfügbar sein, bevor der alte Application Key widerrufen wird.

Provider-Zugangsdaten separat rotieren

Die Rotation eines Provider-Keys ist eine eigenständige Änderung. Folge der Credential-Richtlinie des jeweiligen Providers und teste exakt das Modell, die Region, die Berechtigungen und die Quota, die der Workload verwendet.

1. Erstelle beim Provider Ersatz-Zugangsdaten mit den minimal erforderlichen Berechtigungen.
2. Füge sie der OpenRouter-BYOK-Verbindung mit eigenem Namen und kontrollierter Priorität hinzu.
3. Sende eine Testanfrage und prüfe Activity.
4. Verschiebe den Ersatz in die primäre Position und beobachte Fehler sowie die Provider-Nutzung.
5. Widerrufe die alten Zugangsdaten beim Provider nach dem Überschneidungszeitraum.

Diese Reihenfolge ist eine operative Empfehlung auf Basis des dokumentierten Prioritätsverhaltens von OpenRouter; die Widerrufsregeln des Providers bleiben maßgeblich. Die BYOK Create API von OpenRouter akzeptiert einen unverschlüsselten Credential-Wert, speichert ihn laut Dokumentation jedoch verschlüsselt und gibt ihn in späteren API-Antworten nicht zurück. Bewahre das ursprüngliche Credential deshalb in deinem eigenen Secret Manager auf: OpenRouter ist keine Wiederherstellungskopie.

Wann OpenRouter BYOK nicht die beste Voreinstellung ist

Direkter Provider-Zugriff ist die bessere Standardwahl, wenn die nativen Logs eines Providers, exaktes Endpoint-Verhalten oder die Tooling-Landschaft des Anbieters wichtiger sind als ein einheitliches Routing. BYOK passt besser zu mehreren Providerkonten, vorhandenen Provider-Credits oder zugesicherter Kapazität sowie Kontrollen auf Workspace-Ebene.

FAQ zu OpenRouter BYOK

Berechnet OpenRouter trotz eigenem Key Gebühren?

Ja. Der Provider kann die Inferenz über die BYOK-Zugangsdaten abrechnen. Nach der aktuellen tarifabhängigen Freigrenze kann OpenRouter eine BYOK-Plattformgebühr von 5% von deinen Credits abziehen. Und bei einem Fallback können OpenRouter-Credits für eine Route über einen anderen Provider eingesetzt werden.

Stoppt „Always use for this provider“ jeden Fallback?

Nein. Die Option verhindert nur, dass OpenRouter für den benannten Provider seine eigenen gemeinsamen Zugangsdaten verwendet. Ein Wechsel zu einem anderen kompatiblen Provider bleibt möglich. Nutze provider.only, wenn dieser providerübergreifende Pfad ausgeschlossen sein muss.

Wie sollten Unternehmen BYOK-Sicherheit und Budgets handhaben?

OpenRouter gibt an, dass Zugangsdaten verschlüsselt sind, rohe Provider-Keys nicht über die Management API zurückgegeben werden und BYOK-Ausgaben standardmäßig nicht in Guardrail- und Workspace-Budgets einfließen. Laut der BYOK-Dokumentation musst du Include BYOK spend oder include_byok_in_budgets aktivieren, wenn ein gemeinsames Budget erforderlich ist. Enterprise-Teams sollten zusätzlich Least-Privilege-Zugangsdaten, getrennte Workspaces, Filter, Verwahrung im Secret Manager, Rotation und regelmäßige Activity-Prüfungen einsetzen.

Die richtige Standardkonfiguration richtet sich nach dem Fehler, den du akzeptieren kannst

Wähle Routing- und Budgetkontrollen danach aus, ob erfolgreiche Anfragen, Provider-Zuordnung oder Kostentransparenz die Anforderung ist, bei der du keine Kompromisse machen kannst.