An AI aggregator platform gives your application one API key and one endpoint for models from many providers. You pay the platform, and the platform pays the providers. That last sentence is what separates an aggregator from the two other shapes that look identical in code: a self-hosted gateway, where you run the proxy over provider accounts you hold, and a BYOK control plane, where a hosted service routes only through your own provider accounts and your providers keep invoicing you directly.
All three expose the same thing to a developer, usually an OpenAI-compatible base URL. The differences sit underneath, in contracts, data terms and what happens when something fails. This guide describes each shape from its own documentation, compares them on the questions procurement and security will ask, and says when an aggregator is the right call and when it stops being one.
What an AI aggregator platform is
An aggregator holds accounts with many model providers and exposes them behind one API. OpenRouter is the best-known example; its quickstart says it gives access to hundreds of AI models through a single endpoint, and that the OpenAI SDK pointed at it works as a drop-in replacement with the base URL https://openrouter.ai/api/v11.
The commercial model is the defining part. Per OpenRouter's FAQ, you add funds to an account with OpenRouter, the cost of each request is deducted from that balance, and OpenRouter pays the underlying providers. It says it passes through the providers' pricing without markup and earns its revenue from a fee when you add funds2.
Routing is the other half. By default OpenRouter load-balances a model's requests across the providers that serve it: it prefers providers without recent outages, weights the choice toward lower price, and keeps the rest as fallbacks. You can pin an order, restrict to named providers with only, turn fallbacks off with allow_fallbacks: false, and restrict routing to providers that do not collect data (data_collection: "deny") or to zero-data-retention endpoints (zdr)3.
Aggregators with a bring-your-own-key option
Some aggregators also accept your own provider keys. OpenRouter's BYOK lets you add keys that are tried for requests to that provider. Usage on your keys carries a fee of 5% of what the same model and provider would cost on OpenRouter, above a monthly allowance measured in list-price inference cost4.
The detail worth reading twice is the fallback. By default, if all your keys for a provider hit a rate limit or fail, OpenRouter falls back to its shared endpoints. That means the request runs on OpenRouter's capacity under its terms rather than on your contract. You can change this per key, or set is_byok_only through the API, so a provider never uses shared capacity4. Neither default is wrong. One favours availability, the other keeps every request on your contract. Pick one on purpose.
The other two shapes
Self-hosted gateways and proxies
A self-hosted gateway is software you run in your own infrastructure, in front of provider accounts you hold. LiteLLM describes its proxy as a self-hosted server that offers one OpenAI-compatible endpoint for more than 100 LLM providers, with virtual keys per user, team and project, spend tracking by key, team and tag, budgets, rate limits, load balancing, retries and fallbacks5.
Contracts and invoices stay exactly where they were. What changes is that the gateway becomes a production service you deploy, upgrade, scale and get paged for, and it sits in the request path of every AI feature you ship.
BYOK control planes
A BYOK control plane is hosted like an aggregator but holds no provider accounts of its own. You connect accounts you already have; it routes, fails over, meters and enforces policy across them, and your providers invoice you for the model usage. The platform charges separately for the software. Because it has nowhere else to send a request, a failed attempt moves to another of your connections or fails. It never moves to someone else's account.
AI aggregator vs AI gateway vs BYOK control plane
| Question | AI aggregator | Self-hosted gateway | BYOK control plane |
|---|---|---|---|
| Who holds the provider contract | The aggregator (yours only for BYOK keys) | You | You |
| Who pays the provider | The aggregator, from what you pay it | You, directly | You, directly |
| What you pay the platform | Usage plus any platform fee | Nothing for open-source software; your infrastructure and engineering time | A software subscription |
| Data path | Your app → aggregator → a provider the aggregator chooses or you pin | Your app → your infrastructure → your providers | Your app → control plane → your providers |
| Your negotiated rates and committed spend | Apply only to traffic on your own keys | Apply | Apply |
| Data processing agreements | With the aggregator; the aggregator's terms with each provider govern the hop beyond it | With each provider, as today | With each provider as today, plus one with the control plane |
| Failover | Across the aggregator's providers by default; BYOK may fall back to shared capacity | Configured by you, across your accounts | Across your accounts only |
| Observability | The platform's dashboards and logs | Whatever you build or run | The platform's request records, cost estimates and exports |
| Rate limits | Partly the aggregator's capacity, partly your keys | Your accounts' tiers | Your accounts' tiers |
| Lock-in | Moving means opening an account with each provider | Low; you run the code | Low; point the base URL back at your providers |
Two rows need explanation. Rate limits belong to accounts. OpenAI sets limits per organization and project and moves an organization through usage tiers6. Anthropic sets them per organization and tier, measured in requests, input tokens and output tokens per minute7. On an aggregator's accounts you inherit its standing with each provider. On your own accounts you inherit yours, including any higher limits you negotiated.
Data processing agreements decide what a security review will accept. With an aggregator, your agreement is with the aggregator, and the hop from the aggregator to the model vendor runs under the aggregator's terms with that vendor. OpenRouter's routing controls let you exclude providers that collect data or require zero-data-retention endpoints3, and that is the right place to start reading. If your company already signed a DPA or a zero-retention addendum directly with a provider, that agreement covers traffic on your account, not traffic on someone else's.
When an aggregator is the right call
An aggregator removes the slowest step in trying a new model, which is opening an account with its vendor. That makes it a good fit when:
- You are prototyping. One key, one balance and every model behind it lets a small team compare ten models in an afternoon without ten sign-ups.
- You need breadth more than depth. Open-weight models served by several hosts, niche vendors and new releases all arrive behind one model id format.
- Your volume is small and no contract exists yet. With no negotiated rates and no committed spend, there is nothing to lose by running on the platform's accounts.
- Availability matters more than which contract serves the request. Default cross-provider fallback is useful if you do not care which host answers.
When it stops being the right call
The same arrangement starts to cost more than it saves when the company's relationship with its providers becomes real:
- Procurement signs an enterprise agreement. Negotiated rates and committed spend apply to usage on your account. Traffic that runs on an aggregator's account does not draw down your commitment.
- Security requires direct data agreements. A review that asks "which vendors process our prompts, under which contract" wants the answer to be your contracts. Adding a hop whose terms you did not sign makes that answer longer.
- Finance needs the provider invoice to reconcile. When usage flows through a third party, your provider's invoice no longer contains it. That is fine until someone has to explain spend by team or by feature against a contract.
- You need to leave. Moving off an aggregator means opening accounts, signing terms and getting limits raised with every vendor you used. That work is easier before you depend on it than after.
None of this is a criticism of aggregators. It is the trade they are built on: they hold the relationships so you do not have to. Once you want to hold them yourself, you need one of the other two shapes. OpenRouter alternatives compares named products on these lines, AI gateway pricing models compares what each one charges on, and who owns your AI gateway covers the 2026 acquisitions that changed the owners of several of them.
Questions to ask any platform before you commit
- Whose provider account served this request, and does the response or the request record say so?
- When my own key is rate limited or fails, does the request move to another of my keys, fail, or run on the platform's account? Where is that setting?
- Is any fee charged on usage that runs on my own keys?
- Do budgets and spend limits count usage on my keys, or only usage through the platform's accounts?
- Can I enter my negotiated rate so cost estimates match my invoice?
- Which DPA covers the hop between the platform and the provider?
- Can I export request records through an API?
- What changes in my code to leave? Ideally the base URL, the key and model ids.
If the platform stores your provider keys, also ask how it seals and scopes them. BYOK credential architecture lists what a sound answer looks like.
How INFRO fits the third shape
INFRO is a BYOK control plane. You connect provider accounts you already hold, applications call one OpenAI-compatible endpoint (and Anthropic's Messages format for agent tools such as Claude Code) with an INFRO gateway key, and each request runs on one of your connections. INFRO has no provider accounts of its own, so a failed attempt moves to the next of your connections or the request fails with each connection named. It never runs on a contract that is not yours.
Your providers invoice you for model usage at your rates. INFRO charges a subscription for routing, failover, request records, budgets that refuse spend before the provider call, negotiated-rate cost estimates and reconciliation against provider usage, with 0% markup on model spend. Leaving is pointing the base URL back at your providers. Plans and limits are on the pricing page.