Routers: one key, many models

What a router is

A router sits between you and a dozen model providers. You get one account, one key, one bill, and access to hundreds of models (closed and open, from many companies) through a single request format. OpenRouter is the best known; there are several others, and some cloud platforms offer the same idea inside their own ecosystems.

For anyone comparing tools this is convenient. Testing your twelve prompts across six models normally means six sign-ups, six payment methods and six sets of documentation. Through a router it is one account and a change of model name.

What it buys you

Trying anything immediately. A new model appears and you can send it a prompt within a minute, with no new account.

Access where you could not get it. Some providers are hard to sign up for from some countries, or need a card type you do not have. A router often works where a direct account does not.

Automatic fallback. Most routers will retry a failed request on another provider serving the same model. When one company has an outage, your work continues.

One bill in one currency, with per-key spending limits you can hand to different projects or people.

Prices you can compare. Router listings show cost per million tokens across models side by side, which is the most useful pricing view available anywhere, and it is free to look at.

What it costs you

A margin. Routers make money somehow: usually a percentage on credit purchases or a small markup. It is modest, and it is real.

Another party in the data path. Your prompts pass through the router’s servers before reaching the provider. That is one more privacy policy to read and one more organisation to trust, which for confidential material may be decisive.

Variable back-ends for open models. This is the subtle one and it catches people. When you request an open model like llama-3.1-70b, the router picks among several companies hosting it. Those hosts differ in quantisation, context length, speed and price: one may serve a 4-bit version with a 16k window while another serves 8-bit with 128k. Same model name, measurably different behaviour, chosen for you per request.

Good routers let you pin the host, or filter by quantisation and context length, and the setting is usually off by default. If you are evaluating an open model through a router and getting inconsistent results, this is very likely why.

Feature lag. Vendor-specific capabilities (caching, thinking budgets, particular tool formats) arrive late or not at all.

Reading a router listing properly

The listing looks simple and hides three things worth checking before you trust a comparison:

1. Input and output prices are different numbers, often by a factor of three to five. A model that looks cheap can be expensive for long answers.
2. The context length shown may be the host’s, not the model’s. A model advertised at 128k may be served at 32k by the cheapest provider.
3. Free entries usually mean training on your inputs, heavier rate limits, or both. Read the note next to the word “free”.

Rate limits and credits

Routers usually work on prepaid credit rather than a monthly invoice, which is quietly useful: you cannot overspend past what you have loaded, and running out is an error rather than a bill. For anyone nervous about the open-ended nature of API pricing, this is a real advantage over going direct.

The trade is that rate limits through a router are often tighter than the provider’s own, because the router is sharing its own allocation across all its users. For a burst of a few hundred requests this never matters. For a sustained job it can, and it is worth a small test before you plan around it.

When to use one, and when not

Use a router for evaluation, for occasional access to many models, when direct sign-up is blocked from where you are, and for small projects where one bill is simpler than five.

Go direct when you have settled on one provider and are using it at volume, when you need vendor-specific features, and when the material is sensitive enough that fewer parties in the path matters more than convenience.

A reasonable arrangement for most people: a router for experimenting, a direct account with whichever provider wins, and a local model for anything that must not leave the building. The router earns its margin during the deciding and stops being necessary once you have decided.