ARBR 为开发者提供统一的 AI 栈控制层，通过 OpenAI 兼容接口实现模型路由、治理与观测，帮助管理复杂 AI 调用。
热门评论
PH 用户
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.
shadow test, guarded canary, then rollback if quality drops. thats a lot of gates for one model swap. what actually trips the rollback, an eval score or a person
PH 用户
Congrats! I like that ARBR focuses on the workload rather than pushing you toward a particular model. Different tasks obviously need different things.
PH 用户
I like the idea of having one layer to handle model routing instead of building all of this logic into every application.
PH 用户
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.
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/
tasks to different models seems like a pretty sensible approach.