Models & routing
Fallbacks
Recover inside the policy boundary
Fallbacks keep a request on eligible routes when an upstream becomes unhealthy or unavailable. They do not weaken workspace policy, residency or capability requirements.
Eligibility comes first
The Router considers only providers and models permitted by the resolved workspace policy. An unhealthy preferred route may fall back only to another eligible route.
- Residency restrictions remain in force
- Disallowed providers never become emergency fallbacks
- Required capabilities must still be satisfied
Request a stable alias
Applications request the policy outcome, not a hard-coded fallback chain.
response = client.chat.completions.create(
model="policy/frontier",
messages=[{"role": "user", "content": prompt}],
)Keep client retries bounded
A Router fallback and an application retry solve different problems. Retry only safe requests, use backoff and cap total attempts within the user-facing deadline.
Observe the outcome
Capture status, latency and available correlation metadata. Operational teams should be able to distinguish a successful fallback from a failed application retry.