What is an AI aggregator?

Search for "AI aggregator" and you get three different kinds of product described in identical words. One is a developer service that sells API access by the token. One is a chat app that sells a monthly subscription covering rival labs' models. One is a browser extension that opens four vendors' own web apps in one window. All three market themselves as the place where every model lives. Their billing and limitations differ, and the person typing that phrase into a search box almost always wants exactly one of them.

The category has never drawn that line clearly for anyone standing outside it, which is why the word has come to mean very little. So this piece does two things: it gives the definition, and then it sorts the three shapes out, because the shape determines everything else you will care about.

Start with the boring definition

An AI aggregator is a product that gives you access to models from more than one AI lab through one interface and one bill. It trains nothing of its own. Its work is taking your request, deciding where to send it, and handing back the answer.

That definition is narrow on purpose. It excludes a lot of things that get filed under the same heading. A single lab shipping several sizes of its own model is selling a product line, and no aggregation is involved. A tool that wraps one model and adds templates is a workflow product. A price-comparison page for AI subscriptions is a directory. What makes something an aggregator is that models from rival labs arrive through the same door, and that you pay one party for all of them.

Two consequences follow immediately, and both are underrated. The first is that an aggregator never controls the thing it sells. When a lab retires a model version, changes its safety behaviour, or throttles capacity on a Tuesday afternoon, the aggregator inherits that with no ability to argue. The second is that every aggregator makes routing decisions on your behalf, whether or not it tells you it is doing so. Those two facts, more than model counts or interface polish, are what separate a good one from a bad one.

One word, three businesses

The router shape sells API access. You bring a key, you send requests, you are billed per million tokens, and the product's value is that one endpoint reaches hundreds of models with automatic failover between hosts. OpenRouter is the obvious example, and it is built for people who write code. Its unit of value is a token, its documentation assumes you know what a completion request is, and it will happily let you spend money faster than you expected, because there is no monthly ceiling to hit.

The chat app shape sells a subscription. You open an app, pick a model from a list, and type. Poe is a long-running example of the shape and MultiChats, which is us, is another. Here the unit of value is a month, which changes the product completely: the app has to guess your usage in advance and price around it, so you get limits instead of a meter. In exchange you never think about API keys, spend, or which host is currently serving the model.

The extension shape sells layout. It runs in your browser, keeps you signed in to the vendors' own web apps, and puts several of them in one window so you can fire the same prompt at each. It aggregates nothing on the server. Your account with each lab is doing the actual work, which means you are still paying every lab you use, and you inherit each one's rate limits separately. What you get is a faster way to compare, and you keep every feature the vendors' own apps have, because you are using the vendors' own apps.

Those rows are the whole argument. Three products, one word, and the failure modes do not overlap at all. A router's bad day is a surprise invoice. A chat app's bad day is a limit you hit at the wrong moment, or a routing decision you did not know about. An extension's bad day is a vendor changing its web app and breaking the layout, which happens more than you would think.

Why access is the weakest reason to pay

The category's own marketing usually leads with access, and access is the part that is worth the least. Anyone can open four tabs. Capable models are not hard to reach without paying anyone, and we are part of the reason why: 21 of the 60 models we carry need no subscription at all. If a product's pitch is that it can reach GPT and Claude and Gemini, the honest response is that so can a browser.

What is actually worth paying for is narrower and more specific. It is that switching costs nothing at the moment you need to switch. In practice that means a conversation is a single thread and the model is a property of each turn inside it, so you can ask a reasoning model to work through a problem, then hand the same context to a fast model to draft the email, and never re-explain anything. In our own schema the model is a field on each message, which is the boring technical reason this works at all. That is the difference between four tabs and one app: in four tabs, switching models means copying and pasting your context into a stranger.

The second thing worth paying for is that one bill replaces four. This is less interesting intellectually and more decisive in practice. If you already pay two or three labs separately, you know your own monthly number, and you know how fast it stopped feeling small. This article prints no competitor figure anywhere, because plans and prices in this category change by the month, and a price carried over from somebody's roundup has stopped being a price. Ours is public: Pro is $20.99 a month, and the pricing page has the rest. Run the arithmetic against whatever you are paying now.

Going direct still wins at some things

