Model Routers: One Key, Many Models

What problem does it solve?

If you buy access directly from the vendors, every model family means a separate account, a separate key, a separate invoice and a separate piece of code. At three providers that is still manageable. At ten it is not, and ten is exactly what you would need in order to know which one suits you.

A router takes that layer off you: one key, one billing relationship, one call format reaches most of the models on the market. The model name is a string parameter — change it and you are at another vendor.

Four different things get called a model router

This section comes first, because without it you buy the wrong thing. The four types solve different problems and carry different risks:

The second type is the most common misunderstanding. Anyone advertising "many open models on one API" is not necessarily an aggregator: a single company may be running all of them on its own hardware. That is not a fault — it is simply different. At an aggregator the company working behind you can change from one request to the next; at an inference provider it never does.

What does a router give you?

Five things, and they are not equally important:

• One integration, many models. The call format is uniform; switching model is a one-line change.
• A fallback when a provider goes down. If one vendor's API stops, the call moves automatically to another. In a production system that alone can justify it.
• Access to open-weight models without hosting them. The Chinese and European open models sit behind the same interface as the closed ones — no server of your own.
• A comparable price list. In one place you see what the same task costs on ten models. Billing runs on credits, not per provider.
• Public usage data. The larger routers publish how many tokens run through them on each model — a rare occasion when you are not looking at a marketing number.

The marketplace: who they are and what they charge

The reference point of the category is OpenRouter. In September 2026 its home page advertises more than 500 models and more than 80 providers, while its public API lists 445 models and 106 providers — the two are not the same count, and the gap shows nicely what a moving target this number is. On price: a 5.5 percent fee when you buy credits, and no markup on the inference itself. It also publishes a usage ranking that shows, day by day, how many tokens run through each model.

And one thing that happened in 2026: on 19 August, Stripe agreed to acquire OpenRouter. The company says the name, the product and the roadmap all stay as they are. Nothing has been published about the closing — but if you are building on it now, this is worth knowing.

There is a European alternative too, which is rare in this sector:

In none of these cases does "500 models" mean 500 different model families: the same model can be available at several providers, at different prices and different speeds — and the router picks between them. An open-weight model can be run by anyone who buys the hardware for it.

What does it cost? Three hidden prices

A router does not work for free, and it does not only charge in money.

An extra hop in the chain. Every call passes through one more party. That adds latency — typically not much, but in a sensitive, user-facing application it counts.

A lag in features. Vendors' new capabilities — new parameters, caching, batch runs — appear on the native API first. The router layer passes them on late or only partially.

Another party on the data path. This is the most important one, and the next section deals with it separately.

The data question you cannot sidestep

When you call through a router, your prompt does not go to the vendor directly. It goes to the router, and from there to whichever provider is currently running that model — and that provider may be a company you have never heard of, in a country you did not choose.

The better routers handle part of this: you can set a data policy that excludes providers who log what you send or train on it. That setting is not the default — if you do not touch it, it does not protect you.

The geographic restriction, though, is weaker than you would think, and plenty of people get this wrong. Filtering by logging can be set per request, but filtering by region at the largest provider is not a plain API parameter: it takes a separate regional endpoint, and that goes to enterprise customers on request. If geographic confinement is a legal requirement where you are, settle it in advance instead of assuming it.

A simple rule follows from that: for experimentation and public content a router is excellent; for customer data only once the policy is set and the contract is in order too. The European AI options post covers that side as well.

The gateway: in front of your own keys

This is the category most write-ups skip, and for a developer it may well be the best answer. A gateway gives you access to nothing — it works with your own provider keys and only puts one layer in front of them: a uniform call format, logging, caching, spending caps, automatic retries, fallback to another provider.

Why it is worth it: your prompt never enters a stranger's route, because the call goes to the vendor with your key, from your account. In exchange you have to run it yourself or subscribe to it, and you do not get five hundred models — only the ones you have an account for.

Two well-known gateways have dropped out, though: one was bought in 2026 by a large security company and renamed, the other changed hands and its services have been running in maintenance mode since. In this sector that is the normal pace — which is why you should not tie yourself to a layer you cannot swap out in a day.

