One compliant endpoint for every model
The control plane between your product and the model providers: one OpenAI-compatible API and one key, with per-key quotas and allowlists, written data terms, and a log of every request with its cost.
See the gateway walkthrough and console → On our examples site; the access key comes from the Runix team.
Evaluation credits on request; no card, nothing to install. Billing is usage-based in USD, quoted per workload.
At a glance
- Interface
- OpenAI-compatible API
- Endpoint
router.runixcloud.io/v1- Keys
- Per key: quota, expiry, allowed models, IP allowlist
- Models
- Public list prices, on the catalogue
- Request log
- Model, tokens, cost and request id, per call
- Data terms
- Content never used for training
- Billing
- Usage-based, USD, itemised
- Contracting
- Runix AI Inc · MSA & DPA on request
- Status
- Available; accounts opened by our team
$ curl https://router.runixcloud.io/v1/chat/completions \
-H "Authorization: Bearer $RUNIX_API_KEY" \
-d '{"model": "your-model-id",
"messages": [{"role": "user", "content": "Hello"}]}'
02 · Example
one request, any model
An OpenAI-compatible request. The model is named by its vendor's own id, and GET /v1/models lists every id a key may call.
03 · Capabilities
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 who can say what the models cost.
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
Spend you can see and cap
Every key has a budget, and every call says what it cost.
- Per-key quotas — a spending limit, an expiry date, the models a key may call and the IPs it may call from
- Usage on every response — the token breakdown comes back with the answer, so one call can be checked against the rate card
- One bill — every model at its vendor's public list price, billed in USD by Runix AI Inc, itemised
- Streaming preserved — token streaming and tool calls pass through intact, not buffered and replayed
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
- Name the model by its vendor id;
GET /v1/modelslists what a key may call - Per-key limits and usage tracking apply from the first call
04 · How it works
What happens to one request
Your application holds one base URL and one key. This is everything Router does with a call, in order.
- Your application sends the request to one Runix base URL with its key, in the OpenAI format it already speaks.
- Runix Router checks the key: that it is active and not expired, that the call comes from an allowed IP, that the key may call this model, and that it has quota left. A call that fails a check is refused before it reaches a provider.
- The request is forwarded to the provider that serves the model, and a streamed answer is passed through as it arrives, not buffered.
- The tokens are metered at the model's price, and the response carries its usage, so a single call can be checked against the rate card.
- The call is recorded in the request log with its key, model, tokens, cost and request id, which is what support traces a question with.
05 · Specifications
The details a review asks for
One table, the same shape on every product page, kept current with the pages it points to.
| Item | Value | Where it is documented |
|---|---|---|
| API surface | Chat completions, Responses and model listing, with server-sent events for streaming | Router quickstart |
| Model selection | The vendor's own model id; GET /v1/models lists what a key may call | Router quickstart |
| Models and prices | Every model on the catalogue at its vendor's public list price; contract rates in writing | Models catalogue |
| Provider failure | OpenAI-style error with a request id; failover between providers set up per account | Reliability |
| Limits | Per key: quota, expiry, allowed models and IP allowlist, changed without a redeploy | Access |
| Errors | OpenAI-style error envelope, with a request id on every response | Router quickstart |
| Data handling | Content processed to serve the request; operational metadata kept for billing and support | Privacy Policy and Security |
| Transport | TLS 1.3 and 1.2; 1.0 and 1.1 refused | Security |
| Service level | No public uptime figure; service levels agreed per account in the order form | Reliability |
| Billing | Usage-based in USD, per token or per request by model; prepaid balance or invoice | Pricing |
06 · Works with
The layers on either side
Runix Router hands off to its neighbours in the stack and works on its own. The same block sits on every product page, with the neighbours changed.
Above · 05 Agents
Runix Code and Runix Comic
Independent domain agents. One that wants a single endpoint for every model can put Router in front of its calls.
See the agents →Below · 03 Models
Runix Models
A model tuned on your data sits behind Router next to the hosted providers, on dedicated capacity.
Explore Runix Models →The whole stack
Five layers, seven products
How Router fits with data, storage and the agents on top.
See the stack →07 · How to start
How to start
Three steps, each with a person on the other end: Runix Router is not self-serve.
01Tell us what you are building
Models, expected volume, latency needs. We reply within one business day and set the account up.
02Evaluate before you pay
Evaluation credits on request, the full product, no card. Integration is a base-URL change.
03Go to production in writing
Rates stated before you commit; MSA and DPA on request; prepaid balance or invoice, in USD.
08 · Questions
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?
The error reaches you in the OpenAI shape, with its HTTP status and a request id, so the retry logic in your client keeps working. Failover between providers is set up per account where it is needed; Reliability says what Router does today.
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?
Accounts are opened by our team: 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 account and a quote within one business day.
Open an account