OpenRouter: one API for 417 AI models

OpenRouter is a single gateway that gives you access, through one API compatible with the OpenAI SDK, to hundreds of language models hosted across dozens of providers. Its value comes down to three things: you do not rewrite your code every time you switch model, you pay the provider’s own rate with no markup added, and your prompts are not logged by default.

What OpenRouter actually does

Technically it is a proxy. Your application calls OpenRouter exactly as it would call OpenAI’s API — same routes, same request format, same SDK — and OpenRouter forwards the call to the provider of the requested model. Switching model comes down to changing a string in the request body.

That solves a very concrete problem for a product team: provider lock-in. Without a gateway, trying a competing model means a new account, a new key, a new SDK and a new billing line. With a gateway, it is a parameter. The getting-started documentation fits in a few lines of code: the OpenRouter quickstart guide.

The catalogue in numbers

The figures below come from the public catalogue API, sampled on 27 August 2026. They move constantly, so check them before building an argument on them.

• 417 models exposed
• 59 distinct provider families
• 251 multimodal models accepting image input
• 20 models billed at $0 for both input and output
• 2,000,000 tokens of context window on the widest model in the catalogue

The catalogue can be queried without authentication: openrouter.ai/api/v1/models returns the pricing, context window and input modalities of every model. That makes it a practical source for automating price monitoring instead of maintaining it by hand.

The business model: no markup on inference

This is the most commonly misunderstood point. OpenRouter passes the provider’s pricing through with no markup: you pay the same price per token as you would going directly to that provider. The margin sits on credit purchases, not on consumption.

If you would rather keep your own provider contracts, BYOK mode lets you use your own keys through OpenRouter’s interface. It comes with a free allowance that depends on the plan, measured by list-price inference cost rather than request count; beyond it, a percentage applies. The detailed terms are in the official FAQ.

Privacy: what is logged, and what is not

For a company this is often the deciding criterion, and OpenRouter’s position is unambiguous. Its FAQ states there is zero logging of prompts and completions by default, including when an error occurs. An opt-in setting lets you log them deliberately in exchange for a 1% discount on usage costs — the reverse of the usual default.

The second point is subtler and matters more: OpenRouter states that it does not route to providers that log, or whose policy it has been unable to confirm, unless you explicitly enable the corresponding setting. Not exposing your data is therefore the default behaviour, not a checkbox. That is exactly what you want to be able to write into a processor register.

Automatic routing and fallbacks

Beyond the catalogue, OpenRouter can pick the model for you. The router classifies the request by task type, then leans on spend share observed over a trailing seven-day window — a market signal rather than manual curation. You set a cost band through the cost_tier parameter (from low to max), and the surviving models become the primary pick plus the fallbacks.

The operational consequence is availability: if a provider goes down, the request moves to the next one instead of failing. The documentation even notes that if the rankings or the classification are unavailable, the router degrades to a default model set — a hiccup in the routing infrastructure does not fail the call. Mechanism in detail: the model routing documentation.

When OpenRouter is the right call, and when it is not

A gateway carries a hidden cost: it adds an intermediary between you and the model. It is worth it in three cases, and much less so in two others.

Worth it when you are exploring and comparing several models; when you want aggregated billing and analytics rather than one account per provider; or when service continuity matters and automatic fallbacks save you writing your own retry logic.

Less so when you have settled on a single model in production, since the intermediary then adds little; and when your regulatory constraints require knowing and contracting precisely which host runs the inference, which a routing layer makes structurally harder to trace.

In that second case the question is no longer "which gateway" but "which hosting" — a different subject altogether, which we cover in our approach to AI transformation.

What we take away from it

OpenRouter solves a real problem and solves it cleanly: provider lock-in during the phase when you do not yet know which model you will keep. Its default logging policy is more protective than the market average, which makes it a serious candidate even for sensitive internal use.

It is not, however, a permanent architectural decision. The right way to approach it is to use it to decide — compare, measure, choose — then reassess once the model is settled. If that is where you are, our AI scoping exists precisely to settle those trade-offs before any code is written.