9Router: ein lokaler LLM-Router mit Quota-Fallback und Token-Kompression

Welches Problem 9Router adressiert

Das Ausgangsproblem ist banal und teuer zugleich. Ein Entwickler zahlt für Claude Code, für Codex, für Copilot, dazu kommen Gratis-Kontingente bei Kiro oder OpenCode Free, und jeden Monat verfällt ein Teil davon ungenutzt. Gleichzeitig stoppt ein Rate Limit die Arbeit mitten im Refactoring. Das README zählt genau diese fünf Punkte auf: ungenutzte Abo-Kontingente, Limits, teure Tool-Ausgaben, teure APIs, manuelles Umschalten zwischen Anbietern. 9Router setzt an allen fünf gleichzeitig an, indem es sich als einzelner Endpunkt zwischen CLI-Werkzeug und Anbieter stellt. Zielgruppe sind nach der Beschreibung Einzelentwickler und kleine Teams, die mehrere Zugänge parallel betreiben und deren Werkzeuge (Claude Code, Codex, Cursor, Cline, Copilot, Antigravity) sich auf eine eigene Basis-URL umkonfigurieren lassen. Das ist eine engere Zielgruppe als das Wort "universal" vermuten lässt.

Der Datenfluss: ein Port, drei Stufen

Die Architektur ist im README als Diagramm hinterlegt und lässt sich in einem Satz zusammenfassen: Der Client spricht http://localhost:20128/v1 an, der Router nimmt die Anfrage entgegen, normalisiert sie und leitet sie an einen von drei Tiers weiter. Tier 1 sind Abonnements (Claude Code, Codex, GitHub Copilot), Tier 2 sind günstige Modelle, im Diagramm mit GLM zu 0,6 US-Dollar pro Million Token und MiniMax zu 0,2 US-Dollar pro Million Token beziffert, Tier 3 sind kostenlose Quellen wie Kiro, OpenCode Free und Vertex mit 300 Dollar Startguthaben. Der Wechsel nach unten wird durch zwei Ereignisse ausgelöst: erschöpftes Quota und erreichtes Budgetlimit. Zwischen Client und Anbieter sitzen vier Funktionen: RTK zur Kompression von tool_result-Inhalten, Formatübersetzung zwischen OpenAI- und Claude-Schemata, Quota-Verfolgung und automatische Token-Erneuerung. Bemerkenswert ist, dass die Formatübersetzung als eigener Baustein genannt wird. Das deutet darauf hin, dass Anfragen nicht unverändert durchgereicht werden, sondern durch eine Übersetzungsschicht laufen. Genau dort entstehen in der Praxis die meisten Kompatibilitätsprobleme, etwa wenn ein Client auf Streaming mit Tool-Calls besteht und das Zielmodell ein anderes Ereignisschema liefert. Das README adressiert diesen Punkt nicht.

RTK: Kompression an der richtigen Stelle

Der Token-Sparer heißt RTK und greift nicht am Prompt des Nutzers an, sondern an den tool_result-Blöcken. Das ist die technisch sinnvollste Stelle, denn das README benennt git diff, grep und ls ausdrücklich als Kostentreiber. Solche Ausgaben sind lang, repetitiv und enthalten viel Text, der für den nächsten Denkschritt des Modells irrelevant ist. Eine Kompression genau dort spart Token, ohne die eigentliche Frage des Nutzers zu verändern. Als Größenordnung nennt das Projekt 20 bis 40 Prozent pro Anfrage, im Titel der Repository-Beschreibung steht "RTK -40% tokens". Diese Zahl ist eine Projektangabe, kein unabhängig gemessener Wert, und sie wird stark davon abhängen, welchen Anteil Tool-Ausgaben an der jeweiligen Konversation haben. In einem Chat ohne Shell-Nutzung ist der Effekt nahe null. Wer den Sparer bewertet, sollte ihn an einem eigenen, tool-lastigen Verlauf prüfen, nicht an der Zahl im README.

Installation und die zwei Betriebswege

Der schnellste Weg ist die globale Installation über npm, gefolgt vom Start des Befehls, woraufhin das Dashboard unter http://localhost:20128 erscheint. Der zweite Weg führt über den Quellcode, und hier wird es für Bewertungen wichtig: Das Repository-Paket heißt laut README 9router-app und ist privat, der Quellcode- und Docker-Betrieb gilt daher als der erwartete lokale Entwicklungspfad. Die dokumentierten Schritte sind das Kopieren von .env.example nach .env, npm install und der Start im Entwicklungsmodus mit PORT=20128 sowie NEXT_PUBLIC_BASE_URL=http://localhost:20128. Für den Produktivmodus sind npm run build und anschließend npm run start mit zusätzlichem HOSTNAME=0.0.0.0 dokumentiert. Die beiden relevanten Endpunkte sind das Dashboard unter /dashboard und die OpenAI-kompatible API unter /v1. In der CLI-Konfiguration werden Endpunkt, ein im Dashboard kopierter API-Schlüssel und ein Modellname wie kr/claude-sonnet-4.5 eingetragen. Das Präfix kr/ verweist auf den Kiro-Anbieter und zeigt, dass die Modellnamen im Router einen Anbieter-Namensraum tragen. Wer mehrere Anbieter parallel nutzt, muss diese Präfixe in seiner Werkzeugkonfiguration berücksichtigen.

Grenzen und Fälle, in denen 9Router das falsche Werkzeug ist

