Wäg und LiteLLM: dieselbe API, andere Schicht

Kein Wettbewerber auf derselben Schicht

Dieselbe OpenAI-kompatible API-Oberfläche. Dieselbe Konfiguration, importierbar.

Hier frei. Dort Enterprise.

Beide Projekte sind quelloffen mit einer kommerziellen Stufe. Die Frage war nie, ob es eine kostenpflichtige Edition gibt, sondern wo jedes Projekt die Grenze zieht. Die Enterprise-Dokumentation von LiteLLM listet auf, was ihr Lizenzschlüssel freischaltet, und das meiste davon steht in Wäg unter Apache-2.0. Bei der Mandantenfähigkeit ist der Unterschied struktureller Natur: In ihrem veröffentlichten Datenbankschema trägt eine Organisation ein Budget, Ausgabensummen und eine Mitgliederliste, und ein Team verweist über einen optionalen Fremdschlüssel darauf. Damit ist sie eine Gruppierungsebene über den Teams. Bei Wäg ist eine Organisation eine Autorisierungsgrenze, gegen die jede Anfrage geprüft wird. Wo wir dieselbe Funktion ebenfalls hinter die Lizenz legen, steht das in der Tabelle.

Fairerweise: Ihre Enterprise-Stufe bringt auch IP-Allowlists und einen SOC-2-Typ-II-Bericht mit. Beides haben wir heute nicht.

Die LiteLLM-Spalte stammt aus deren eigener Enterprise-Dokumentation, die angibt, dass ein Lizenzschlüssel die dort genannten Funktionen freischaltet. Nicht aufgeführt heißt, dass eine Funktion auf dieser Seite nicht genannt wird, und nicht, dass sie unmöglich wäre. Die Wäg-Spalte ist die Lizenzaufteilung, die das Gateway durchsetzt: Eine Enterprise-Funktion ist ein Modul, das eine signierte Lizenz nennen muss. Die als Nicht aufgeführt markierten Agentenzeilen sind ein anderes Nicht aufgeführt: Deren Agenten-Gateway ist gar keine Enterprise-Funktion, diese Fähigkeiten fehlen also im Produkt, statt in der Lizenz eingepreist zu sein.

Beide liefern ein Agenten-Gateway. Nur eines regiert den Agenten.

LiteLLM hat ein A2A-Agenten-Gateway ergänzt, und das Naheliegende macht es gut: Agenten registrieren, steuern, welche Teams und Schlüssel sie erreichen, Kosten zuordnen. Zwei Zeilen sind echte Gleichstände. Der Rest ist der Punkt, an dem beide aufhören, dieselbe Art Produkt zu sein.

Die LiteLLM-Spalte gibt wieder, was deren eigene Dokumentation und deren öffentliches Repository zeigen. Nicht dokumentiert heißt, dass die Funktion dort nicht beschrieben wird, und nicht, dass sie unmöglich wäre. Drei Zeilen verdienen die Einzelheit. Ihr Not-Aus feuert einen Webhook an die Laufzeitumgebung des Agenten und lässt den Agenten, in ihren Worten, auf der LiteLLM-Seite registriert und aktiviert; unserer weist den Agenten am Gateway ab, auf jedem Replikat und in jeder Region, und beendet einen bereits laufenden Stream. Ihr require_approval ist das Feld von OpenAI: steht es auf etwas anderes als never, geht der Werkzeugaufruf zur Ausführung an den Client zurück — nichts wird angehalten, niemand wird benannt, nichts wird festgehalten. Und bei Agentenzahlungen findet eine Codesuche in deren Repository nach x402 und AP2 überhaupt nichts. Bei Drittanbieter-APIs liegt der Unterschied nicht im Weiterleiten. Deren Pass-through-Endpunkte leiten an jede externe API weiter, mit in der Konfiguration hinterlegten Zugangsdaten, und Rechte je Schlüssel und Team sind eine Enterprise-Funktion. Es fehlt die Entscheidung: Das Ziel ist eine statische Route und nicht etwas, das ein bestimmter Agent erreichen darf oder nicht; keine Regel liest die Argumente des Aufrufs, keine Freigabe kann ihn anhalten, er trägt kein Datenfluss-Etikett und zählt nicht gegen einen Lauf.

Wie Agenten-Governance in Wäg funktioniert

Fälle, in denen LiteLLM die richtige Antwort ist

Und zwar ernst gemeint. Wenn Sie sich hier wiedererkennen, bringt eine Control Plane vor allem Betriebsaufwand, den Sie noch nicht brauchen.

• Ein Team, ein oder wenige Services, und Sie wollen heute Multi-Provider.
• Sie nutzen import litellm im Anwendungscode wegen seines In-Process-Routings und seiner Callbacks und schätzen genau das.
• Sie haben eigene Python-Callbacks im Anfrage-Lebenszyklus, deren Neuimplementierung echte Arbeit wäre.
• Ihre Anbieterliste enthält etwas Ausgefallenes, das Wäg noch nicht abdeckt.
• Ihre Governance-Anforderungen sind mit Budgets pro Key tatsächlich erfüllt.

Die Symptome, nicht die Funktionsliste

• Budgets müssen zum Organigramm passen. Limits pro Key können nicht ausdrücken: „Dieses Team bekommt 4.000 €, kein einzelner Nutzer mehr als 500 €, und die Experimente des Marketings dürfen nicht die Kapazität der Entwicklung aufbrauchen.“
• Policy muss für Anwendungen gelten, die nie zugestimmt haben. Eine Regel, die nur dort greift, wo jemand daran gedacht hat, sie einzubauen, ist keine Kontrolle.
• Agenten haben die Angriffsfläche deutlich vergrößert. Aus einem Nutzerzug werden N Modell- und Werkzeugaufrufe gegen entfernte MCP-Server. Auth pro Server, Werkzeug-ACLs und Audit pro Schritt sind dann kein Nice-to-have mehr.
• Jemand hat gefragt, was KI im letzten Quartal je Team gekostet hat. Und die Antwort erforderte ein Datenprojekt statt eines Dashboards.
• Compliance braucht Nachweise, keine Absichten. Seit dem 2. August 2026 sind die GPAI-Durchsetzungsbefugnisse und die Transparenzpflichten aus Artikel 50 des EU AI Act mit Sanktionsrisiko bewehrt. Protokollierung und Nachvollziehbarkeit müssen nachweisbar sein.
• Das Gateway ist tragend geworden. Sobald jeder Produktpfad dahinter liegt, ist ein Python-Prozess mit Interpreter und zur Deployzeit aufgelöstem Abhängigkeitsbaum eine andere Risikodiskussion als bei zehn Anfragen pro Minute.

Was sich überhaupt nicht ändert

Designentscheidungen, keine Funktionszählung

Funktionstabellen veralten in einem Quartal. Dies sind strukturelle Entscheidungen, die sich nicht mit einem Release ändern.

Wenn LiteLLM seine Aufgabe erfüllt, behalten Sie es. Wenn das, was tatsächlich an die Grenze kommt, Governance statt Routing ist, dann ist das eine andere Schicht — und genau für die ist Wäg gebaut.