OmniRoute: freies MIT-KI-Gateway mit 358 Anbietern, über 1.200 Modellen und Token-Kompression

OmniRoute ist ein KI-Gateway unter MIT-Lizenz von diegosouzapw, und sein Versprechen ist unmissverständlich. Coding-Werkzeuge wie Claude Code, Codex, Cursor, Cline, Copilot und Antigravity sollen über einen einzigen Endpunkt 358 Modellanbieter erreichen (der Repository-Titel nennt 359 Anbieter und über 1.200 Modelle). Mehr als 150 davon bieten ein kostenloses Kontingent, und das Gateway wechselt automatisch zum nächsten, wenn ein Kontingent erschöpft ist. Die Schlagzeile lautet rund 1,62 Milliarden kostenlose Token pro Monat, bei null Einstiegskosten. Eine so große Zahl verlangt Skepsis, also lohnt es sich, zuerst ihre Herleitung zu lesen, bevor man ihr Gewicht beurteilt.

Das README ist zurückhaltender als sein Werbebanner. Das Projekt katalogisiert 489 Einträge kostenloser Stufen und fasst sie zu 35 wiederkehrenden Pool-Schlüsseln zusammen. In die Schlagzeile fließen nur die 17 Pools mit veröffentlichtem, positivem Monatsbudget sowie fünf modellbezogene Obergrenzen bei Groq, und es wird nach gemeinsamem Pool dedupliziert, sodass jeder Pool nur einmal zählt. Kontingente, die sich erst nach einer regionalen Identitätsprüfung öffnen, derzeit ModelScope mit etwa 6 Millionen Token, werden getrennt ausgewiesen und nie in die Schlagzeile eingerechnet. Im ersten Monat sind mit Anmeldeguthaben bis zu rund 2,22 Milliarden möglich. Der Budgetbalken nennt die großen Posten: Mistral mit 1 Milliarde, Nara mit 210 Millionen, LLM7 und xKiro mit je 150 Millionen sowie Groq mit 30 Millionen über fünf Obergrenzen. Dreizehn Anbieter sind in einem Katalog für Vertragsrisiken als „meiden“ markiert, die Entscheidung bleibt beim Nutzer. Die Autoren geben außerdem an, die Zahlen alle zwei Wochen neu zu prüfen, in beide Richtungen. Diese Transparenz ist der eigentliche Beitrag. Das Schwierige an kostenlosen Stufen ist selten, sie zu finden, sondern zu sehen, was man tatsächlich hat.

Bei Routing und Kosten bietet OmniRoute 19 Routing-Strategien und wechselt den Anbieter automatisch, wenn ein vorgelagertes Kontingent erschöpft ist oder ein Aufruf scheitert. Zusätzlich stapelt es zwei Kompressionsschichten, RTK und Caveman, und verspricht 15 bis 95 Prozent eingesparte Token, im Mittel etwa 89 Prozent. Die Kompression geschieht im Gateway, das vorgelagerte Werkzeug braucht keine Änderung. Diese Zahl sollte man nüchtern lesen: Der Durchschnitt von 89 Prozent stammt vom Projekt selbst, und der reale Gewinn hängt von der Last ab. Wiederholte Werkzeugausgaben, lange Logs und Standardkontext lassen sich gut komprimieren. Dichtes Code-Reasoning und neue Aufgabenbeschreibungen deutlich weniger. Sie sind eher als obere Orientierung zu verstehen und sollten an eigenen Sitzungen gemessen werden. Das technische Problem ist real: Jeder Anbieter spricht einen eigenen Dialekt, authentifiziert anders und begrenzt den Verkehr nach eigener Regel, pro Minute, pro Tag oder pro Modell. Das Gateway muss diese Unterschiede in eine einheitliche Aufrufschicht falten und sich merken, wie viel in jedem Pool übrig ist und wann er zurückgesetzt wird. Mit den Routing-Strategien lässt sich der nächste Sprung nach Latenz, Kosten, Restkontingent oder Modellfähigkeit wählen, statt es dem Zufall zu überlassen. Der automatische Fallback macht aus einem Fehler einen internen Wiederholungsversuch, und das Coding-Werkzeug sieht nur einen leicht verzögerten Erfolg. Bei lang laufenden Agentenaufgaben ist das nützlicher als jede Verfügbarkeitszusage eines einzelnen Anbieters, denn ein Abbruch mitten im Lauf bedeutet meist, den gesamten Kontext neu aufzubauen.

