OpenRouter startet Private Endpoints für feinabgestimmte Modelle und reservierte Kapazitäten

Eine API für öffentliche und private Deployments

OpenRouter bietet die öffentlichen Modelle, die ein Team nutzt, bereits hinter einer einzigen API an. Private Endpoints erweitert dies laut Unternehmen auf Deployments, auf die nur ein bestimmtes Team Zugriff hat: ein feinabgestimmtes Modell, ein dediziertes Deployment eines öffentlichen Modells oder bei einem Provider reservierte Kapazität.

Bislang bedeuteten feinabgestimmte Modelle und reservierte Kapazitäten nach Angaben von OpenRouter eine zweite Integration neben OpenRouter. Mit der neuen Funktion registriert eine Organisation das Deployment als privaten Endpunkt und ruft es über die bestehende API auf, wobei Modell-Slug und Routing-Präferenzen erhalten bleiben. Öffentliche Anbieter können optional als Backup dienen, falls das private Deployment ausfällt oder sein Ratenlimit erreicht.

Einen privaten Endpunkt sehen nur Organisationen, die der Kunde freigibt. Er taucht nie in öffentlichen Modelllisten, Rankings, der Suche, Diagrammen oder Benchmarks auf.

OpenRouter nennt ein Beispiel: Eine Organisation mit einem dedizierten Azure-Deployment von DeepSeek V4 Pro kann es für deepseek/deepseek-v4-pro registrieren, und ihre Apps rufen weiterhin diesen Slug auf. Für diese Organisation rückt der Endpunkt standardmäßig an die erste Stelle der Provider-Liste, während Model Fallbacks, Provider Selection und das übrige Routing wie bei jedem anderen Provider funktionieren. OpenRouter erreicht das Deployment über BYOK mit dem Azure-Schlüssel des Kunden, sodass Azure dem Kunden direkt Rechnung stellt.

Reservierte Kapazitäten werden genauso behandelt. Der Traffic der Organisation geht standardmäßig zuerst an den privaten Endpunkt. Ist dieser ratenlimitiert oder nicht verfügbar, kann OpenRouter den Überlauf an öffentliche Anbieter weiterleiten, und zwar im Rahmen der vom Kunden festgelegten Provider-Präferenzen und BYOK-Fallback-Einstellungen.

Einrichtung, Test und API

Sobald die Funktion aktiviert ist, registriert ein Organisationsadmin das Deployment auf der Seite „Private Endpoints“ im Konto. Dabei gelten zwei Voraussetzungen. Das Deployment muss bei einem Provider gehostet sein, der für BYOK unterstützt wird, da OpenRouter den eigenen Schlüssel des Kunden verwendet. Außerdem muss es ein Modell bereitstellen, das bereits im OpenRouter-Katalog steht, weil der Endpunkt Slug und Fähigkeiten dieses Modells übernimmt.

Admins können eigene Preise hinterlegen, damit der Endpunkt im Kostenreporting korrekt erscheint, und sie geben an, ob das Deployment Prompts speichert.

Bevor Traffic geroutet wird, sendet OpenRouter eine echte Anfrage über den Provider-Schlüssel, der in einem der Workspaces der Organisation hinterlegt ist. Laut Unternehmen wird dabei bestätigt, dass:

• der Schlüssel akzeptiert wird
• das Deployment das OpenAI-kompatible Format spricht
• Streaming funktioniert
• die Nutzungsdaten für die Abrechnung zurückkommen
• die Modell-ID mit der registrierten übereinstimmt

Nach bestandenem Test aktiviert der Admin den Endpunkt, und Workspaces der Organisation können ihn über den Modell-Slug aufrufen. Bis dahin bleibt er verborgen und kann nicht aufgerufen werden.

Teams mit vielen Endpunkten oder als Code verwalteter Infrastruktur können stattdessen die Private Endpoints API nutzen. Sie deckt den gesamten Lebenszyklus ab: Entwurf registrieren, Testprüfungen ausführen, aktivieren, Preise aktualisieren, pausieren und löschen. Die Authentifizierung erfolgt mit dem Management-API-Schlüssel der Organisation, und ein einziger Create-Aufruf registriert, testet und aktiviert einen Endpunkt. Schlagen die Prüfungen fehl, bleibt der Entwurf erhalten und wird zusammen mit den fehlgeschlagenen Prüfungen zurückgegeben, sodass er angepasst und erneut versucht werden kann. Ein Idempotency-Key-Header macht Wiederholungen sicher, denn ein erneut verwendeter Schlüssel liefert den Endpunkt zurück, der durch die erste Anfrage erstellt wurde. Der OpenRouter-Terraform-Provider bündelt dies in einer Ressource namens openrouter_private_endpoint: terraform apply registriert, testet und aktiviert einen Endpunkt, terraform destroy entfernt ihn.

Datenverarbeitung, Limits und Verfügbarkeit

OpenRouter betont, dass ein als privat markierter Endpunkt nicht automatisch ein Zero-Data-Retention-Endpunkt ist. Der Provider verarbeitet Prompts genau wie bisher, und OpenRouter hält die Datenrichtlinie fest, die der Kunde bei der Registrierung angibt.

Ein privater Endpunkt kann In-Region Routing nutzen, wenn OpenRouter aus seiner Adresse eine Region ableiten kann oder wenn bei der Einrichtung eine angegeben wird. Anfragen an us.openrouter.ai oder eu.openrouter.ai werden dann innerhalb dieser Region an das Deployment geleitet. Die unterstützten Provider sind im Leitfaden zu In-Region Routing aufgeführt.

Der Provider-Schlüssel muss in jedem Workspace, der den Endpunkt aufruft, unter BYOK hinterlegt sein, und auch die Testanfrage bei der Einrichtung benötigt ihn dort. Standardmäßig kann jede Organisation bis zu 10 private Endpunkte haben, wobei Endpunkte, die noch eingerichtet werden, auf dieses Limit angerechnet werden.

Was das für Enterprise-Kunden bedeutet

Für Organisationen, die bereits feinabgestimmte Modelle oder reservierte Kapazitäten betreiben, entfällt damit die separate Integration neben OpenRouter. Teams können eine API, einen Satz Slugs und ihre bestehenden Routing-Regeln behalten, mit öffentlichen Anbietern als Sicherheitsnetz.

Private Endpoints ist als Add-on zum Enterprise-Tarif erhältlich. Kunden müssen die Aktivierung bei ihrem Ansprechpartner anfragen. Danach kann ein Organisationsadmin den ersten Endpunkt über die Seite „Private Endpoints“ oder über die Private Endpoints API mit einem Management-API-Schlüssel anlegen.