All-in-one aggregators 72 services

This category solves the "one project, several vendors" problem. You keep a single base_url and a single key, and switching models is just a matter of changing the model name — no separate accounts, no separate invoicing and no separate rate-limit handling per vendor.

The typical fit: a product that needs Claude for coding, GPT for structured output and Gemini for long documents. If you only ever use one family, a specialist category is usually cheaper and steadier — to cover such a wide range, aggregators often re-forward a few models, which makes the chain longer than a specialist's.

What to watch: aggregators vary enormously. Some connect straight to their upstreams, others sub-contract through several layers. And "how many models a service advertises" is not the same thing as "how many our probe can actually reach" — we mark the difference in the listings. An empty model count means we could not retrieve a list from the API; that does not prove the service lacks support, but it does tell you it does not expose /v1/models publicly.

One more thing that is easy to overlook: an aggregator is a single point of failure. Every model call goes through that one service, so when it breaks, everything stops. In production it is steadier to run two or three side by side than to push all of your traffic through one.

• Most stable：Highest current uptime. Fewer samples means more distortion, so we state the source (public dataset / our own measurement) and you can check it on the detail page.
• Fastest：Ordered by the home-page response time of the most recent probe. A single measurement is noisy, so treat it as a range rather than an absolute.
• Broadest model coverage：This uses the model count our endpoint probe actually detected, not the support list the service advertises — the two are measured differently, and the advertised figure is usually the more optimistic one.

Why does the model count here differ from what the service advertises?

What a vendor advertises is a support list; our count is what a real request to /v1/models returned. The two measure different things. Advertised lists usually include models that are "coming soon" or "available on request", while the API returns only what can actually be called today. We record what we can reach and leave the field empty with a label when we cannot — we never pass a marketing figure off as a measured one.

Does one key for every model make rate limiting more likely?

It depends on how the service schedules traffic. Aggregators typically keep several upstream channels behind the scenes and route by health and latency, switching automatically when one is throttled. But that scheduling layer is their own implementation, and strategies are not transparent, so for high-concurrency work test the target service under load rather than trusting its advertised number.

When mixing several vendors' models, how do I keep billing and usage in one place?

Most aggregators offer a single usage dashboard, but billing rules differ — whether input and output are priced separately, whether cache hits get a discount. Estimate your expected cost from the official price list before you sign up, then reconcile the actual charges during the first week and only scale up once the numbers line up.

Compared with going direct to the vendors, what exactly do aggregators save?

They save on payment friction and integration cost, not necessarily on unit price. Official APIs need an overseas credit card and sometimes a particular network environment; aggregators take local payment methods and let you top up instantly. On price, an aggregator applies its rate to the official list price — only a rate below 1x is genuinely cheaper, and anything above 1x is a fee for convenience.