If instead of a gateway you would rather run the model yourself, then you are choosing among the local AI runners, and that is an entirely different decision.

The clouds' marketplace

There is a third route as well: the big cloud providers' model marketplaces. There too one key reaches many models, and the whole thing falls under your existing contract — the same invoice, the same data-processing agreement, the same region choice as the rest of your cloud services. If procurement is the obstacle at your company, this route is faster.

The three big ones: Amazon Bedrock, Microsoft Foundry (formerly Azure AI Studio, then Azure AI Foundry) and Model Garden on Google's Gemini Enterprise Agent Platform (formerly Vertex AI). IBM watsonx.ai belongs here as a fourth. The frequent renaming is a signal in itself: this layer is still looking for its shape.

There is no European equivalent in this category — no EU cloud sells several large vendors' closed models under a single contract. What does exist is EU-hosted open model APIs: OVHcloud, Scaleway, IONOS and Nebius all offer one. If data residency is your main criterion, the choice is not the provider but the model set: a closed frontier model on an EU contract is hard to get today.

The fourth meaning: the per-request selector

When someone says "model router", they sometimes do not mean a marketplace but that the system decides for each request which model is needed. The easy question goes to the cheap model, the hard one to the expensive model.

This exists in two forms today. One is the marketplaces' built-in automatic selector, which mostly costs nothing beyond the price of the model it picks — though not always, because Amazon charges a dollar per thousand requests for the routing itself. The other is the standalone product: the best-known independent solution asks five cents per million routed tokens.

Treat the category with reservation: two of its well-known players had left it by 2026 — both turned themselves into research labs, and neither offers a routing product any more. It is not worth building an architecture on a per-request selector today, but as a supplement it is fine.

Which one, when?

Five signals decide:

• Trying things out, comparing, prototyping → marketplace. There is no point opening five accounts only to close four of them in two weeks.
• Using open-weight models → marketplace or inference provider, because without running your own hardware it is awkward otherwise.
• A production system, several providers, with your own contracts → gateway. You get the uniform interface without the prompt landing on a stranger's route.
• A single model, high volume, in production → direct. Fewer hops, the full feature set, a simpler chain of responsibility.
• Strict data requirements → a cloud marketplace or a direct contract, not a marketplace.

One concrete use: the model bake-off

A marketplace's best use is not production but the decision. When you have to work out which model your task needs, on one shared surface that is an afternoon's work instead of opening five accounts.

The recipe: take 20 to 40 real tasks, run them with the same prompt on five or six models, and look at the error count, the response time and the price. A router makes trivial exactly the part that would otherwise be most of the work — the two-week model bake-off piece sets it out step by step.

Then, once you have a winner, you can move to direct access. A router is a tool, not a commitment.

Common misunderstandings

• "A router and a gateway are the same thing." They are not. A marketplace gives you access to strangers' services on its own key; a gateway stands in front of your keys. On the data path that is the biggest difference in this article.
• "Many open models on one API, therefore an aggregator." It may be one company running all of them on its own hardware. Ask who the operator is.
• "You can set on the router which country it runs in." Filtering by logging, yes; filtering by region, typically only on a separate enterprise endpoint.
• "Whoever charges no markup is free." The fee may sit on the credit purchase rather than on the inference. Check which of the two.
• "This layer is stable." In two years it has seen an acquisition, a rename, a product moved into maintenance mode and two exits. Plan an escape route.

What to take away

One key, many models — for trying things out and as a fallback this is the best solution available today. Its price is an extra hop, features that arrive late, and one more party on the data path, which has to be handled with a policy and which is less tightly bound to geography than you would think.

The first question of the decision, though, is not which router to choose but which type you need. For trying things out a marketplace, in production with your own contracts a gateway, for a single high-volume model direct access, for strict data requirements a cloud marketplace.

And whichever you choose: this layer moves fast. Within two years there has been a multi-billion acquisition, two renamings and two exits. Choose something you can replace in a day — keeping the model name in a string parameter is a good idea for exactly that reason.