Architektonisch rückt das Projekt das Gateway in die Rolle einer Steuerungsebene für Coding-Agenten. Deren Nutzungsmuster ist ungewöhnlich: lange Sitzungen, häufige Werkzeugaufrufe, immer wieder abgespielter Kontext, hoher Kontingentdruck, und Ratenlimits schlagen oft im ungünstigsten Moment zu. Eine Zwischenschicht, die Kontingente und Protokollunterschiede versteht und ohne Aufhebens die Route wechselt, löst die Frage „welches Modell rufe ich auf“ aus den Einstellungen jedes Werkzeugs heraus und verwaltet sie an einem Ort. Entwickler pflegen dann nicht mehr ein Dutzend Schlüssel und Limitregeln pro Werkzeug, sondern haben einen Endpunkt und ein Dashboard, einschließlich der Live-Ansicht unter /dashboard/free-tiers. Die MIT-Lizenz erlaubt Selbsthosting und Prüfung, was bei einer Komponente, die Prompts sieht, zählt.

Die Risiken bündeln sich an derselben Stelle. Erstens können sich die Bedingungen kostenloser Stufen jederzeit ändern: Zieht ein Anbieter die Regeln an, spüren abhängige Arbeitsabläufe es sofort, und das Projekt räumt selbst ein, dass die Zahlen schwanken. Zweitens enthalten Prompts oft Quellcode und internen Kontext, und die Weiterleitung über Dutzende Dritte macht den Datenweg weit komplexer als bei einem einzigen Anbieter. Drittens wird das Gateway, sobald Schlüssel und Routing-Regeln dort zusammenlaufen, zu einem wertvollen Ziel und sollte wie ein Produktionsdienst betrieben werden. Pragmatisch ist es, das Gateway für Open-Source- oder unkritische Projekte zu nutzen, sensible Repositories über eigene oder vertrauenswürdige bezahlte Anbieter zu leiten und die Live-Seite der Kontingente im Blick zu behalten.

Im Branchenkontext spiegelt OmniRoute eine Arbeitsteilung, die sich gerade herausbildet. Modellanbieter konkurrieren über Leistung und Preis, während „viele Anbieter gut nutzen“ zu einer eigenen Infrastrukturschicht wird. Kostenlose Stufen dienten zunächst der Kundengewinnung; systematisch gebündelt werden sie zu einem planbaren öffentlichen Rechenpool. Das hilft vor allem Studierenden, unabhängigen Entwicklern und kleinen Teams, weil es die Hürde für Experimente mit Agenten-Workflows senkt. Es erinnert aber auch daran, dass die Nachhaltigkeit kostenloser Kontingente von den Geschäftsentscheidungen der Anbieter abhängt, und je erfolgreicher die Bündelungsschicht wird, desto eher dürften Anbieter die Regeln anpassen. Die vernünftige Lesart ist daher, OmniRoute als Beobachtungsfenster und übertragbares Entwurfsmuster zu sehen, nicht als Versprechen dauerhaft kostenloser Rechenleistung. Dauerhaft wertvoll für ein Team sind Kontingentüberwachung, Fallback-Logik und Routing-Richtlinien im eigenen Stack. Diese Fähigkeiten bleiben nützlich, wie sich die kostenlosen Stufen auch entwickeln, und sie lassen sich auch auf bezahlte Anbieter übertragen.