> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orq.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Routing Rules | AI Router
> Use CEL-based routing rules to redirect AI Router requests to different models based on request attributes, evaluated in priority order.
Feature available with the [Enterprise Plan](https://orq.ai/solutions/enterprise)
Routing Rules are CEL-based conditions that intercept requests to the [**AI Router**](/docs/router/using-the-router) and redirect them to a different model when matched. Rules are evaluated in priority order and the first matching rule wins. No further rules are evaluated after a match.
## Use cases
Routing rules are most useful when you need to redirect or distribute traffic at the router level based on request attributes, without modifying any calling application.
Intercepts support bot requests addressed to one model and silently redirects them to a cheaper one, so the calling application needs no changes to benefit from the cost saving.
Two rules at the same priority split document traffic by complexity: simple documents go to a lighter model, complex ones go to a more capable model, all based on metadata attached to each request.
Matches requests that include a file attachment and routes them through an ordered list of models that all support native file input, so the request succeeds even if the first model is unavailable.
A low-priority catch-all rule that redirects traffic to an alternative set of models whenever primary providers are unavailable, keeping requests flowing without manual intervention.
Distributes requests in round-robin mode across multiple endpoints serving the same model, balancing inference load across providers without any changes required on the caller side.
## 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 with `model: "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.
To distribute traffic across providers at the request level without organization-wide rules, use the `load_balancer` parameter directly in your API calls.
## 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. |
### 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**](/docs/router/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.
Click **Add** to add a target model.
### Priority
A numeric value that sets the evaluation order for this rule. Rules are evaluated in ascending order: priority `0` 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. |
You can also click **Add group** to nest conditions into a logical group. Multiple conditions within a group are joined with `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.