Multi-provider failover

Routing rules that survive a provider outage without a code change or a redeploy.

A single-provider outage is the most common way an AI feature goes down in production — and it's also the easiest one to design around, because Relixr routes by rule, not by hardcoded model id.

Designing the fallback chain

• Order by capability parity, then cost. Fallbacks should be models capable of handling the same task, not just cheaper ones — a fallback that gives worse answers than the primary is a silent quality regression, not resilience.
• Keep the chain short. Two or three candidates is enough for almost every workload. A long chain mostly adds latency to the failure path without meaningfully improving availability.
• Let the response tell you what happened. Every response carries relixr.route.fallbacks_attempted and relixr.route.selected_model — log these fields so an incident review can see exactly when and how often failover triggered, without needing provider-side status pages.
• Test the fallback path deliberately. A fallback chain that's never exercised until a real outage is a fallback chain you don't actually trust yet. Point a rule's primary at a model you don't have access to in a staging workspace and confirm the fallback fires.

Applying this

1. Create a routing rule with your preferred model first and one or two capability-equivalent alternatives from a different provider.
2. Read relixr.route off responses in your logging pipeline, not just the model output — it's the source of truth for which provider actually served the request.
3. Alert on a sustained rise in fallbacks_attempted — that's your earliest signal of a provider-side incident, often before the provider's own status page updates.