AI gateway vs AI control plane
The terms are used interchangeably, which is a problem when you are specifying infrastructure. The distinction is not marketing — it is about where decisions get made and what they apply to.
One routes requests. The other decides what a request is allowed to be.
An AI gateway
Puts one endpoint in front of several providers. It routes, holds keys, retries, caches and fails over. It solves a connectivity and resilience problem, and it solves it for whoever points at it.
An AI control plane
Decides what a request is allowed to be before it becomes one: who is asking, what they may spend, what data may leave, which model may serve it, and what record the request leaves behind. It solves a governance problem, for the organization, whether or not each application participated.
Every control plane contains a gateway. Not every gateway becomes a control plane — that requires identity, budgets, policy and audit to be first-class in the request path rather than bolted alongside it.
Where the boundary actually falls
| Axis | Gateway | Control plane |
|---|---|---|
| Unit of concern | A request and a route | An inference request, with its cost, policy and identity |
| Scope | The services that point at it | Every AI workload in the organization |
| An agent's authority | A key that works until somebody rotates it | An identity with an owner, a run limit, a tool policy and a named approver |
| Enforcement | Advisory, or per-key limits | In the request path, before the provider is contacted |
| Record produced | Traffic logs | Decisions — model, reason, verdict, cost, actor |
| Operated by | A team | The organization, as shared infrastructure |
How to tell which one you have
Useful when evaluating any vendor in this category, including us.
- The opt-in test. If a team spins up a service tomorrow and doesn't tell you, is it governed? A gateway governs what points at it. A control plane governs what the organization has decided must go through it — and makes not going through it the exception you can detect.
- The enforcement test. When a budget is exceeded, does something stop, or does a dashboard turn red? Advisory limits are reporting. A control plane rejects the call before the provider is contacted.
- The record test. Can you reconstruct, six months later, which model served a request, why, what policy verdicts applied, what it cost, and on whose behalf? A gateway logs traffic. A control plane produces decisions.
The same three events, twice
| Event | With a gateway | With a control plane |
|---|---|---|
| A team's spend doubles overnight | You find out from the provider invoice, or from a dashboard nobody was watching. Attribution is a data exercise. | The soft-budget webhook fired at the threshold; the hard limit rejected the overage before it was spent, against that team's counter only. |
| A new data-handling rule is issued | It becomes a ticket for every team that calls a model, and a code review problem forever after. | One policy change takes effect for every workload behind the endpoint at once, including the ones nobody registered. |
| An agent calls an unsanctioned tool | The tool call never passed through the gateway, so there is no record that it happened. | Tools reached through the gateway's MCP endpoint are allow-listed, so the call was refused and logged. A server the client runs itself shows up in the agent inventory. |
Often, no
AI is one feature in one service, with one provider and one team. A gateway is the right size for that, and over-buying infrastructure is its own failure mode. Nothing below applies to you yet, and adopting a control plane early mostly buys operational surface you don't need.
You likely do once any of these is true:
- More than a handful of teams call models.
- Spend needs attributing to cost centres, not just capping.
- Data-handling rules must hold across applications, not per repository.
- Agents call external tools with real credentials.
- You have to demonstrate control over AI usage to someone outside engineering.
- The gateway became load-bearing — every product path now depends on it.
A control plane you operate
Wäg is an open-source AI control plane that runs in your own infrastructure. It includes the gateway — OpenAI-compatible, multi-provider, caching, failover — and adds identity, hierarchical budgets, policy, agent governance and audit in the same request path. It imports LiteLLM configuration, so if you already run a gateway, trying it costs one base URL.
One endpoint. Every model. Complete control.
Run it in your own infrastructure
Everything you need to run a control plane in production is Apache-2.0 and stays that way — routing, HA, caching, failover, budgets, policy, MCP, jobs and observability. Self-hosted, no account, no phone-home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>Not a working pull: the images are not public yet. Design partners receive the registry details privately.
Deploy in 5 minutesShape it as a design partner
Wäg is not publicly released yet. We are working with a small cohort of teams running multi-provider AI in production, and serious about governance and sovereignty, to harden the control plane on real workloads.
- Every Enterprise capability included, at no licence cost
- Hands-on migration — we do it with you, including from LiteLLM
- A direct line to the engineers building it, and real influence on what ships next