An aggregator will not give you a lab's exclusive surfaces, and this is the part the category tends to skip. Claude Code is Anthropic's, and it will stay Anthropic's. Gemini inside Google Docs is Google's, and no third party gets to put a model into a document you are editing in Workspace. The same goes for the vendor connectors, the agent modes, and whatever each lab ships next quarter to make its own subscription stickier. If your work depends on one of those, an aggregator sits alongside that subscription and will not replace it, and any aggregator that tells you otherwise is selling.

You also take on a dependency you did not have before. When you go direct, there is one company between you and the model. Through an aggregator there are at least two, and often three, because many open-weight models reach you through a third-party host, since the lab that trained them does not host it itself. Every one of those hops is a place where your request can be retained, logged, or routed somewhere with a different privacy posture than the one you thought you were getting. Model availability becomes someone else's decision too. If an aggregator cannot get acceptable terms for a model, that model simply is not in the list, and most products will never tell you why.

There is a smaller version of the same trade in day-to-day use. A lab's own app is tuned around one family of models, so its file handling, its memory, its voice mode and its export formats are all built for exactly what those models accept. An aggregator has to build one set of features that works across a catalogue where the models disagree about almost everything: some read PDFs natively and some do not, how much conversation each one can hold before it starts forgetting differs by an order of magnitude, and reasoning controls are exposed differently by every lab. The honest result is a slightly flatter feature set with far more range behind it, and whether that is a good trade depends entirely on whether your work is deep in one lab's ecosystem or spread across several.

Routing is where the real differences live

This is the question almost nobody asks, and it is the one that most changes what you actually get. When you tap a model name, where does the request go?

Our own answer is a useful worked example, because it is written down in the registry, where the numbers can be checked against the app. Of the 60 models we currently carry across 18 providers, 32 are called natively, meaning the request goes to OpenAI, Anthropic, Google, xAI or Mistral directly. The other 28 reach a third-party host through OpenRouter, which is the router shape doing exactly what it is good at. Twenty of those 28 carry a flag called restrictedRouting, which pins them to an allowlist of six hosts (DeepInfra, Fireworks, Google Vertex, Amazon Bedrock, Groq and Azure) with a denylist of creator-owned endpoints and anonymous compute networks stacked on top. Six models carry a privacyNotice that renders on the model's info card in the app, in their own words: OpenRouter-routed entries say "Routed via OpenRouter to third-party providers that may briefly retain requests; they do not train on your data", and Grok says "xAI may use your conversations to train Grok models."

Those six are the whole privacy position, and it is worth stating plainly. We do not train on your conversations. What the provider behind a given model does with them varies by model. Where we know of a difference, the card carries a notice; on the other 54 entries it says nothing, which is not the same as nothing to know.

Routing also decides what is missing. Meta's Muse Spark is not in our list, and the reason sits in a comment in the registry file next to the model it does carry: the only host carrying Spark on the route we use is Meta's own first-party endpoint, which our account privacy settings reject, so every request to it fails at the guardrail. We would rather have the model. We are not willing to change the setting to get it. Most rosters have holes like that, and almost none of them explain the hole.

Four questions to ask before you subscribe

None of this requires you to read anyone's source code. It requires asking questions that a product either answers on its own site or dodges, and the dodge is informative. Ask them in this order:

• Which models do you call at the lab, and which go through a third-party host?

• If a host is involved, is it a fixed list you can name, or wherever is cheapest today?

• Which models retain or train on what I send, and where do you show me that before I use one?

• What is in your list that you cannot actually serve right now?

That last one catches the most products. A roster is easy to inflate and hard to maintain, and a model that was deprecated by its lab six months ago will happily sit in a dropdown forever. What happens when you pick it is either an error or a quiet substitution nobody told you about. Our registry holds 90 entries and serves 60; the other 30 are retired or switched off, and 27 of them carry an explicit pointer to the model that replaced them, so a saved conversation on an old model moves somewhere sensible instead of erroring. That is unglamorous work and it is a fair proxy for whether anyone is minding the shop.

So the word "aggregator" tells you almost nothing on its own, and the shape underneath it tells you almost everything. Work out whether you want a metered endpoint, a subscription with an app around it, or a layout tool over accounts you already pay for. Then ask where the requests go. Every product in this category has an answer to that question, and the ones worth your money will give it to you without being asked twice.