Die erste Einschränkung steht im README selbst, nur versteckt: Die beworbene Bequemlichkeit hängt an Gratis-Kontingenten Dritter. Kiro wird mit etwa 50 Credits pro Monat angegeben, OpenCode Free ohne Authentifizierung, Vertex mit 300 Dollar Startguthaben. Solche Zusagen können sich jederzeit ändern, und der Router kann daran nichts ändern. Ein Ausfall oder eine Verschärfung der Bedingungen trifft nicht den Router, sondern die Stufe, auf die er ausweicht. Die zweite Einschränkung ist der Einzelpunkt. Läuft der Prozess auf Port 20128 nicht, steht die gesamte Coding-Umgebung still, unabhängig davon, wie viele Anbieter konfiguriert sind. Die dritte betrifft die Kostenkontrolle: Der Router kennt ein Budgetlimit und wechselt dann die Stufe, aber das README beschreibt nicht, wie dieses Limit berechnet wird, ob es sich auf Token, Anfragen oder Dollarbeträge bezieht und ob es pro Anbieter oder global gilt. Ohne diese Klarheit ist die Tier-2-Stufe eine offene Rechnung. Viertens ist die Formatübersetzung ein Risiko für Clients, die auf anbieterspezifische Felder setzen, etwa auf Denkstufen. Die Release Notes zu v0.5.20 nennen einen "thinking level picker + suffix support across providers", was nahelegt, dass solche Felder über Anbieter hinweg nicht einheitlich sind und der Router sie eigens abbilden muss. Wer ein Modell mit exotischen Parametern nutzt, sollte mit Abweichungen rechnen. Schließlich ist der Quellcode-Betrieb ausdrücklich der vorgesehene Weg für dieses Repository, während das npm-Paket eine andere, private Anwendung ist. Wer aus dem Repository heraus arbeitet, arbeitet an einer Next.js-Anwendung, nicht an einer schlanken Bibliothek.

Was ein Gateway wie LiteLLM anders macht

Die naheliegende Alternative ist ein etabliertes LLM-Gateway wie LiteLLM. Der Unterschied liegt weniger im Funktionsumfang als im Schwerpunkt. LiteLLM ist als Proxy für viele Anbieter mit einem Fokus auf Vereinheitlichung, Budgets und Logging gebaut; die Konfiguration erfolgt typischerweise deklarativ über eine Konfigurationsdatei, in der Modelle, Anbieter und Limits eingetragen werden. 9Router stellt stattdessen ein Dashboard in den Mittelpunkt, in dem Anbieter verbunden, Kontingente beobachtet und Schlüssel kopiert werden. Der zweite Unterschied ist RTK. LiteLLM komprimiert Tool-Ausgaben nicht als Kernfunktion; 9Router tut genau das und macht es zum Verkaufsargument. Wer ohnehin schon eine Gateway-Konfiguration pflegt und nur die Token-Kompression braucht, bekommt bei 9Router ein zusätzliches System mit eigener Oberfläche und eigener Datenhaltung. Umgekehrt gilt: Wer zum ersten Mal mehrere Gratis-Kontingente parallel nutzen will, kommt mit dem Dashboard schneller zu einem laufenden Endpunkt als mit einer handgeschriebenen Proxy-Konfiguration. Die Entscheidung hängt also daran, ob der Bedarf bei Vereinheitlichung und Nachvollziehbarkeit oder bei Kontingent-Ausnutzung und Token-Sparen liegt.

Wartung, Release-Tempo und Lizenz

Das Repository steht unter MIT-Lizenz, was die Weitergabe und Anpassung erlaubt, solange Copyright- und Lizenzhinweis erhalten bleiben. Das ist die einfachste der gängigen Varianten und verhindert keine kommerzielle Nutzung. Wichtiger für den Betrieb ist die Kopplung an fremde Anbieter-APIs. Die Release Notes der letzten veröffentlichten Versionen zeigen, woran gearbeitet wird: v0.5.18 brachte "cached token tracking, provider fixes", v0.5.20 einen Denkstufen-Wähler, v0.5.35 "Grok Imagine video, Copilot Claude route, i18n th/fa". Der wiederkehrende Bestandteil "provider fixes" ist der eigentliche Wartungsposten. Jede Änderung an einer Anbieter-API erfordert eine Anpassung im Router, und der Betreiber muss die neue Version einspielen, sonst bricht die betroffene Stufe. Für die Kostenplanung heißt das: Der Router ist nicht wartungsfrei, er verlagert die Wartung nur von der eigenen Tool-Konfiguration in ein zusätzliches System. Wer aus dem Quellcode baut, muss außerdem bei jedem Update die Next.js-Abhängigkeiten neu installieren und den Build erneut ausführen. Hinzu kommt ein Punkt, den das README nicht behandelt: Wenn Zugangsdaten mehrerer Anbieter in einem Dashboard zusammenlaufen, verschiebt sich die Angriffsfläche. Ob Schlüssel verschlüsselt gespeichert werden, lässt sich aus dem vorliegenden Material nicht belegen, und das ist vor einem produktiven Einsatz zu klären.

Redaktionelles Fazit

Sinnvoll ist 9Router für Entwickler, die bereits mehrere Abonnements und Gratis-Kontingente parallel bezahlen und deren CLI-Tools sich auf einen OpenAI-kompatiblen Endpunkt umbiegen lassen. Wer einen Anbieter mit stabilem Vertrag nutzt oder Compliance-Aufzeichnungen braucht, sollte es nicht dazwischenschalten, weil der Router dann nur eine zusätzliche Fehlerquelle ist. Vor dem Einsatz zu prüfen: ob der eigene Client Streaming und Tool-Calls über http://localhost:20128/v1 sauber verarbeitet, ob die im Dashboard angezeigten Gratis-Kontingente tatsächlich in der erwarteten Größenordnung liegen, und ob die Lizenz- und Nutzungsbedingungen der durchgereichten Anbieter einen solchen Proxy überhaupt erlauben.

Offizielle Quellen

1. decolua/9router on GitHub
2. License: MIT
3. Project website
4. README
5. Releases