Wäg and LiteLLM: same API, different layer

Not a competitor at the same layer

Same OpenAI-compatible API surface. Same configuration, importable.

Free here. Enterprise there.

Both projects are open source with a commercial tier, so the question was never whether there is a paid edition. It is where each one draws the line. LiteLLM's enterprise documentation lists what their licence key turns on, and most of that list is Apache-2.0 in Wäg. On multi-tenancy the difference is structural rather than a matter of degree: in their published database schema an organization carries a budget, spend rollups and a membership list, and a team points at it through an optional foreign key, which makes it a grouping level above teams. In Wäg an organization is an authorization boundary that every request is checked against. Where we gate the same capability they do, the table says so.

Fair is fair. Their enterprise tier also carries IP allowlists and a SOC 2 Type II report. We have neither today.

LiteLLM's column is their own enterprise documentation, which states that a licence key enables the features listed there. Not listed means a capability is not named on that page, which is not the same as not possible. Wäg's column is the licence split the gateway enforces: an Enterprise capability is a module that a signed licence has to name. The agent rows marked Not listed are a different kind of Not listed: their agent gateway is not an Enterprise feature at all, so those capabilities are missing from their product rather than priced into their licence.

Both ship an agent gateway. Only one governs the agent.

LiteLLM added an A2A agent gateway, and it does the obvious things well: register agents, control which teams and keys may reach them, attribute the cost. Two rows are genuine parity. The rest are where the two products stop being the same kind of thing.

LiteLLM's column is what their own documentation and public repository show. Not documented means the capability is not described there, which is not the same as impossible. Three rows deserve the detail. Their kill switch fires a webhook at the agent's own runtime and, in their words, leaves the agent registered and enabled on the LiteLLM side; ours refuses the agent at the gateway, on every replica and region, and ends a stream that is already running. Their require_approval is OpenAI's field: set to anything but never, the tool call is handed back to the client to run — nothing is held, nobody is named, nothing is recorded. And for agent payments, a code search of their repository for x402 and AP2 returns nothing at all. On third-party APIs the difference is not the proxying. Their pass-through endpoints route to any external API with a credential set in the configuration, and grants per key and team are an Enterprise feature. What is absent is the decision: the destination is a static route rather than something a given agent may or may not reach, no rule reads the call's arguments, no approval can hold it, it carries no data-flow label, and it does not count against a run.

How agent governance works in Wäg

Cases where LiteLLM is the right answer

Genuinely. If you recognise your situation here, adopting a control plane buys you operational surface you do not need yet.

• One team, one or a few services, and you want multi-provider today.
• You use import litellm inside application code for its in-process routing and callbacks, and value that directly.
• You have custom Python callbacks in the request lifecycle that would be real work to reimplement.
• Your provider list includes something long-tail that Wäg does not cover yet.
• Your governance requirements are genuinely satisfied by per-key budgets.

The symptoms, not the feature list

• Budgets need to match your org chart. Per-key limits cannot express "this team gets €4k, no single user more than €500, and marketing's experiments cannot eat engineering's capacity."
• Policy has to apply to applications that never opted in. A rule you can only enforce where somebody remembered to add it is not a control.
• Agents made the surface much larger. One user turn becomes N model and tool calls against remote MCP servers. Per-server auth, tool ACLs and per-hop audit stop being nice-to-have.
• Somebody asked what AI cost, by team, last quarter. And answering it required a data project rather than a dashboard.
• Compliance needs records, not intentions. Since 2 August 2026, GPAI enforcement powers and Article 50 transparency obligations under the EU AI Act carry penalty exposure. Logging and traceability have to be demonstrable.
• The gateway became load-bearing. Once every product path is behind it, a Python process with an interpreter and a deploy-time dependency tree is a different risk conversation than it was at ten requests a minute.

What does not change at all

Design commitments, not a feature count

Feature tables go stale in a quarter. These are structural choices that do not change with a release.

If LiteLLM is doing its job, keep it. If the thing that is actually strained is governance rather than routing, that is a different layer — and it is the one Wäg is built for.