Search traffic for "OpenRouter alternative" is mostly people who have outgrown one specific thing: aggregation is easy to adopt and hard to defend in a procurement review. If you are shopping, the useful exercise is not comparing feature grids — vendors write those — but writing down the questions whose answers you would have to show someone else.
What follows is that checklist. It is deliberately vendor-neutral: run it against every candidate, including Runix Gateway, and including "keep building it ourselves".
1. Who is the counterparty?
Ask which legal entity you are contracting with, where it is incorporated, and whether it can issue an invoice your finance team can pay. This sounds bureaucratic until a security review stalls for six weeks because nobody can produce a signable MSA.
Follow-ups worth asking: is there a DPA available, and does the vendor sub-process your data through anyone you have not been told about?
2. What happens to prompt content?
Get this in writing, and get the distinction right, because most vague answers hide it: content (prompts, completions, files) is not the same as operational metadata (token counts, latency, error codes, model ids). Almost every gateway keeps the second — you cannot bill or debug without it. The questions that matter are whether the first is stored at all, for how long, who can read it, and whether it is ever used to train anything.
"We do not store your data" is not an answer. "Content is not persisted beyond the request; metadata is retained for N days for billing and support; nothing is used for training" is.
3. Where do the credentials live?
There are two models, and they have different blast radii. Either you hand the gateway your provider keys, or the gateway holds its own provider relationships and issues you keys. Both are defensible. What matters is that gateway keys can be scoped and revoked per team or per service without redeploying anything, and that revocation actually takes effect immediately.
4. What does failover really do?
Every vendor says "automatic failover". Push on the specifics:
- Does a mid-stream failure fail over, or only a failure before the first token? Failing over after tokens have been emitted requires deciding what the client sees — silently restarting a stream produces duplicated text.
- Is there a retry budget, or does every failure retry? Unbudgeted retries turn a provider brownout into an outage. We wrote about the mechanics in designing for model failover.
- Are tool calls and structured outputs preserved across a failover to a different provider, whose schema handling may differ?
5. Can you attribute cost without a spreadsheet?
Ask to see what a statement looks like. Specifically: can you break spend down by key, by team and by model, and does the vendor's number reconcile with your own request logs? A gateway that cannot answer "which feature spent this" is a billing pass-through, not a cost control.
6. What is the pricing model, exactly?
Three shapes are common: a margin on provider rates, a flat platform fee, or a per-request charge. All three are fine. What is not fine is not being told which one you are on. Ask what happens when the underlying provider changes its prices, and whether your rate is fixed for a term.
7. What is the added latency, measured how?
A gateway on the hot path adds overhead. Ask how it is measured — added time-to-first-token is the number that matters for streaming UX, and it is the number vendors are least likely to publish. Be suspicious of a single global figure with no percentiles and no region.
8. What happens when the gateway itself is down?
You have added a dependency in front of every AI feature. Ask about the failure mode: is there a documented way to bypass it, do keys keep working if the control plane is unavailable, and what is the actual availability record — not the target.
9. Can you leave?
Exit cost is the cheapest thing to check and the most expensive to discover late. If the gateway speaks a standard API, leaving is a base-URL change. If it requires a proprietary SDK, a custom prompt format, or holds the only copy of your usage history, you are buying a migration project you have not scheduled.
10. Is the honest answer "build it"?
Sometimes. One provider, one team, modest volume — a hundred lines of retry logic is genuinely cheaper than a vendor relationship. The calculus changes at the second provider, the second team, or the first compliance questionnaire, because that is when the work stops being a library and starts being an operated service.