Models & routing
Models and policy routes
Choose a capability without hard-coding a provider
Requests may target an eligible direct model or a stable policy/* alias. Policy routes are the preferred contract when applications should remain portable across providers.
Direct model or policy alias
Choose a direct model when the exact model is part of the product requirement. Choose a policy alias when quality, latency, residency or another operating rule is the durable requirement.
- policy/frontier — prioritise eligible high-capability routes
- policy/fast — prefer responsive healthy routes
- policy/residency — constrain dispatch to approved providers and regions
- Direct identifiers remain subject to workspace eligibility
Set the model field
Use the standard model field. The Router resolves policy aliases before provider dispatch.
{
"model": "policy/frontier",
"messages": [
{"role": "user", "content": "Review this architecture."}
]
}Treat capabilities as route-specific
Tool use, vision and structured output depend on the eligible route and upstream model. Validate support before production use, even when the client exposes the field.
Keep product code portable
Stable aliases allow operating policy to change without redeploying each product. Product code should not contain provider selection logic that belongs at the Router boundary.