OpenRouter

One endpoint in front of many providers

A router sits between your application and the model providers. You hold one API key and call one URL; it forwards to whichever provider serves the model you named.

OpenRouter describes itself as giving "access to hundreds of AI models through a single API endpoint", and the integration cost is close to zero for anyone already on OpenAI's client: you "can also use the OpenAI SDK pointed at OpenRouter as a drop-in replacement." Change the base URL and the key.

The model is a string in the request. anthropic/claude-sonnet-5, google/gemini-3.8-flash, meta-llama/llama-3.3-70b-instruct. Provider and model in one field, chosen per request.

That is the entire mechanism. Everything interesting is in what it makes cheap and what it quietly costs.

What a router makes cheap: changing your mind

Choosing the right model argues for running your own comparison rather than trusting a leaderboard. The honest problem with that advice is that comparisons are expensive. Three candidates across three providers is three SDKs, three keys, three sets of quirks, and a day of work before you have a single number.

Through a router it is a loop over three strings.

const candidates = ['anthropic/claude-sonnet-5', 'openai/gpt-5.2', 'google/gemini-3.8-flash']

for (const model of candidates) {
  const result = await client.chat.completions.create({ model, messages })
  await score(model, result)
}

The decision stops being a commitment and becomes a configuration value, which means it gets revisited when a better model appears instead of persisting because switching was a project.

Latest aliases extend the same idea to versions. The documentation describes an alias that "always resolves to the newest model" in a family, "allowing code to use fresh versions without redeployment". That is convenient for experimentation and worth thinking twice about in production, where the model silently changing underneath a tested prompt is what regression testing exists to catch.

Automatic fallback, and what it hides

The second selling point is resilience. A router can retry elsewhere when a provider is failing, and OpenRouter says it "handles fallbacks automatically and picks the most cost-effective option for each request."

Useful. Provider outages happen, and a request served by a different provider beats a 503.

But read the second half of that sentence, because automatic routing means something is choosing for you. A request you believe is going to one model may be served by a different provider hosting the same weights, with different quantization, different context handling, and different latency. Your prompt was tuned against one of those. Output quality that varies between identical requests for no reason you can see is difficult to debug, and "the router picked a different host" is not a hypothesis most people reach for.

If you need determinism about who serves a request, the routing controls exist and you should use them explicitly rather than accepting the default.

Who sees your prompts when you route

A router is a third party in the request path, and every prompt passes through it. The documentation here is more honest than most, and the honest part is easy to miss.

Three facts, from the privacy and logging page:

"Each AI provider on OpenRouter has its own data handling policies for logging and retention." So there is no single answer to what happens to your data. It depends on where the request landed, which, per the previous section, you may not have chosen.

There is a training opt-out, and it does what it says: "OpenRouter will not route to providers that train." But the same page adds that this setting "has no bearing on OpenRouter's own policies and what we do with your prompts." The control most people would reach for governs the providers, not the router.

And retention is not routed on at all: "OpenRouter does not have routing rules that change based on data retention policies." A workload with a retention requirement needs the per-request provider restriction the docs describe. The default will not honor it, and nothing will tell you.

None of that is disqualifying. It is the ordinary consequence of adding an intermediary, documented plainly. It does mean a router is a poor fit for workloads under a data-handling constraint, where self-hosted models is the opposite end of the same axis: maximum control, maximum operational cost.

The features that do not survive a common interface

A shared interface is the average of what its providers offer, and the interesting parts of a provider are rarely average.

Prompt caching, structured output modes, extended thinking, provider-specific tool-calling behavior, batch endpoints, fine-tuned model access. Each is implemented differently by whoever offers it, and a common interface either omits it, exposes it inconsistently, or supports it on some routes and not others.

The one with the clearest financial consequence is caching. Prompt caching bills a cache read at a fraction of the base input price, 10% on Anthropic's published rates checked 2026-09-16, and a pipeline built around that discount changes shape when it silently stops applying. Before routing a caching-dependent workload, verify the behavior on the specific route rather than assuming.

There is also a plain hop cost. Your request travels to the router and then to the provider. The documentation does not quantify it and it was not measured here, so no figure appears below. A hop is still a hop, and it lands on every request.

The reasonable shape for most teams: route while you are choosing, and consider going direct once you have chosen and a provider's specific features start mattering. Or stay routed, having decided the flexibility is worth more than the edges. Both are defensible. Drifting into the second without noticing the first is not.

Further reading

• OpenRouter, Quickstart: the endpoint, the OpenAI-compatible interface, model strings, and latest aliases.
• OpenRouter, Privacy and logging: the three quotations in the privacy section, and the per-request provider restriction.
• Choosing the right model: the decision a router makes cheap to revisit.
• Self-hosted models: the other end of the control axis.