Routes, failover and receipts
Understand route eligibility, ordered fallback and the evidence behind every switch.
On this page
Virtual models and ordered chains
A virtual model such as conflux/code names an ordered chain. Each hop selects a provider and upstream model. Reorder hops in Models; capability rules skip models that cannot support requested tools or images. Reasoning effort is configured per virtual model, not separately on every hop.
Route Inspector explains eligible providers, available keys, cooldowns, quota evidence and capability skips. Inspecting a route does not generate output, consume inference quota or advance key rotation.
What triggers a switch
The router can fall back on quota signals, rate limits, invalid upstream credentials, server errors and timeouts before substantive output is committed. Malformed successful JSON is also rejected. A committed stream interruption returns an explicit failure because replaying partial output is unsafe.
Consecutive failures open a circuit. After cooldown, one inference request claims the recovery probe. Reported reset windows are respected. Optional scheduled catalog probes are separate and do not clear exhausted credentials or circuits.
Read the failover receipt
- Open Usage Logs and expand View receipt on a request.
- Read each attempt: provider, model, HTTP status, error class, latency and recorded usage. Unknown or estimated usage is disclosed.
- Review degradation steps such as bounded retry or context trim.
- Download JSON for a shareable, owner-scoped record. Request bodies, tool arguments and provider secrets are excluded.