Fallback
kineticRouter’s fallback mechanism automatically switches to alternative models when the primary model is unavailable, ensuring your service stays uninterrupted.
How It Works
- The request is sent to the primary model
- If the primary model returns an error (5xx, timeout, rate limit, etc.)
- Alternative models from the fallback list are tried in order
- The first successful response is returned
Per-Request Fallback
Configure fallback for individual requests using the provider.fallback parameter:
The Anthropic-native route is planned and its configuration is shown only as a reference. This example is intentionally not copyable in its current display state.
The Anthropic-native route is planned and its configuration is shown only as a reference. This example is intentionally not copyable in its current display state.
Global Fallback Configuration
Configure a global fallback strategy in the kineticRouter Console without specifying it in each request:
- Log in to the kineticRouter Console
- Go to Settings → Routing Policy
- Configure the default fallback model list
Per-request fallback parameters override the global configuration.
Fallback Triggers
The following conditions trigger a fallback:
| Condition | Description |
|---|---|
| HTTP 5xx | Server error |
| Request timeout | Model response timeout |
| 429 Rate limit | Upstream model rate limit reached |
| Model unavailable | Provider maintenance or decommission |
The following conditions do not trigger a fallback:
| Condition | Description |
|---|---|
| HTTP 4xx (except 429) | Client errors require fixing the request |
| Content filtering | Model refused to generate content |
Combining with Routing
Fallback can be combined with provider routing:
The Anthropic-native route is planned and its configuration is shown only as a reference. This example is intentionally not copyable in its current display state.
Recommended Fallback Configurations
For recommended models, see the Model Marketplace .
Best Practices
- Choose fallback models with similar capabilities — Ensure consistent output quality after fallback
- Use cross-provider fallbacks — Avoid all models being down from the same provider
- Set 2-3 fallback options — Sufficient to handle most failure scenarios
- Monitor fallback frequency — Frequent fallbacks may indicate the need to switch your primary model