> ## 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.

# Relay

> Route each AI request to the least expensive model that is capable enough for the work.

Relay decides which model should handle each request. It routes per turn rather than locking an entire session to one model, using company-defined choices around cost, quality, latency, policy, and fallback behavior.

A gateway passes traffic. Relay provides the routing intelligence. It can also operate as the gateway itself.

## Choose how Relay fits

| Mode             | Request path                                                                 | Use it when                                                       |
| ---------------- | ---------------------------------------------------------------------------- | ----------------------------------------------------------------- |
| Relay gateway    | Relay receives and executes the request                                      | You want an OpenAI-compatible gateway with routing built in       |
| Existing gateway | Relay adds a decision layer while your gateway remains in the execution path | You want to preserve the gateway and controls you already operate |
| Observe          | Your existing request path remains unchanged                                 | You want traffic analysis and reporting before changing execution |
| Route-only       | Relay returns a model decision and your infrastructure executes it           | You want full control of provider execution                       |

<CardGroup cols={2}>
  <Card title="Start with the gateway" icon="bolt" href="/docs/relay/quickstart">
    Create a project and send the first OpenAI-compatible request.
  </Card>

  <Card title="Compare integration modes" icon="git-branch" href="/docs/relay/integration-modes">
    Choose an execution or observation path without changing more than necessary.
  </Card>
</CardGroup>

## Routing control

Teams can route automatically or pin a model, choose candidate models, bias cost, quality, or latency, set fallbacks, and inspect why each request was routed. Custom routers can be built for chat, code, or company-specific workloads.

Visibility gives Relay real company traffic and use-case context. That lets routers reflect the work the company actually performs rather than a generic benchmark alone.

## Providers stay yours

Relay supports customer-controlled provider accounts and keys. A company can change providers, models, or gateway architecture without rewriting the applications that call its OpenAI-compatible endpoint.

## Measure before and after

Traffic logs, decision replay, model comparisons, quality evaluations, cost projections, latency reports, and agent-run grouping show the effect of routing on real workloads. Activity and results return to Visibility as part of the shared operating map.

<CardGroup cols={2}>
  <Card title="Configure routing" icon="sliders-horizontal" href="/docs/relay/routing-fallbacks">
    Set a pinned or automatic policy, candidate set, tradeoff, and fallback.
  </Card>

  <Card title="Measure outcomes" icon="chart-line" href="/docs/relay/reports-evals">
    Replay decisions, compare live and shadow results, and run quality evaluations.
  </Card>

  <Card title="Inspect traffic" icon="list-tree" href="/docs/relay/traffic-runs-signals">
    Trace requests, understand decisions, group agent runs, and classify signals.
  </Card>

  <Card title="Review the architecture" icon="network" href="/docs/platform/architecture">
    See how Relay fits with Visibility, Sidekick, customer gateways, and deployment models.
  </Card>
</CardGroup>