One alias in front of OpenRouter.
Your application calls a Relays alias. Relays holds the OpenRouter credential, applies the route policy, and hands back the provider response in the shape your SDK expects.
- Your application
Keeps the OpenAI-compatible request it already sends.
- Relays
Holds the key, picks the candidate, writes the receipt.
- OpenRouter
Receives the call on its own base URL.
- OpenAI-compatible
- Chat Completions
- Bring your own OpenRouter API key
OPENROUTER_API_KEY https://openrouter.ai/api/v1- Maintained Relays preset
Relays’ OpenRouter preset is a Chat Completions connection. A Relays alias can pin an OpenRouter model ID while the application continues to call the Relays route.
What is measured, and what is not.
Availability comes from OpenRouter. Latency, error rate, and cost per successful request come from your own traffic, so Relays leaves them empty until requests run.
Relays measurements
Models at the edge.
Model IDs sit behind a Relays alias, so a catalogue change at OpenRouter never reaches your code.
Every route carries a policy.
A route is a list of candidates, a budget, and a record of what happened. You set all three before any traffic runs.
Candidates stay inside the contract.
OpenRouter can be one explicitly ordered candidate in a Relays Chat Completions route. Relays records the gateway route; model availability and upstream routing behavior remain owned by OpenRouter.
See how a route is chosenA ceiling on this route.
Set an alert threshold and a stop threshold for the route rather than for the whole application. Relays checks both before the call goes upstream.
Each attempt is written down.
Every call records the alias, the candidates tried, the status each returned, tokens in and out, and the estimated cost of the attempt that served it.
Read a route receipt
One endpoint is enough to start.
Keep the client you already wrote. Bring us the workload and we will map the first OpenRouter route with you.
