Runix Gateway · Early access

One compliant endpoint
for every model

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

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.

Security

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
Compliance

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
Performance

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 Gateway 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.
Integration

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 — illustrative 
# Point your existing OpenAI-compatible client at Runix
curl https://api.runixcloud.io/v1/chat/completions \
  -H "Authorization: Bearer $RUNIX_API_KEY" \
  -d '{
    "model": "auto",
    "messages": [{"role": "user", "content": "Hello"}],
    "stream": true
  }'

Common questions

How much of my code has to change?

Runix Gateway 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.

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