Router quickstart & integration guide

Runix Router is an OpenAI-compatible endpoint in front of many model providers. If your code already calls an OpenAI-compatible API, integration is a configuration change: point the client at Runix and swap the key. This guide covers the quickstart, model selection, streaming, failover semantics, and the operational details teams ask about. Router is in early access — keys are issued after a short intake, and onboarded teams get support directly from the engineers.

1. Quickstart

Set your client's base URL to https://api.runixcloud.io/v1 and use the key issued during onboarding. Everything else about your existing integration stays the same.

# cURL
curl https://api.runixcloud.io/v1/chat/completions \
  -H "Authorization: Bearer $RUNIX_API_KEY" \
  -d '{
    "model": "auto",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

# OpenAI SDK (Python)
from openai import OpenAI
client = OpenAI(
    base_url="https://api.runixcloud.io/v1",
    api_key=RUNIX_API_KEY,
)
resp = client.chat.completions.create(
    model="auto",
    messages=[{"role": "user", "content": "Hello"}],
)

The same base-URL swap works for any tool that speaks the OpenAI API — LangChain, LlamaIndex, the Vercel AI SDK, or plain HTTP.

2. Model selection

Two ways to choose what serves a request:

• Pin a model id — pass a specific model id in the model field and Router dispatches to that model, applying failover only within the providers that serve it.
• Route automatically — pass "model": "auto" and Router selects by cost, health and your account's configuration. Routing preferences are set per key during onboarding; tell us your priorities (cheapest acceptable, latency-first, provider allowlists) and they are applied server-side.

3. Streaming

Pass "stream": true and responses arrive as standard server-sent events, exactly as your SDK already expects. Streaming passes through the router rather than being buffered and replayed — including tool-call deltas — so time-to-first-token stays close to the provider's own.

4. Failover semantics

What happens when an upstream provider degrades is the part worth reading twice:

• Errors, rate limits and timeouts trip a circuit breaker; the request is re-issued to a healthy alternative under a retry budget, so one provider's bad hour does not become your outage.
• Mid-stream failures are re-issued as well — see how streaming failover works for the mechanics and the edge cases.
• A degrading provider is taken out of rotation before it drags your latency, and returns when health checks pass.

For the background on retry budgets and failure taxonomy, read Model failover for production LLM traffic.

5. Limits, usage and cost

• Per-key quotas — each key carries limits and quotas set during onboarding, revocable and adjustable without a redeploy.
• Usage tracking — usage is recorded per request from the first call; billing is usage-based in USD with itemised statements. See Pricing for how quotes work.
• Attribution — issue separate keys per team or product to get cost attribution along the lines your finance team actually asks about; the reasoning is covered in LLM cost attribution.

6. Data handling

Prompt and response content is processed to serve your request; it is not used to train models and not sold. Operational metadata — usage counts, latency, error codes — is kept to run billing, reliability and support. The full statement is in the Privacy Policy, and the security posture in Security.

7. Getting a key

Router is in early access: we issue keys and onboard teams individually rather than through self-serve signup. Tell us what you are building — models, expected volume, latency needs — and we reply within one business day with an access plan. A complete API reference ships with general availability; early-access teams receive onboarding documentation directly.