Create Routing Rules
Routing rules determine which providers handle incoming requests and in what order. This tutorial walks you through creating a routing configuration using the priority strategy, then testing it with an API call.
Prerequisites
- At least one provider configured and healthy (see Set Up Your First Provider)
- Admin dashboard access
Step 1 — Navigate to the Routing Page
- In the sidebar, click Routing.
- The routing list shows all routing configurations for your tenant, grouped by capability (chat, embeddings, audio, images, etc.).
- Click Create Routing Config.
Step 2 — Set Basic Configuration
- Name — Enter a descriptive name, for example
Chat Primary Route. - Capability — Select the request type this config handles. Choose
chatfor chat completion requests. - Strategy — Select
priorityto start. This strategy tries providers in a fixed order, falling back to the next on failure. See Routing Strategies for all ten options. - Enabled — Toggle on.
- Is Default — Toggle on if this should be the fallback config when no other routing config matches.
Step 3 — Add Provider Entries
Each route entry maps a provider to this routing configuration.
- Click Add Route.
- Provider — Select your provider from the dropdown (e.g.,
openai-prod). - Model ID — Enter the default model for this route, for example
gpt-4o. - Priority — Enter
1(lower number = higher priority). This provider will be tried first. - Weight — Enter
1. Weight is used by theweightedstrategy; forprioritystrategy it has no effect. - Enabled — Toggle on.
To add a fallback provider:
- Click Add Route again.
- Select a second provider (e.g.,
anthropic-prod). - Set Priority to
2. This provider is tried only if the first fails. - Set Model ID to the equivalent model on this provider, for example
claude-sonnet-4-20250514.
Step 4 — Configure the Fallback Chain (Optional)
The fallback chain provides a last-resort option after all route entries have been exhausted.
- Scroll to the Fallback Chain section.
- Add a provider entry with a model ID. This provider is appended after all strategy-ordered routes.
- You can also enable a Local Fallback (e.g., an Ollama instance) for complete offline resilience.
The routing service detects circular fallback chains and breaks them automatically.
Step 5 — Set Capability Filters
If a specific model is requested by the client (via the model field in the API request), the routing service filters route entries to only include providers that have a matching ModelConfig with that model ID enabled. Providers without the requested model are skipped.
To ensure correct filtering:
- Verify each provider in your routes has the relevant models registered in the Models section.
- Models must be marked as
enabledto be eligible.
Step 6 — Test with an API Call
Send a test request to verify routing works:
curl -X POST http://localhost:3000/v1/chat/completions \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o", "messages": [{"role": "user", "content": "Hello"}] }'The response includes a metadata.providerChain array showing which providers were attempted:
{ "metadata": { "providerChain": [ { "provider": "openai-prod", "model": "gpt-4o", "attempted": true, "result": "success", "latencyMs": 842 } ] }}If the first provider fails, you will see multiple entries in the chain showing the failover.
How the Routing Service Works
- Load config — Finds the routing config matching the tenant, capability, and enabled state.
- Load providers — Fetches all
ProviderConfigdocuments referenced in the routes. - Filter — Removes providers that are disabled, unhealthy, or not in the tenant’s allowed-providers list.
- Apply strategy — Orders the remaining candidates using the selected strategy.
- Append fallbacks — Adds fallback chain entries after the strategy-ordered list.
- Cache — Results are cached in memory for 60 seconds with jittered TTL to prevent thundering herd.
Next Steps
- Explore the Routing Strategies architecture doc for details on all ten strategies
- Configure Budget Management to control costs across providers