Busbar Calls Itself an Execution Boundary for AI. Read the Block Quote Before You Plan Around It.

An Apache-2.0 Rust binary that governs every model call your agents make, with a scope note three paragraphs into its own README that most people will skim past.

The first diagram in Busbar's README is a single line of text, and it is doing more work than anything else on the page:

Applications and agents → Busbar → Models, MCP tools, and A2A agents

Three destinations on the right side. Three planes of an agent's reach, governed at one point. If you have spent any time worrying about what your agents actually touch, that line is the shape of the thing you want.

Three paragraphs down, in a block quote the GitHub renderer sets in grey, the project says which of the three exists today:

What this README demonstrates today: Busbar's model execution plane ... MCP tool governance and A2A agent trust use the same execution-boundary model.

Read that last sentence twice. "Use the same execution-boundary model" is a statement about architecture, not about shipping. It says the design extends. It does not say the code does.

I want to be clear that I think the block quote is to the project's credit. Most infrastructure projects put the roadmap in the diagram and let you find the gap in production. Busbar put it in a callout above the fold. But a scope note only helps the people who read it, and the diagram is what gets screenshotted into a slide about how the agent governance problem is solved.

What actually ships, and it is not nothing

Busbar is a single static Rust binary, Apache-2.0, MSRV 1.97, no interpreter or database or sidecar in the request path. You point an SDK at it by changing a base URL, and it becomes the place where model destinations, credentials, budgets, and evidence are decided.

The protocol work is the part I find most convincing. Six wire protocols, first class on both sides: OpenAI, OpenAI Responses, Anthropic, Gemini, Cohere, and Bedrock Converse. That gives 36 ingress-to-upstream pairs, and the README claims all 36. Same-protocol routes forward the original request bytes rather than re-serializing them, so an OpenAI call to an OpenAI backend is byte-identical to calling the provider directly. Cross-protocol routes translate the modelled fields, and the project claims system prompts, tool calls, structured-output schemas, and Bedrock tool-use blocks survive the hop in either direction.

The governance model is per-key and nested. Every virtual key binds to a budget group, groups nest a person under a team under the org, and a request is admitted only if every limit in that chain (request rate, token rate, concurrency, dollar budget) is under cap. The check and the charge happen as one atomic step before the call is forwarded, which is the difference between a budget and a report.

Credentials stay at the boundary. Apps get a Busbar token, Busbar holds the real provider key and signs upstream calls itself. A leaked app token can spend against its budget. It cannot walk off with your Anthropic key.

And busbar --validate parses your config and every provider reference, exits non-zero on anything wrong, with no server and no network and no state. That turns agent policy into a CI gate instead of a document, which is worth more than it sounds.

The gap that matters for agents

Here is the thing a model-plane boundary structurally cannot do, and it is worth understanding before you write "governed" on an architecture diagram.

Busbar sits on the HTTP path between your application and a model provider. It sees the request going out and the response coming back. It can reject that request, restrict it to certain models, reroute it, or rewrite the body outright.

It does not see what happens next.

When your agent reads that response and writes a file, Busbar was not in the path. When it runs a shell command, Busbar was not in the path. And when it calls an MCP server, there is a good chance nothing crosses the network at all. The MCP specification defines stdio as a standard transport, in which the client launches the server as a local subprocess and talks to it over pipes. No socket, no HTTP, no hop for any gateway to sit in. A network-path enforcement boundary cannot observe a stdio MCP server, not because Busbar has not built it yet, but because there is nothing on the wire to observe.

That is why the roadmap language for the tool plane is specific in a different way. The README lists what tool governance would mean: caller grants, approved schemas, budget enforcement, and drift quarantine for MCP tools. Those are real controls and someone should build them. Every one of them implies a component that sits somewhere other than the HTTP path a model call takes, or a transport decision (HTTP MCP servers only) that you would have to make on purpose across your whole fleet.

So the honest read of Busbar today: it is very good at the plane where your money and your credentials live, and silent on the plane where your filesystem lives. Both matter. They are not the same purchase.

Put this into practice

The lowest-friction version of this takes about ten minutes and does not require you to believe anything about the roadmap.

Run it as a passthrough in front of the one provider you already use. One binary, one YAML file, one base URL change in your app. Even with a single backend, three things improve the same day: the provider key leaves every app deployment, a runaway agent loop hits a cap instead of your invoice, and every call shows up with cost and latency attached.

curl -fsSL https://getbusbar.com/install.sh | sh

Mint per-project virtual keys for agent workloads specifically, with hard caps. Agents are the workload budgets were invented for. A human sending chat requests does not accidentally spend four figures overnight. A retry loop with a large context absolutely does, and the atomic check-and-charge is what stops it mid-flight rather than in the morning.

Put busbar --validate in CI before you put Busbar in production. A policy engine you configured badly fails closed at the worst possible moment, and this is the cheap way to find that out on a laptop instead of at 3am.

If you deploy to Kubernetes, the README's manifest pins getbusbar/busbar:1.5.3 and sets config: { locked: true }, which is what allows the read-only root filesystem. Read the note under it: the data plane has no auth chain until you turn on virtual keys. The project tells you this. Do not skip it because the manifest looks copy-pasteable.

Honest limitations

The performance numbers are the vendor's, and the vendor says so. Busbar publishes 83 µs added latency at p99, 67,059 requests per second, and 7.4 MiB idle memory against a field that has LiteLLM Python at 8,221 µs and 152 rps. Those come from onthebench.ai, which the site describes as a neutral field and which states plainly at the top of its own methodology page that it is "built and operated by the Busbar team, who are also one of the entrants." The harness is open source and re-runnable with an AWS account, they distinguish "we measured" from "their published," and they document a real list of ways their own numbers can be wrong. That is far above the industry floor. It is still a benchmark run by a competitor.

Two gaps in the harness are worth knowing since they come from the same page. The protocol support matrix, the thing that would independently verify the 36-pair claim, currently reads "no results/matrix JSONs are committed yet." And the correctness check verifies that the request reached the upstream in the right protocol without verifying the response was converted back correctly, which the page calls a real gap and lists as open.

Version drift shows up across the project's own materials. The README's performance figures are stamped 1.5.1 measured 2026-08-03, the site's performance page carries 1.5.5 figures measured 2026-08-21, and the Kubernetes example pins 1.5.3. None of those are wrong. They just mean you should read the version stamp under any number you plan to quote.

And the project's own list of things it will say against itself is worth repeating because it is accurate: LiteLLM's provider catalogue is much larger, the 36-pair coverage row counts wire protocols rather than providers, and LiteLLM Rust has overhead in the same class where the real difference is scope.

What to do with it

Busbar is a good answer to a question worth asking: where do the credentials, the budget, and the record of every model call live? If that answer is currently "in each app's environment variables and next month's invoice," a single Rust binary and a YAML file is an unusually cheap upgrade.

Just make sure the question you are answering is that one. The diagram at the top of the README describes a boundary around everything an agent reaches. The block quote under it describes a boundary around what an agent asks a model. The distance between those two is where the agent writes to your filesystem, and no amount of governance on the model call closes it.

Read the scope note. Then decide what you still need to build.

Sources: GetBusbar/busbar README; getbusbar.com performance; On the Bench methodology; GetBusbar/benchmarking.