Esc to close · ⌘K / Ctrl-K opens search anywhere
BharatRouter's pitch is uptime: the router switches seamlessly between the providers
you configure — same model across providers, or a different model
entirely when the first choice is out. Build a chain below, knock steps out, fire
real requests, and watch the x-br-provider badge show who actually served
each one. The request keeps succeeding; that's the point.
1 · Your API key — stays in your browser (localStorage), sent only to api.bharatrouter.com
No key yet? Create one — trial keys work (200 req/day, free).
2 · Fallback chain — first step is the primary; the router walks down on failure or when a step is knocked out
Mixes every pool: platform models (paid from your wallet), your own
BYOK models (typed as provider/model, once a key
is saved), and your own custom endpoints (BYOE) when signed in.
"Knocked out" steps are removed from the request — exactly what an outage looks like to
the router.
3 · Fire real requests
The same thing, from your code
The fallbacks field works on every request. Owners can also save a chain
org-wide — PUT /me/routing/<model> with the same JSON, or ask your
agent to call the set_fallback_chain MCP tool — so plain requests pick it
up with no code change.
Every provider has bad minutes — rate limits, regional incidents, model
deprecations. With one vendor, their bad minute is your outage. BharatRouter holds
live health for every route (circuit breakers, latency EWMAs) and walks
your chain in order, so a request only fails when every
step you configured is down — and you decide the order: own infra first for cost,
a fast inference cloud for the latency-critical fallback, a different model
entirely as the last resort. Set optimize: "auto" and the router
weighs uptime, latency and price per request instead.