Per-request routing decisions
The request is classified before model selection. Classification determines provider eligibility. Price and quality then rank eligible providers.
- Per-request
- Decision granularity
- Named
- Refusal reasons
- Reproducible
- Selection record
Constraint, not generic error
Design
How this part works
Payload classification
The payload is inspected for the signals that determine eligibility: declared jurisdiction, data class, modality, context length, tool use and streaming requirement. A request that has no eligible provider fails, rather than being reclassified to fit an available one.
Provider eligibility
Jurisdiction rules remove providers from the candidate set. Price, latency and cache state then order whatever remains. Endpoints outside the boundary are ineligible, regardless of price.
Reproducible decision records
Each response carries the reason its provider was selected: the policy that applied, the eligible candidate set, and the signals that ordered them.
Refusal behaviour
When no eligible provider can serve a model, the request fails with a specific error naming the constraint. Silent degradation to a global endpoint is not an available code path.
Comparison
Boundary-first routing
Example gateway without policy
- Provider list is a preference order
- Fallback widens the pool when a region is degraded
- Selection is logged as a provider name
- Refusals look like failures
- Jurisdiction removes providers before selection begins
- Fallback is confined to the eligible set
- Selection is logged with the policy that produced it
- Refusals are a documented outcome
Elsewhere on the platform
Other platform features
Start