A Model Router picks the right model for each request instead of you hard-coding one — you give it a pool of candidate models and a strategy for choosing between them, then call it like you'd call any single model.

Overview

Model Router is in the AI Agents section of the side-nav, next to Models. Where the Model Registry brings an existing external model under observation, a router is itself something you point your traffic at: you give it a pool of candidate models, a strategy for choosing between them, and a fallback model for when nothing else applies — then you call the router the way you'd call any single model, and it decides per request.

The router list shows each router's Router name, Strategy, Models (pool size), Last request, Requests (30d), Cost (30d), P95 latency (30d), and Created by. Row actions are Edit Router and Delete. Empty state: "No routers" — "Create a router to pick the right model for every request."

Creating a Router

New Router opens an editor with five parts (the editor's save button reads Create Router):

Details — a Router Name (e.g. "Support triage") and a Description of what it fronts and how traffic should split across it.
Models — Add Models builds the router's pool from a searchable list of candidate models (each row shows Modality, ELO, Context, Price, and 30-day Requests/Spend). This pool is load-bearing — everything below can only name a member of this pool: rules, split shares, and per-model notes can only target a model you've added here. Until the pool has at least one model, the strategy section shows an empty state instead of its controls.
Fallback — the one answer to "nothing else applies", across every strategy — the model used when the router can't decide or its pick is unavailable. You can't pick a fallback before adding a model. The cheapest priced model in the pool is pre-selected; change it if needed.
Strategy — pick how the router chooses per request (see below).
Stickiness — whether a pick is made for each request, or once for the session. Per query: each request is routed on its own, so a conversation can switch models between turns. Per session: the first pick holds for the whole session; if that model is down, it moves to the fallback.

The Four Routing Strategies

Strategy	How it decides
Rules	"Conditions you write. Predictable, auditable." You add named rules, each with one or more conditions and a target model to Route to; rules are evaluated top-to-bottom and the first match is picked. Every rule needs at least one condition and a target model before it can be saved. Rules can be reordered, renamed, expanded/collapsed, and deleted.
Smart	"Best quality per dollar, per request." One control, Optimise for — a slider from Cheapest to Balanced to Best quality — sets how much cheaper a candidate has to be before the router trades quality for it.
Split	"Fixed traffic share, regardless of content." Set a % share for each pool model; the fallback model's row is read-only and automatically takes whatever is left. Shares can't total more than 100% (you'll see "Shares add up to N% — they can total at most 100%").
LLM Routing	"A model reads the request, then picks." You choose a Router Model (a judge model, picked from your workspace's text-generation models generally — not limited to the router's own pool), optionally toggle Include Reasoning (records why the judge picked on every span; adds a little latency but tends to improve the pick), write free-text Routing Instructions (e.g. "Pick the cheapest member that can do the job well"), and add a short note per pool model under When to use each model. Choosing an expensive judge model shows a cost warning, since the judge reads every single request the router handles.

Testing a Router Before Saving

The editor's Test routing panel runs a real dry run against your current, unsaved draft: type a sample prompt (e.g. a support message) in Prompt and select Run Test. It shows which model was picked and the Reason (a matched rule, Smart routing, the traffic split, the LLM judge, or Fallback — meaning nothing else matched), plus one extra line depending on the strategy: the matched rule's name when the reason is a rule, a confidence score when it's Smart, or the judge's own explanation when it's LLM Routing.

Note: A rule's exact position in the list, how long the decision took, and the individual signal values judged are shown later, on a routed request's own record — not in this dry run. Because the cheapest priced pool model is pre-selected as the fallback, Run Test is ready once the pool has a model; if no model in the pool has a price, pick a fallback yourself first. If your strategy is LLM Routing, you also need a judge model picked first.

A Saved Router's Detail Page

Four tabs:

Tab	What it shows
Overview	A traffic strip (Requests, Spend, Saved vs baseline, P95 latency) over a chart; a per-model table (Model, Tokens, Price, Requests, Share, Cost, Latency) showing how traffic actually split across the pool; a Details card (Strategy, Stickiness, Last updated, Fallback, Cost baseline).
Analytics	A stat strip (Requests, Cost, P95 latency); Traffic and spend (what routing actually cost against the same traffic on the baseline model); Routing mix (each model's share of requests over time); Latency (the router's decision time against the routed or baseline model, at P50/P90/P95); Reroutes and errors (share of requests that didn't complete on their first-choice model — Rerouted, Timed out, Rate limited, Failed).
Linked assets	Every agent and automation in your workspace currently pointed at this router as its model.
Observability	The router's own spans, same as any registered model's Observability tab.