Routing Rules are an Enterprise-only feature. When an active Policy with a model is matched, Routing Rules are bypassed. Routing Rules apply only when there is no active policy, or when the matched policy has no model configured.
How routing rules work
When a request arrives at the AI Router, the router evaluates all active routing rules in ascending priority order. The first rule whose CEL expression matches the request determines the target model. If no rule matches, the model from the original request payload is used. Example: A request arrives withmodel: "openai/gpt-4o". A routing rule with condition model.contains("gpt-4o") and target openai/gpt-4o-mini is the highest-priority matching rule. The router redirects the request to gpt-4o-mini, regardless of what the caller specified. In CEL expressions, model refers to the model value from the request payload.
Visibility
- Global rules: visible to workspace administrators only.
- Project rules: visible to all members of the scoped project.
Creating a routing rule
From the Routing Rules list, click Add New Rule. A panel opens on the right with the following fields.
General
| Field | Description |
|---|---|
| Rule Name | A display name for the routing rule. |
| Description | Optional context for administrators. |
| Enable Rule | Toggle to activate or deactivate the rule. When enabled, the rule is active and applied to matching requests. |
| Project | Scope of the rule. Global (all projects) applies the rule workspace-wide. Selecting a specific project restricts it to requests within that project only. |
Providers and traffic weight
Defines the target model or models to route matching requests to. This section is identical to the model configuration in Policies. Models sets the distribution strategy for the target:- Fallback: Route to the primary model. If it fails, try the next in the list.
- Weighted: Split traffic across models by percentage weights.
- Round Robin: Rotate evenly across all configured models.
Priority
A numeric value that sets the evaluation order for this rule. Rules are evaluated in ascending order: priority0 is evaluated before priority 10. The first matching rule wins.
Rule Builder
The Rule Builder constructs the CEL expression that determines whether this rule applies to a given request. Conditions are built from values present in the request headers and body. Clicking Add opens a dropdown with the following condition types:| Condition | Description |
|---|---|
| Header | Match on a request header name and value. |
| Model | Match on the model specified in the request payload. |
| Identity | Match on the identity making the request. |
| Metadata | Match on metadata attached to the request. |
| Project | Match on the project scope of the request. |
and. Groups themselves can be joined with either and or or. Select the operator between groups to control how they combine. Each condition can be removed with .
The generated CEL expression is shown read-only in the CEL Expression Preview below the builder.