One compliant endpoint for every model

Runix Router · Early access

The control plane between your product and the model providers: central key custody, written data terms, and failover that fires mid-request — behind one OpenAI-compatible API.

Request access See how billing works Read the docs

Built for the three things that block rollouts

Teams rarely stall on whether a model works. They stall on who holds the keys, what legal can sign, and what happens at 3am when a provider degrades.

Keys stop leaking out of .env files

Provider credentials live in the gateway, not in a dozen repositories and CI secrets.

  • Central key custody — provider keys are held once, never distributed to app teams
  • Scoped access — per-key limits and quotas, revocable without a redeploy
  • Request-level trail — who called what, when, with which model and at what cost
  • No training on your content — prompts and outputs are processed to serve the request, nothing more

Something procurement can sign

A registered US company to contract with, and terms written down before you ask.

  • US entity — Runix AI Inc, Wyoming, invoiced in USD
  • MSA & DPA on request — reviewed per engagement; an order form overrides the standard Terms
  • Data handling in writing — content versus metadata, and how long each is kept
  • No invented badges — we state the posture we actually hold, and name what we do not

A bad provider hour is not your outage

The gateway is on the hot path, so it is built to get out of the way and to recover without you.

  • Failover mid-request — errors, rate limits and timeouts re-issue upstream under a retry budget
  • Circuit breakers — a degrading provider is taken out of rotation before it drags latency
  • Streaming preserved — token streaming and tool calls pass through intact, not buffered and replayed
  • Routing you control — pin a model, or let the router choose on cost, health and configuration
Runix Router is in early access, so treat capability claims as what the product does for onboarded teams today — not as a published SLA. Ask us for specifics on your workload and we will answer concretely, in writing.

A base URL, not a migration

If your code already calls an OpenAI-compatible API, the change is configuration. The SDKs, the streaming, the tool-call shape and the error semantics you already handle stay where they are.

  • Point the client at Runix and swap the key
  • Pin a model id, or send "model": "auto" and let routing decide
  • Per-key limits and usage tracking apply from the first call
example request 
# Point your existing OpenAI-compatible client at Runix
curl https://api.router.runixcloud.io/v1/chat/completions \
  -H "Authorization: Bearer $RUNIX_API_KEY" \
  -d '{
    "model": "auto",
    "messages": [{"role": "user", "content": "Hello"}],
    "stream": true
  }'

What a provider's bad hour looks like from your side

Your application holds one base URL and one key. Everything below happens behind that line, while the request is still in flight.

How Runix Router handles a degrading provider Your application sends every request to one Runix endpoint. Runix watches provider health, trips a circuit breaker when a provider starts erroring, rate-limiting or timing out, and re-issues the request to a healthy provider under a retry budget. The degraded provider returns to rotation once health checks pass. Your application one base URL one key request Runix Router health checks circuit breaker retry budget re-issued here Healthy provider serving your traffic Degrading provider errors, 429s or timeouts Standby provider available if the first choice also fails
  1. Your application sends every request to one Runix base URL, with one key.
  2. Runix Router tracks provider health, and trips a circuit breaker on errors, rate limits and timeouts.
  3. The degrading provider is taken out of rotation before it drags your latency.
  4. The request is re-issued to a healthy provider under a retry budget, so a retry storm cannot become the second incident.
  5. The provider returns to rotation when health checks pass. Nothing in your application changed.
Your code never learns any of this happened. The base URL it holds does not change, and no redeploy is involved: which is the point of putting a gateway on the hot path at all.

Common questions

How much of my code has to change?

Runix Router speaks the OpenAI API. In most cases you change the base URL and the key; the SDK you already use keeps working, including streaming and tool calls.

What happens when a provider fails?

Errors, rate limits and timeouts trip a circuit breaker and the request is re-issued to a healthy provider under a retry budget, so one provider's bad hour does not become your outage.

Is my prompt content used for training?

No. Content is processed to serve your request, not used to train models and not sold. Operational metadata (usage counts, latency, error codes) is kept to run billing, reliability and support. See Privacy.

Can we sign a contract and get invoiced?

Yes. Runix AI Inc is incorporated in Wyoming. MSA and DPA on request; an order form takes precedence over the standard Terms. USD billing with itemised statements, prepaid or invoiced.

How do I get access?

Access is invite-only: tell us what you are building and your account is set up within one business day; evaluation credits are issued on request, so you can test against real traffic before you pay. The full process is on Access.

Put the gateway in front of your traffic

Tell us the models you call and roughly how much: we come back with an access plan and a quote within one business day.

Request access