Comparisons of AI gateways often start with a feature grid and a model count. Both are the wrong starting point. Any gateway worth shortlisting can route a chat completion to several providers; what differs — and what you live with for years — is who holds the provider accounts, what happens to a request when your own key fails, whether your budgets can see that spend, what any fee is charged on, and who has to keep the service running.
A disclosure first: INFRO builds a gateway and competes with some of these products. Everything below about another product comes from that product's own documentation, repository or announcement on the access date shown, and nothing here compares performance, which we have not measured. Fee levels are left out on purpose: they change often, and the basis a fee is charged on tells you more about how it will scale than this month's percentage. The dated figures are in AI gateway pricing models compared.
What changed in 2026
The category consolidated this year, and some of the products below now belong to larger companies:
- OpenRouter. Stripe announced on 2026-08-19 that it "has agreed to acquire" OpenRouter1. As of 2026-10-13 neither company had published a completion notice.
- Portkey. Palo Alto Networks announced on 2026-05-29 that it had closed its acquisition of Portkey, which becomes the core AI gateway of its Prisma AIRS security platform2. Portkey's own pricing page now reads "Portkey is now PRISMA AIRS AI Gateway"3.
- Helicone. Helicone joined Mintlify on 2026-03-03; its post says the services remain live "in maintenance mode", with security updates, new models and fixes still shipping4.
None of these is a reason to avoid a product on its own. Each is a reason to read the terms you will be on next year rather than the ones you signed. Who owns your AI gateway covers the timeline and a portability checklist.
The options
OpenRouter
OpenRouter provides one API across many providers' models. Its FAQ says it charges a fee when you purchase credits and passes through the pricing of the underlying providers without markup5.
It also supports bring-your-own-key. Its BYOK documentation describes a monthly allowance that depends on your plan and is measured in list-price inference cost rather than request count; usage above it carries a fee calculated on what the same model and provider would cost on OpenRouter, deducted from your OpenRouter credits6. Two consequences follow. The fee basis is the list price, not the rate your own contract carries. And the same page documents what happens when your keys fail: if every key you configured hits a rate limit or fails, "OpenRouter will fall back to using shared OpenRouter endpoints", which is the default; you can set each prioritized key to never use shared capacity for its models, or for its whole provider6. If your reason for BYOK is to keep traffic on your own contract, change that setting deliberately.
LiteLLM
LiteLLM is an open-source AI gateway you run yourself. Its documentation describes one OpenAI-compatible endpoint for many providers, with spend recorded per key, team, user and tag, and budgets and rate limits per virtual key7. The repository describes routing with retry and fallback logic across deployments, and is MIT-licensed except for an enterprise directory under a separate license8. There is no vendor in the request path — and no vendor to page.
Portkey's open-source gateway
Portkey publishes an open-source, MIT-licensed gateway whose README describes falling back to another provider or model on failed requests and automatically retrying failed requests up to five times9. Observability and logging are part of Portkey's hosted platform rather than the open-source gateway — the hosted platform that is now Prisma AIRS AI Gateway3. The repository showed no change of license on 2026-10-139.
Cloudflare AI Gateway
Cloudflare runs a hosted gateway in front of your providers. Its pricing page says the core features are free, that inference bought through its Unified Billing is passed through without markup, and that a fee applies to credits purchased through Unified Billing10. Its spend limits are the relevant detail for a BYOK buyer: they "apply to both Unified Billing requests and BYOK requests for models with known pricing", answer 429 when exceeded, and are "eventually consistent", so a burst of concurrent requests can briefly pass the limit11.
Vercel AI Gateway
Vercel's gateway charges "no markup and no platform fee on tokens", including with your own keys, and bills some capabilities as paid add-ons12. Its BYOK documentation sets two conditions a BYOK buyer should read closely: BYOK needs purchased AI Gateway credits, and "when a request with your credentials fails, AI Gateway keeps it running by falling back to system credentials", billed against that balance13. Its budgets page adds that "BYOK spend isn't counted in budgets" and that a budget "is a soft cap, not a hard limit": the request that crosses the limit still completes14. LLM spend limits compared sets these budget behaviours side by side.
Direct provider APIs
No gateway at all. You get each provider's newest features the day they ship and no additional party in your data path. You also get one integration, one error model and one set of rate limits per provider — limits that are defined per organization and project15 — and you build failover, budgets and cross-provider cost attribution yourself.
INFRO
INFRO is a hosted gateway over provider accounts you connect, and only those. Your providers invoice you directly at your own rates; INFRO charges a software subscription and takes no fee on model spend. Because INFRO holds no provider accounts, there is nothing for it to fall back to: a failed attempt moves to the next of your own connections or keys, and when all of them fail the request fails.
Side by side
| OpenRouter | LiteLLM (self-hosted) | Portkey gateway (open source) | Cloudflare AI Gateway | Vercel AI Gateway | INFRO | |
|---|---|---|---|---|---|---|
| Whose provider accounts serve requests | OpenRouter's, or yours with BYOK | Yours | Yours | Cloudflare's through Unified Billing, or yours | Vercel's, or yours with BYOK | Yours only |
| When your own key fails | Falls back to OpenRouter's shared capacity unless you turn it off per key | Your configured retries and fallbacks | Your configured fallbacks and retries | Not covered by the sources read | Retried on Vercel's credentials | Next of your own connections or keys; otherwise an error |
| Budgets count spend on your own keys | Not covered by the sources read | Yes, per key, team or user | Not in the open-source README | Yes, for models with known pricing | No | Yes, as an estimate of provider cost |
| What any fee is charged on | Credit purchases; BYOK usage above an allowance | Nothing (open source); an enterprise license is sold separately | Nothing (open source) | Unified Billing purchases; some features billed separately | No fee on tokens; paid add-ons | A subscription; no fee on model spend |
| Who operates the gateway | OpenRouter | You | You | Cloudflare | Vercel | INFRO |
Which fits which situation
- Choose OpenRouter when you want immediate access to many providers' models without holding an account with each, and a fee on credit purchases is acceptable at your spend. If you bring your own keys, decide whether shared-capacity fallback should stay on.
- Choose a self-hosted open-source gateway such as LiteLLM or Portkey's when no third party may sit in your request path and you have engineers who will operate, upgrade and page for a service handling production traffic.
- Choose Cloudflare or Vercel when your application already runs on that platform and its gateway's defaults match yours — in particular, how its budgets treat traffic on your own keys.
- Stay on direct APIs when you use one provider, depend on provider-specific features on day one, and do not yet need cross-provider failover, attribution or policy.
- Choose INFRO when you already hold — or want to hold — your own provider contracts, want every request to run on them, need routing, failover, per-request cost attribution and budgets across them, and prefer a subscription to a fee on model spend. Confirm the specific capabilities you need against its documentation first.
INFRO: your accounts, your keys, your failure policy
A request that names a model is served by every enabled connection whose provider serves it, providers in the order you connected them, and spread across each provider's active keys; a key marked standby is used only after every active key of that provider failed, and a key that answered 429 waits at the back of the line for the provider's Retry-After. A named route fixes the order instead, and can carry if-rules that pick targets from request metadata and failure rules that decide, per failure kind, whether to retry, move to the next target or stop — see routing rules and failure rules and the routes docs.
Budgets are hard caps per organization, project, member and key, with alerts at thresholds you set, and they count INFRO's estimate of what your provider will bill for traffic on your own connections; a model with no known rate is recorded as unpriced, never as free. On the Business plan, that estimate is also compared daily with the cost OpenAI's and Anthropic's own cost APIs report. Plans start at $35 a month, with a 14-day trial; see pricing.
Questions to ask any gateway vendor
- Whose provider accounts serve my requests on the plan I would buy, and can that change without my consent?
- When my own provider key fails or is rate-limited, does the request move to another of my accounts, fail, or run on yours — and who chooses?
- Do budgets count the spend on my own keys, and do they block or only warn?
- What is the fee charged on — purchases, usage, requests, add-ons or seats — and what happens at an allowance?
- Is the provider and account that served each request recorded where I can query it?
- Which data is retained, for how long, and is prompt capture off by default?
- Who owns the vendor today, and what does my contract say on a change of control?
- How do I leave: is the API standard enough that switching is a base-URL change?
The last question matters most. A gateway adopted to reduce dependence on one provider should not create a harder dependence of its own. See what an LLM gateway is for the credential models in more depth, and build versus buy for the self-hosted trade-off.