Skip to main content

​
Overview

Routing rules let you control where your AI requests go based on their context — feature, task type, provider, or model. Set a rule once in the dashboard. Every matching request is routed automatically from that moment forward.
Your code changes nothing. Lectr handles it at the proxy layer.

​
How it works

When a request arrives at Lectr, the routing engine evaluates your rules in priority order.
Rewriting means replacing the model and/or provider before the request is sent upstream. If no rule matches — or if rule evaluation fails — the request is forwarded unchanged. Passthrough is always the fallback. Routing cannot block or degrade a request.

​
Rule conditions

Each rule can match on any combination of four conditions. All specified conditions must match — AND logic. Unset conditions are wildcards. Examples:

​
Creating a rule

Go to Rules in the dashboard sidebar. Click New rule and fill in:
  • Name — a label you’ll recognise in logs (e.g. “Downgrade classifiers to mini”)
  • Conditions — one or more of: feature tag, task type, provider, model
  • Target provider — where to send matching requests
  • Target model — which model to use
Save. The rule takes effect immediately — no restart, no deploy.

​
Priority

Rules are evaluated in ascending priority order. Priority 1 is evaluated first. The first matching enabled rule wins — evaluation stops.
Reorder rules by dragging them in the Rules list. The new order takes effect immediately. No two enabled rules can share the same priority. If you set a priority that’s already taken, the dashboard shows an error — it won’t silently reorder.

​
Toggling rules

Rules can be enabled or disabled without deleting them. A disabled rule is never evaluated — it’s invisible to the routing engine. Useful for:
  • Testing a rule without committing to it
  • Temporarily disabling routing during an incident
  • Keeping rules around for future use without activating them

​
Seeing rules in action

Every request log shows whether a routing rule was applied and which one. In the Requests table:
When model_actual differs from model_requested, the substitution is clearly visible. Routing coverage: The dashboard overview shows what percentage of your traffic is being routed versus passing through:
Unrouted traffic indicates requests with no matching rule — which may be intentional.

​
Common rule patterns

Downgrade all classification tasks to a cheaper model
Route all Anthropic traffic to a specific model
Migrate away from a deprecated model
Route a specific feature to a different provider
Combine feature and task for precision routing

​
What routing changes

When a rule matches, Lectr:
  • Rewrites the model field to the target model
  • Routes the request to the target provider
  • Normalises authentication headers automatically
Routing does not change:
  • Your prompts or messages
  • Any other request fields
  • The response format — it remains identical to provider output

​
Routing and recommendations

The recommendation engine surfaces opportunities to reduce cost. Routing rules let you apply those optimizations instantly without changing your code. The workflow:

​
Safety guarantees

Routing is designed to be safe for production use.
  • No matching rule → request is forwarded unchanged
  • Rule evaluation error → request is forwarded unchanged
  • Provider error → passed through unchanged
Routing only affects where the request is sent — not how it behaves.

​
Reference

Condition matching:
  • Exact string matching (provider is case-insensitive)
  • All conditions must match (AND logic)
  • Unset conditions act as wildcards
Priority:
  • Lower number = higher priority
  • Priority 1 is evaluated first
  • No duplicate priorities allowed
Cache:
  • Rules are evaluated from an in-memory cache
  • No database on the hot path
  • Cache updates immediately when rules are created, edited, toggled, or deleted
Passthrough:
  • No match = unchanged request
  • Routing never blocks execution

​
FAQ

Immediately. When you save, toggle, or delete a rule, the routing cache is reloaded server-side within milliseconds. The next matching request uses the updated rules.
The provider returns an error, which is passed through unchanged.
No. Evaluation stops at the first match. Only the highest-priority matching rule is applied.
Yes. If your client is configured for OpenAI but a rule routes to Anthropic, Lectr handles the provider switch — including auth header normalisation — automatically. Your client doesn’t need to know.
Yes. Routing works identically for streaming and non-streaming requests.
No hard limit. Most teams use fewer than 20 rules.