How Arbitex Routes Every AI Request to the Right Provider
Every AI call your organization makes passes through a decision: which model, which provider, under what conditions. Routing is where that decision lives.
Most enterprises using AI today have more than one model provider. A team might be running OpenAI for one application, Anthropic for another, and an internal model for a third. The security team may have opinions about which teams can use which providers. The finance team definitely has opinions about what each team is allowed to spend.
Without a central routing layer, those decisions — which model, which provider, which teams, how much — happen in individual applications, with no central record and no unified enforcement. Governance is a spreadsheet and a prayer.
Routing is Arbitex’s answer to that problem. It is the first stage every AI request passes through, and it does more than forward a call.
What Routing Actually Does
When an application sends a request to the Arbitex Gateway, Routing determines three things before anything else happens:
Which model and provider receives the request. Arbitex connects to 9+ providers — including OpenAI, Anthropic, Google, and major cloud-hosted options — plus a bring-your-own-endpoint option for organizations running their own models. Your security team defines which models each team is permitted to use. Routing enforces those decisions on every call. A team that is not authorized to use a particular model does not get routed to it, regardless of what they ask for.
Which routing mode applies. Not every AI call is a simple question-and-answer. Arbitex supports three routing modes:
- Single — one request, one provider. The standard mode.
- Compare — the same request is sent to multiple providers simultaneously, and all responses are returned side by side. Useful for evaluating which model performs better on a task, or for building confidence before committing to a provider.
- Summarize — the request is sent to multiple providers, and Arbitex aggregates the responses into a single output.
What happens if the first choice is unavailable. Providers have outages. Models go down. Automatic health monitoring in Arbitex tracks the status of each connected provider and, when one becomes unavailable, moves traffic to the next provider in the configured fallback chain — without any change to the application code and without interrupting service.
The Integration Is One Line
One of the more practical aspects of Routing is that adopting it does not require rewriting your AI applications. Arbitex exposes an API that is compatible with the standard format your existing AI libraries already speak. Changing the endpoint your application points at is the entire integration:
base_url = "https://api.arbitex.ai/v1"
That is it. Your existing code continues to work. Arbitex adds governance — routing, inspection, policy enforcement, and logging — without touching the application.
What Routing Is Not
It is worth being precise about what Routing does and does not do, because the category of “AI gateway” covers a wide range of products with very different capabilities.
Routing in Arbitex is not a load balancer optimizing for latency or cost. It is a policy-governed decision. Which teams can use which models is a governance question, set by the security team, enforced by the gateway. The routing decision is auditable: every request produces a log entry that shows which provider received it, under which policy, at what time.
Routing is also not the complete picture. The request entering the gateway in Routing still needs to be inspected before it reaches the model — which is what the next stage, Protection, handles.
Why This Matters to a Security Leader
For a CISO, the value of Routing is control and evidence.
Control: The security team sets policy for which models are authorized. Those policies are not suggestions in a wiki — they are enforced at the wire. A developer cannot route a request to a model that is not on the approved list, because the gateway does not allow it.
Evidence: Every routing decision is logged. When an auditor asks which AI providers your organization used in Q4, or which teams made requests to which models, the audit log in Arbitex has the answer. Not aggregated, not approximate — a complete record of every request routed, with the policy that governed it.
For a security leader who needs to answer “are our AI interactions governed?” — Routing is where governance begins.
Part 2 in this series covers what happens after Routing: how the Protection stage examines the content of every request before it reaches the model.
Protection — what happens to your data →
See how Routing works in a demo → Read about the full platform →