Routing rules
A routing rule matches a request the same way a guardrail policy does (virtual_key_ids,
team_ids, models, metadata) and applies an action. Rules are evaluated in priority
order.
action.to is where the request actually goes. action.fallbacks is an ordered chain
tried if the primary target fails — a rewrite and a fallback chain in one rule, so a
cost-optimization rewrite doesn’t have to sacrifice reliability.
Aliases
An alias is a named target you can point multiple keys or rules at, so you can repoint “the model we use for X” in one place instead of editing every consumer.targets also accepts a weighted/keyed shape ({ "default": [...] }) for more complex
fallback sets — the same shape a budget’s fallbackAlias (see Budgets)
resolves against when a budget’s onExceed is fallback.
Both routing-rule targets and provider keys are currently scoped to the
openai provider
value in the schema — this is the CRUD surface for selecting a provider/model pair, not
a statement about which wire dialects the gateway accepts. The data plane itself parses
and speaks OpenAI, Anthropic, and Gemini request/response shapes; see
Architecture.Where next
Budgets
onExceed: "fallback" resolves against an alias, not a raw model string.Architecture
Where routing sits in the request lifecycle.