Ein einzelner HTTP-Endpunkt nimmt einen Chat-Completion-Request entgegen, prüft das Budget des anfragenden Schlüssels, wählt einen Modellanbieter und schreibt Tokenzahl und Kosten in eine eigene Datenbank. Dieses Muster beschreibt das Repository mozilla-ai/otari, ein Gateway unter Apache-2.0, das sich selbst betreiben lässt und nach außen wie die OpenAI-API aussieht. Der Gedanke ist alt, aber wieder relevant: Die Zahl der Modellanbieter im eigenen Stack wächst schneller als die Zahl der Anwendungen, die sie nutzen.
Wer das einmal aufgeräumt hat, will selten zurück. Man kann sich die Telefonzentrale eines größeren Bürogebäudes vorstellen: Nach außen gibt es eine Nummer, intern hängen Dutzende Nebenstellen daran, und die Zentrale führt Buch darüber, wer wie lange telefoniert hat. Diese Rolle übernimmt ein LLM-Gateway zwischen deinen Anwendungen und den Anbietern. Otari ist ein solches Gateway und lässt sich vollständig in eigener Infrastruktur betreiben.
Ein Endpunkt statt vierzig SDKs: was OpenAI-kompatibel praktisch bedeutet
OpenAI-kompatibel heißt zunächst nur: Das Gateway spricht dasselbe Protokoll wie die OpenAI-API, also dieselben Pfade, dieselben Feldnamen, dieselben Antwortstrukturen. Für dich heißt das: Die Anwendung wechselt ihren Client nicht. Du änderst die Basis-URL und den Schlüssel, alles andere bleibt. Bibliotheken, die für OpenAI geschrieben wurden, funktionieren unverändert weiter. Das spart Umbauarbeit.
Die Alternative wäre, für jeden Anbieter eine eigene Anbindung zu pflegen. Anthropic hat ein anderes Format, Google ein anderes, lokale Modelle über Ollama oder vLLM wieder ein anderes. Wer drei Anwendungen und fünf Anbieter kombiniert, unterhält fünfzehn Übergänge und fünfzehn Stellen, an denen sich etwas ändern kann. Das Gateway reduziert das auf eine Schnittstelle, die nach innen stabil bleibt, während sich die Anbieter dahinter austauschen lassen.
Otari setzt auf Python, was den Kreis der Mitwirkenden groß und die Einstiegshürde klein hält. Im Repository liegen ein Gateway unter src/gateway und ein Verwaltungsdashboard unter web/src, das auf HeroUI in Version 3 und TanStack Query setzt; auf der Datenbankseite arbeiten die Entwickler mit asynchronem SQLAlchemy und Alembic-Migrationen. Solche Konventionen stehen in den Beitragsrichtlinien des Repositories und deuten auf Wartbarkeit hin.
Virtuelle Schlüssel, Budgets und Kostentracking: die Verwaltungsschicht
Der Nutzen eines Gateways liegt nicht im Weiterleiten, sondern in der Buchführung. Die echten Anbieterschlüssel bleiben an einer Stelle liegen, idealerweise in einem Secret-Store, und die Anwendungen bekommen virtuelle Schlüssel. Jeder davon lässt sich einem Team, einem Projekt oder einer Umgebung zuordnen, und jeder lässt sich einzeln widerrufen, ohne dass irgendwo anders etwas kaputtgeht.
Dazu kommen Budgets. Entscheidend ist nicht die Obergrenze, sondern der Zeitpunkt der Prüfung. Ein Request verbraucht Tokens über die Laufzeit hinweg, und die Kosten stehen erst danach fest. Otari arbeitet deshalb mit einer Reservierungslogik: Vor dem Aufruf wird ein Betrag gegen das Budget reserviert, nach dem Aufruf wird die tatsächliche Nutzung verbucht und die Differenz freigegeben. Wer das nicht baut, merkt erst hinterher, dass ein Team sein Monatsbudget in zwei Tagen verbraucht hat.
Aus denselben Daten entsteht das Kosten- und Nutzungstracking für die LLM-API. Du siehst, welches Modell welche Summe verursacht hat, welcher Schlüssel auffällig viel Traffic erzeugt und wo ein Prompt plötzlich dreimal so viele Tokens zieht wie in der Woche zuvor. Das ist keine Metrik um ihrer selbst willen, sondern die Grundlage für die Entscheidung, ob ein teures Modell an einer Stelle nötig ist.
Self-hosted ohne Rückkanal: der Bruch mit Hybrid- und Hosted-Modus
In der Commit-Historie steht ein Beitrag mit dem Titel „bye b-hybrid“, der den Hybrid- und den Hosted-Modus entfernt. Im Hybridmodus wurden Zugangsdaten pro Request von otari.ai aufgelöst und die Nutzung dorthin zurückgemeldet; im Hosted-Modus gab es eine Steuerungsebene ohne eigene Datenebene. Beide Varianten fallen weg. Jede Installation bedient Verwaltung und Inferenz jetzt aus der eigenen Datenbank. Zuvor tat das nur ein eigenständiges Deployment.
Die Entscheidung hat Folgen. Auf der einen Seite verschwindet eine Abhängigkeit, die viele Teams ohnehin nicht wollen: kein Rückkanal zu einem fremden Dienst, keine offene Frage, wo die Zugangsdaten liegen, kein Sondermodus, der sich anders verhält als dokumentiert. Auf der anderen Seite fällt die Bequemlichkeit weg, die ein gehostetes Modell bietet. Es gibt niemanden mehr, der die Datenbank betreibt, während du dich um die Anwendungen kümmerst.
Für ein open-source LLM-Gateway, das man selbst hostet, ist das konsequent. Ein Gateway sitzt zwangsläufig an der Stelle, an der alle Prompts und alle Schlüssel vorbeikommen. Wer dort eine zweite, externe Instanz zulässt, muss sie erklären können. Otari erklärt sie nicht mehr, sondern streicht sie. Das vereinfacht die Architektur, macht sie aber schwerer zu verkaufen. Beides spricht eher für das Projekt.
Routing als Empfehlung: das Claude-Code-Plugin otari-router
Neben dem klassischen Proxy-Betrieb bietet Otari einen Endpunkt unter /api/v1/routing/recommend, der für eine Aufgabe ein passendes Modell vorschlägt. Darauf setzt ein Plugin für Claude Code auf, das im Repository unter plugins/otari-router liegt und über einen Marketplace-Eintrag installiert wird. Zwei Hooks genügen: Beim Start eines Subagenten geht die Anfrage an den Routing-Endpunkt, nach Abschluss werden Modell und Tokenzahlen protokolliert.
Das Verhalten im Fehlerfall: Antwortet Otari nicht innerhalb von drei Sekunden, oder kommt ein Fehler zurück, startet der Subagent auf dem Modell, das er ohnehin bekommen hätte, und im Transkript steht eine Zeile dazu. Das Gateway blockiert also nicht, es schlägt vor. Ein Routing, das die Arbeit anhält, weil eine Empfehlung fehlt, wäre in der Praxis schlimmer als gar kein Routing.
Installiert wird das Ganze über die Plugin-Befehle von Claude Code. Gateway-URL und API-Schlüssel sind Pflichtoptionen; der Schlüssel landet im sicheren Speicher. Ein Unit-Test hält Marketplace-Datei, Manifest und Hook-Datei in Übereinstimmung, damit die drei nicht auseinanderlaufen. Für ein Werkzeug, das selbst mit Sprachmodellen arbeitet, ist das eine nüchterne Absicherung.
Reifegrad und Tempo: was die Zahlen im Repository verraten
Die Repository-Zahlen sind eine Momentaufnahme vom 26. Oktober 2026: rund 740 Sterne, gut 90 Forks und knapp 1.900 Commits sowie 246 offene Issues, 67 offene Pull Requests und 264 Branches. Solche Werte ändern sich laufend und sind kein Qualitätsnachweis. Sie deuten auf aktive Entwicklung, ersetzen aber weder einen Blick in offene Fehler noch einen Test der benötigten Funktionen. Wer das Gateway produktiv betreibt, sollte Versionen festschreiben und Release-Notes sowie Sicherheitsmeldungen regelmäßig prüfen.
Die als Breaking Change markierten Commits bestätigen das. Die Entfernung des Hybridmodus war eine solche Änderung, kein Nebeneffekt. Die Historie zeigt auch Betriebsdisziplin: Ein wöchentlicher Lock-Refresh wurde eingestellt, nachdem er vier Wochen unbemerkt fehlgeschlagen war; Abhängigkeiten wandern jetzt über Dependabot, und der Lockfile bleibt unter Python 3.15, weil onnxruntime für diese Version keine passenden Pakete liefert.
Wer darüber nachdenkt, das Gateway selbst zu hosten, sollte diese Punkte einordnen. Ein junges Projekt mit hoher Änderungsrate bedeutet, dass du Upgrades einplanen musst, inklusive Datenbankmigrationen. Das ist keine Kritik, sondern die normale Rechnung bei selbst betriebener Infrastruktur. Es macht Arbeit. Die Frage ist, ob sie an der richtigen Stelle landet.
Wann sich ein eigenes LLM-Gateway rechnet – und wann nicht
Ein open-source LLM-Gateway selbst zu hosten lohnt sich, sobald mehrere Anbieter im Spiel sind und mehrere Teams dieselben Schlüssel teilen müssen. Sobald du Kosten pro Abteilung ausweisen willst, sobald ein Anbieterwechsel nicht durch zwanzig Repositories gehen soll oder sobald die Frage auftaucht, welche Prompts das Haus verlassen, wird die zentrale Stelle zum Vorteil. Dann ist der OpenAI-kompatible Gateway für mehrere Anbieter vor allem eine Schnittstelle zur Buchhaltung.
Weniger sinnvoll ist das für ein einzelnes Team mit einem einzigen Anbieter und einem überschaubaren Budget. Dort überwiegen der Betriebsaufwand für Datenbank, Migrationen und Monitoring. Auch wer einen Managed Service mit SLA und Support braucht, wird mit einer selbst betriebenen Instanz nicht glücklich; Otari liefert Software, keinen Betrieb. Und wer vor allem eine Oberfläche zum Durchklicken sucht, sollte prüfen, ob er sie braucht.
Für alle dazwischen gilt: Man kann klein anfangen. Ein Endpunkt für 40+ LLM-Anbieter, einige virtuelle Schlüssel, ein Budget pro Team – lässt sich schrittweise erproben und zurückrollen, solange die Anwendung nur Basis-URL und Schlüssel tauscht; der tatsächliche Aufwand hängt von Authentifizierung, Datenbank, Monitoring und Ausfallsicherheit ab. Otari macht die Modelle nicht besser und die Prompts nicht klüger. Es macht sichtbar, was sie kosten, und verwaltbar, wer sie benutzt. Ob dir das den Betrieb einer eigenen Datenbank wert ist, ist eine organisatorische Frage. Ein Blick in die eigene Rechnung hilft bei der Antwort.
Quelle: github.com
