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

# Integration modes

> Choose how Relay observes requests, makes routing decisions, and participates in provider execution.

Choose the smallest integration that gives Relay the responsibility you want it to have.

| Integration       | Relay sees the request | Relay chooses the model | Relay calls the provider                        |
| ----------------- | ---------------------- | ----------------------- | ----------------------------------------------- |
| Relay gateway     | Yes                    | Optional                | Yes                                             |
| Existing gateway  | Yes                    | Yes                     | No, your gateway remains in the execution chain |
| Observe over OTEL | Trace data             | No                      | No                                              |
| Route-only        | Decision input         | Yes                     | No                                              |

## Relay gateway

Point an OpenAI-compatible client at Relay. A named provider model is passed through; `oximy/auto` asks Relay to select from the configured candidates. This path supports central keys, limits, fallbacks, traffic records, and routing explanations.

## Existing gateway

Keep your established gateway in the request path and add Relay as the model-decision layer. At a high level, the application or gateway asks Relay for a decision, then the existing gateway executes the selected model using its own provider credentials and controls.

<Note>
  Existing-gateway chaining does not have one universal configuration recipe.
  The exact placement depends on your gateway's routing hooks, authentication
  model, and request format.
</Note>

Preserve one authority for retries, provider credentials, and final execution. Propagate Relay's decision identifier into your telemetry so the decision and eventual provider call can be correlated.

## Observe over OTEL

Keep the current provider path and export OpenTelemetry traces to Relay. This is the lowest-risk way to establish traffic, cost, latency, and workload baselines before changing execution.

## Route-only

POST request context to Relay's decision endpoint. Relay returns the selected model and a decision identifier; your application or gateway performs the provider call. Route-only is generally available for teams that need routing intelligence without proxy execution.

## Capabilities, not a one-time lock

Gateway and OTEL observation can coexist in a project. Shadow comparison is also a separate setting: it can evaluate a candidate alongside observed or gateway traffic, subject to provider access and budget.

<CardGroup cols={2}>
  <Card title="Use the Relay gateway" icon="server" href="/docs/relay/gateway">
    Swap an OpenAI-compatible base URL and let Relay execute.
  </Card>

  <Card title="Observe with OTEL" icon="activity" href="/docs/relay/observe-otel">
    Export traces without changing the provider call path.
  </Card>

  <Card title="Use route-only" icon="signpost" href="/docs/relay/route-only">
    Ask Relay for a decision and execute it yourself.
  </Card>

  <Card title="Plan keys and providers" icon="key" href="/docs/relay/keys-providers-models">
    Separate Relay authentication from provider credentials.
  </Card>
</CardGroup>