> ## Documentation Index
> Fetch the complete documentation index at: https://oximy.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom routers

> Create, train, inspect, and maintain workload-specific model routers from project traffic.

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Judging quality">
    Relay scores candidate responses on the sampled requests. This executes model calls and therefore consumes provider spend.
  </Step>

  <Step title="Training">
    Relay builds the selector from the sampled and judged rows.
  </Step>

  <Step title="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.
  </Step>
</Steps>

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.

<Note>
  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.
</Note>

<Card title="Inspect routed traffic" icon="list-tree" href="/docs/relay/traffic-runs-signals">
  Confirm the router identifier, selected model, and routing reason on actual requests.
</Card>