Model routing

Declarative routing rules with transparent, per-response decisions — never a silent model swap.

Routing rules let you say what you want (lowest cost, lowest latency, a fallback chain) without hard-coding which model handles every request. Rules can match on cost, latency, or token count, or act purely as fallbacks.

Create a Routing Rule

Go to Routing in the dashboard.
Select New rule.
Choose what the rule matches on: cost, latency, or token count.
Order your candidate models — Relixr tries them in sequence, falling through to the next on failure.
Select Save rule.

Every response — streaming or not — carries structured routing metadata, so you always know exactly which model answered and why.

{
"relixr": {
  "request_id": "req_...",
  "route": {
    "rule_id": "rule_...",
    "rule_name": "cost-optimized",
    "selected_model": "gemini-2.0-flash",
    "selected_provider": "google",
    "candidates": ["gpt-4o-mini", "gemini-2.0-flash"],
    "fallbacks_attempted": [],
    "selection_reason": "lowest_cost"
  },
  "cost": {
    "estimated_usd": 0.00042,
    "final_usd": 0.00039,
    "breakdown": {
      "provider_usd": 0.00030,
      "margin_usd": 0.00006,
      "platform_usd": 0.00003
    },
    "balance_remaining_usd": 47.23
  },
  "edge": {"colo": "NBO", "latency_ms": 12}
}
}

When no rule matches, route.rule_id is "default" and selection_reason documents the fallback strategy that was used.

Tip:

Set up a fallback chain, not just a single preferred model — pin your primary model, and list one or two cheaper or faster alternatives as fallbacks. If the primary provider has an outage or a spike in latency, your requests keep flowing instead of failing outright.

A routing rule tries its preferred model first and falls through its candidate list until one succeeds.

Next steps

Guardrails

Enforced before routing, at the edge.

Presets

Bundle a model choice with a system prompt.

← Errors Guardrails →