AI stacks are getting more complex with more models, providers, costs, and decisions. ARBR gives your applications one control layer across your AI stack. Connect once through an OpenAI-compatible endpoint to route, govern, observe, evaluate, and deploy across AI models. Open source, MIT-licensed, provider-neutral, and self-hosted.
Hey Product Hunt 👋
We built ARBR because teams can see how much their LLMs cost, but their logs rarely answer the harder production question:
Which workloads can safely move to a different model, what evidence supports the change, and did the result hold after rollout?
ARBR closes that loop.
It observes workloads, surfaces model-switching opportunities, builds evaluation datasets from representative traffic, and compares candidate models across quality, cost, latency, format adherence, and critical failures.
The final decision remains human-controlled. Teams can approve a recommendation, introduce it through shadow testing or a guarded canary, measure the realized savings, and roll back if quality drops.
ARBR is:
▪️ Self-hosted and provider-neutral
▪️ OpenAI-compatible
▪️ Open source under the MIT License
▪️ Usable as a standalone gateway or above LiteLLM
▪️ Built around explicit, auditable, and reversible routing decisions
Explicitly pinned models stay pinned. When an application uses model: "auto", ARBR follows only the rules and policies that the team has enabled.
You can explore the complete workflow in demo mode without adding a provider key, then connect your own traffic when you are ready.
We would genuinely value feedback from teams running LLM workloads in production:
▪️ Is the evidence sufficient for you to approve a model change?
▪️ Which governance or deployment controls are missing?
▪️ Which provider integrations should we prioritize next?
Deploy it, break it, open an issue, or tell us where the workflow falls short.
GitHub: https://github.com/project-arbr/...
Docs: https://projectarbr.org/docs/
Report
Cost + performance is going to be a big challenge as AI usage grows for us. Routing different
tasks to different models seems like a pretty sensible approach.
@shivani_bakhetia Exactly! That’s the problem we built ARBR around. Different tasks need different models, and routing them intelligently can make a big difference to both cost and performance.
Report
I like the idea of having one layer to handle model routing instead of building all of this logic into every application.
ARBR
Cost + performance is going to be a big challenge as AI usage grows for us. Routing different
tasks to different models seems like a pretty sensible approach.
ARBR
@shivani_bakhetia Exactly! That’s the problem we built ARBR around. Different tasks need different models, and routing them intelligently can make a big difference to both cost and performance.
I like the idea of having one layer to handle model routing instead of building all of this logic into every application.
ARBR
@amit_gyde Yes, Amit, having a dedicated layer gives you room to test and switch things around without making the app itself more complex.