About Busbar

The control plane for AI traffic, built to run on your own infrastructure.

Busbar is a single-binary AI control plane written in Rust: one fast, self-hosted process that speaks every major provider protocol, translates losslessly between them, and enforces your keys, budgets, and rate limits, all without your prompts or credentials ever leaving your network. We started Busbar because the tools in this space made you choose between performance, control, and simplicity. We did not think that trade was necessary.

What we are building

Every team wiring up more than one model runs into the same wall: provider APIs differ, keys sprawl, spend is hard to see, and the gateway you reach for to fix it becomes its own heavyweight dependency with a database and a runtime to babysit.

Busbar is built on a different premise from the rest of the category: we speak protocols, not providers. Most gateways flatten everything to one vendor's API shape, usually OpenAI's, and then bolt the others on as translations of it. That choice quietly picks a winner, and everything native to the other providers, the features that made you choose them, gets dropped on the way through. Busbar treats the wire protocols as first-class on both sides and translates between them through a superset representation, so an Anthropic-native feature survives a hop to a Gemini backend and back. No provider is the privileged one. Add a new provider and it is a peer on day one, not a second-class adapter.

What that buys you is freedom to change your mind. Your application picks the SDK it likes; your infrastructure picks the model it wants; neither has to know about the other, and switching either one is a config edit rather than a rewrite. The speed matters, and a control plane that adds microseconds rather than milliseconds is worth having, but it is the means and not the point. The point is that the layer in front of your models should not be the thing that constrains which models you can use.

The rest follows from staying small and staying yours: one static binary with nothing else to run out of the box, running where your traffic already does, so prompts and credentials never leave your network. If you need more, like a shared store for cluster-wide governance, you add a signed plugin, not a second system.

Where we reproduce a competitor, we publish our own same-box benchmarks; where we don't, we take that project's own published numbers at their word (the methodology is stated per competitor on our performance page). And we help fund onthebench.ai, a neutral, reproducible benchmark of the self-hostable AI gateway space, Busbar among the entrants, so the numbers are something you can re-run yourself rather than take on faith.

The team

Matthew Jackson, founder of Busbar

Matthew Jackson

Founder

Matthew's background spans engineering, solution architecture, and go-to-market: he has built performance-critical backend systems, designed them for customers with real constraints, and then had to sell and support the result. That mix is why Busbar looks the way it does, shaped as much by what breaks in someone else's production and what an operator will actually agree to run as by what is interesting to build. He started the project out of a conviction that an AI control plane should be measured in microseconds and owned by the team that runs it, and he still writes the code.

Advisors

Behind the scenes, Matthew works with a group of advisors helping get Busbar off the ground. They cover AI and technical guidance from CTOs across the industry, along with legal, finance, and go-to-market support. Their experience keeps us honest about what teams actually need in production, from wire-protocol edge cases to the realities of governing spend across a fleet, and about everything around the product that an engineer does not wake up knowing. They are not listed publicly at this stage.

Where we are

Busbar is an early-stage, pre-seed startup. The software is open source under the Apache-2.0 license and is built to run in production; the company around it is deliberately small and focused on the product. That means you get direct access to the people building it: no support tier stands between you and an answer.