Busbar is a single binary you run in your own infrastructure, sitting between your applications and every AI provider. One endpoint to route and fail over chat, embeddings, images, and audio across providers, enforce hard budget caps, provision or revoke access, and see every request’s cost, latency, and traffic.
No reviews yetBe the first to leave a review for Busbar
Maker
📌
Every serious AI application is becoming multi-model and multi-provider. You want Claude for one thing, GPT for another, a cheap model for classification, and a fallback when your primary is rate-limited. The moment you have more than one provider, something has to sit between your app and all of them. That something is a gateway.
The gateways that exist today mostly do two things. They flatten every provider to OpenAI’s shape, and they retry on failure. Both are quietly lossy. And none are a true AI Control Plane.
Flattening to OpenAI throws away what makes each provider worth using: Anthropic’s thinking blocks, Gemini’s safety settings, Bedrock’s tool-use envelope. You get portability by giving up capability.
Retry-on-failure is error handling, not failover. The call throws, and then something retries, after your user already felt the stall. And a naive retry can hammer a provider that’s already down.
Neither is wrong, exactly. They’re just not enough once the gateway is load-bearing infrastructure.
What I’m building
Busbar is you AI Control Plane
Lossless translation, both ways. Speak any of six wire protocols in, any provider out, through a superset intermediate representation, so native features survive the hop instead of being flattened away.
Failover inside the request. Reroute across providers before the client sees a byte, even mid-stream, within a deadline and hop budget. The user never sees the stumble.
A circuit breaker that knows whose fault it is. Classify each failure (provider outage, your bad request, context-length, auth or billing) and treat each differently, instead of retrying into a wall.
One static Rust binary. No Python sidecar, no interpreter, no GC in the request path. Your keys, your network, your data path.
Why me, why now
Multi-model is going mainstream this year, and the control plane is where the reliability and portability promises get made or broken. I think the right architecture is reliability-first and lossless, not OpenAI-shaped and retry-based, and I’d rather build that from the metal up than bolt it onto an interpreted proxy.
Report
Dropped the binary on a small box and pointed two apps at it — the per-request cost breakdown showing up in the same log line as latency was a nice surprise, made tracking which model was actually eating the budget way easier than my old spreadsheet.
Report
Maker
@glzar617617 Great to hear! Thank you for testing it out! You made it sound as easy as it was designed to be
Report
Dropping in my own API keys took about two minutes and the cost dashboard finally showed me what I was actually paying for across providers. The failover switching feels solid too.
Dropped the binary into a test setup and was routing between three providers within a few minutes. The cost tracking per request is genuinely useful, especially catching which embeddings calls were quietly adding up.
Ran it locally as a single binary and was surprised how clean the cost-per-request view is. Nice that it actually enforces hard budget caps without extra setup.
Dropped the binary on a small box and pointed two apps at it — the per-request cost breakdown showing up in the same log line as latency was a nice surprise, made tracking which model was actually eating the budget way easier than my old spreadsheet.
@glzar617617 Great to hear! Thank you for testing it out! You made it sound as easy as it was designed to be
Dropping in my own API keys took about two minutes and the cost dashboard finally showed me what I was actually paying for across providers. The failover switching feels solid too.
@sebahattinjfbl Good to hear! Thank you for checking it out
Dropped the binary into a test setup and was routing between three providers within a few minutes. The cost tracking per request is genuinely useful, especially catching which embeddings calls were quietly adding up.
@ozcifttaha29558 Love it!
Ran it locally as a single binary and was surprised how clean the cost-per-request view is. Nice that it actually enforces hard budget caps without extra setup.
@hlya133826 Thank you!