docs/reference/RELAY_BACKEND_STRATEGY.md
OmniRoute now supports three relay modes for /api/v1/relay/chat/completions:
ts: Use the TypeScript relay in-process.bifrost: Force the Bifrost gateway.auto: Prefer Bifrost when available, fall back to TypeScript on failure.When you are running at high request rate (large number of tokens/day, near-constant throughput), the best strategy is to keep the fallback path explicit and fast so the hot path never blocks on a dead sidecar.
ts
bifrost
auto
9router and CLIPROXYAPI are both integrations that historically exposed compatibility paths for upstream providers.
If you are currently comparing 9router/CLIPROXYAPI:
OMNIROUTE_RELAY_BACKEND=bifrost.OMNIROUTE_RELAY_BACKEND=auto.The stable product boundary is the OmniRoute relay API, not the dashboard implementation. The Next.js dashboard may install, configure, and supervise local services, but request routing should enter through the relay API and hand off behind that boundary.
Long-term backend choices:
For a very high-throughput deployment, the default answer is therefore auto with Bifrost enabled: use the Go sidecar on the hot path while preserving the TypeScript fallback for success rate. Use bifrost only when strict sidecar-only behavior is more important than graceful degradation.
For sustained high RPM/RPS and strict success SLO:
auto with a practical cooldown and failure telemetry.OMNIROUTE_RELAY_BACKEND=autoBIFROST_ENABLED=1Sidecars should import provider metadata through the JSON-safe provider plugin manifest instead of depending on TypeScript executor internals. See Provider Plugin Manifest for the sidecar eligibility contract and migration phases.