AI Router & LLM Router: How Mizan's Routing Works

The request flow

Your application sends a request to Mizan's API instead of directly to OpenAI, Anthropic, or another provider — the same request shape you're already using, since Mizan is drop-in compatible with the OpenAI, Anthropic, and Vercel AI SDKs. Change your base URL, and you're live; no rewrite required.

From there, Mizan decides which model actually handles the request. That decision happens on every call, not once at setup time — which is what makes it routing rather than a static integration.

What decides where a request goes

• Data residency — whether the request is allowed to leave a given jurisdiction, and which providers satisfy that
• Quality — which model performs best for the type of task (a coding request and a summarization request don't need the same model)
• Cost — provider pricing, plus whether a cached response can answer the request without a new inference call at all
• Latency — response time, including the effect of how far a provider's infrastructure is from where the request originates

You can route on one of these dimensions or combine them — the same request that needs to stay within a given jurisdiction can still be routed to whichever compliant model is fastest and cheapest, rather than defaulting to a single fixed option.

One key, every provider

A single Mizan API key calls OpenAI, Anthropic, Gemini, Bedrock, and other providers you connect — you change the model name in your code, not your integration. Behind that key: your wallet balance, your usage across every provider, and (where you've set them) your routing rules.

Caching, so you don't pay for the same work twice

When a request repeats — the same prompt, or a step in a multi-step agentic workflow that's already been computed — Mizan can return the cached response instead of paying for new inference. This is a cost lever, but it's also a latency one: a cache hit is faster than any model call.

Where locally hosted models fit in

Mizan's routing extends to locally hosted models in Saudi Arabia where they're available through the region's infrastructure providers. That landscape — national initiatives, regionally hosted model deployments — is still developing. Mizan's architecture treats "which model handles this" and "where is that model physically hosted" as two answers to the same routing question, so as local options expand, they become additional routing targets rather than a separate integration to build.

Reliability and fallback

If a provider is unavailable or rate-limited, routing can fall back to an alternative that meets the same requirements — including the same residency constraints, so a failover never silently sends a request somewhere it wasn't allowed to go in the first place.