Skip to main content
Custom routers learn a model-selection policy for a specific workload. They are useful when a general cost, quality, or latency preference is not precise enough.

Create a router

Choose a name, router type, tradeoff, and two to eight candidate models. Candidates must be callable for the project and supported by the routing engine. Router types are:
  • Chat for conversational workloads
  • Code for software-development workloads
  • Custom for company-specific task families

Training lifecycle

1

Draft

A new or materially edited router is a draft. Candidate changes reset a trained router because the previous learned policy no longer describes the configured set.
2

Collecting samples

Relay pulls bounded examples from the project’s real traffic. Training accepts a sample size from 15 to 500 and can be narrowed by task identifier.
3

Judging quality

Relay scores candidate responses on the sampled requests. This executes model calls and therefore consumes provider spend.
4

Training

Relay builds the selector from the sampled and judged rows.
5

Ready

Training completed and the router artifact is ready. Readiness alone does not prove that every production request is using the router; verify activation and traffic records for the intended routing path.
The live pipeline can also report Failed, with an error for diagnosis. While active, progress includes sampled requests, judged requests, and trained rows.

Budget and maintenance

Set a training budget before starting a run. Router creation and route-evaluation quotas depend on the Relay plan. Editing the name alone preserves the learned candidate policy. Changing candidates or the tradeoff can require retraining. Delete a router only after traffic no longer references it.
The dashboard exposes router creation, training, polling, editing, and deletion. Production selection requires the routing path to reference the ready router; do not infer activation from the Ready badge alone.

Inspect routed traffic

Confirm the router identifier, selected model, and routing reason on actual requests.