OpenRouter Explained: One API for Every LLM - and What It Means for EU Teams

If you build with large language models, you've felt the pain: every provider has its own SDK, its own auth, its own rate limits, its own quirks. Switching from one model to another - or hedging against an outage - means rewriting integration code. OpenRouter is one of the most popular answers to that problem. But for a European company, "popular in San Francisco" and "safe to put customer data through" are two very different questions.

This post does both halves. First, what OpenRouter actually is and how it works under the hood. Then the part that matters most for us in Europe: the competitive landscape, who is EU-based versus US-based, and what that means for GDPR and data residency.

A note on sources. Almost everything about OpenRouter's own behaviour below comes from OpenRouter's public documentation. It is authoritative for what OpenRouter states it does, but none of it is independently audited - so we flag the self-attested claims as exactly that. The competitor details come largely from vendor marketing pages and should be confirmed contractually before you rely on them.

What OpenRouter Is

OpenRouter is a unified API gateway - sometimes called an aggregator or LLM router - that sits between your application and the model providers. Instead of integrating OpenAI, Anthropic, Google, Mistral, Meta's Llama hosts and dozens of others one by one, you integrate OpenRouter once and get access to all of them through a single endpoint.

Three properties define it:

• One interface for 400+ models across 60+ providers. A single account, a single API key, a single billing relationship reaches the large majority of commercially available models. (The counts are OpenRouter's own and grow over time.)
• Drop-in OpenAI compatibility. OpenRouter implements the OpenAI API specification, so the official OpenAI SDK works out of the box. In most codebases, adopting it is a base-URL change and a model-name change - not a rewrite.
• A routing layer, not a model. OpenRouter trains nothing of its own. It is plumbing: it forwards your request to an upstream provider and streams the answer back.

The mental model is the one you already know from payment gateways or CDNs: a single integration point that abstracts away a fragmented supply side.

How It Works

Routing and load balancing

The same model is often served by several providers at different prices and reliabilities. By default OpenRouter does price-based load balancing: it first drops any provider that has had a significant outage in the last 30 seconds, then picks among the rest weighted by the inverse square of price. In OpenRouter's own worked example, a provider charging $1 per million tokens is roughly 9× more likely to be chosen than one charging $3 (because 1/3² = 1/9). You can override all of this - pin a provider order, set a price ceiling, or sort by throughput or latency instead.

Fallbacks

This is the headline reliability feature. Provider failover is on by default: if the chosen provider returns an error, OpenRouter transparently retries the same model on the next provider. On top of that, model-level fallbacks are opt-in - you can define a chain like "try Claude, then GPT, then Llama" so a single request degrades gracefully instead of failing. You can also lock this down (allow_fallbacks: false) to restrict routing to providers you've explicitly approved.

Pricing - and the "no markup" asterisk

OpenRouter's signature pricing claim is that it charges no markup on inference: you pay the same per-token rate you'd pay the underlying provider directly. Independent reviews confirm the catalogue rates match providers' published prices.

But "no markup" is not "no fees," and the distinction matters for a budget:

• A ~5.5% fee on credit purchases (with a minimum, currently around $0.80) when you top up via card.
• A ~5% crypto top-up fee as an alternative.
• A ~5% BYOK fee (see below), though the first ~1 million BYOK requests per month are free.

So the per-token economics really are pass-through; the platform monetizes the money movement and the BYOK convenience, not the tokens. Present "no markup" to a stakeholder without those fees and you'll under-budget.

BYOK - Bring Your Own Key

You can supply your own provider API keys (e.g. your existing Azure OpenAI or Anthropic key). OpenRouter encrypts them and uses them for requests routed to that provider, so usage hits your provider account, your rate limits, and often your negotiated pricing or compliance terms. The ~5% BYOK fee applies above the free tier. One sharp edge to know: by default OpenRouter will fall back to its shared endpoints if your key fails, unless you explicitly set "always use my key for this provider."

The Pros

• One integration, the whole market. Add or swap models without touching integration code. This is genuine insurance against vendor lock-in and against any single provider's pricing or policy changes.
• Real resilience. Cross-provider failover pools the uptime of many providers. When one host has an incident, your traffic keeps flowing.
• Fast experimentation. Trying a newly released model is a one-line change, which is invaluable in a market that ships a new state-of-the-art every few weeks.
• Cost control levers. Price ceilings and price-weighted routing let you chase the cheapest viable host automatically.
• Sensible privacy defaults. Zero data retention of prompt content is the default, not an upsell (more below).

The Cons

• It's another dependency in the critical path. A gateway that fronts every model is also a single point of failure and a new trust boundary. Its own availability and security now bound yours.
• "No markup" still has fees. The credit-purchase and BYOK fees are easy to overlook.
• Latency overhead. Adding a hop adds milliseconds. Usually negligible, occasionally not - benchmark for latency-critical paths.
• Heterogeneous provider behaviour. The "same" model can behave differently across upstream hosts (quantization, context limits, feature support). Pinning providers helps but adds back some of the complexity you came to avoid.
• The big one for us: data residency is not EU by default. See the next section.

The EU Question: GDPR and Data Residency

Here is where a European consultancy has to slow down, because the convenient default and the compliant configuration are not the same thing.

Where OpenRouter sits

OpenRouter is a US-based company, and its default endpoint is not EU-resident. For a GDPR-bound team this is the crux: by default, prompts (which routinely contain personal data) can be processed on US infrastructure and routed to upstream providers in various jurisdictions.

OpenRouter does offer an EU in-region routing option via a dedicated eu.openrouter.ai endpoint. Per its documentation, requests there are decrypted and processed entirely within the EU and routed only to providers operating in the region. Two important caveats:

1. It's enterprise-only, by request - not something you flip on in the dashboard on a free account.
2. It's a vendor self-assertion. During our research, the strongest "data never leaves the EU" phrasing did not survive independent verification - so treat it as a documented guarantee to confirm in a DPA, not as an audited fact. EU in-region routing also offers a smaller model selection than the global endpoint.

Privacy and logging - the controls that do exist

To OpenRouter's credit, the privacy controls are granular and the defaults are reasonable:

• Zero Data Retention (ZDR) by default. OpenRouter does not store your prompts or completions - even on errors - unless you opt in. Note that "zero retention" covers prompt/completion content; request metadata (token counts, latency, timestamps) is still retained.
• Per-request and account controls. You can require ZDR-only endpoints (zdr: true), route only to providers that don't collect data (data_collection: "deny"), and set an account-wide training opt-out so OpenRouter won't route to providers that train on inputs.
• Each upstream keeps its own policy. OpenRouter aggregates and displays each provider's retention/training terms rather than imposing one - so "ZDR" depends on which provider actually serves the request.

Two opt-in logging mechanisms are easy to confuse, and the difference is legally meaningful:

• A data "discount" toggle gives you ~1% off in exchange for letting OpenRouter use your prompts/completions to improve the product - which grants it an irrevocable commercial-use right to that content. For client data, don't.
• A separate Input & Output Logging feature lets you privately store request/response content for your own debugging, encrypted at rest, retained ≥3 months, and explicitly not used for training. (This one does not apply to eu.openrouter.ai traffic.)

The practical takeaway: OpenRouter can be configured defensibly, but the GDPR-safe setup is the enterprise EU endpoint plus a Data Processing Agreement, named sub-processors, and SCCs or Data Privacy Framework coverage for anything touching the US default. That is a procurement conversation, not a checkbox.

The Competitive Landscape

OpenRouter is the best-known router, but it has a crowded field around it. Roughly grouped:

(Vendor classifications above are drawn from the providers' own materials; verify the specifics for your use case.)

EU-based vs US-based: the honest summary

• Most pure-play routers are US companies (OpenRouter, Together, Fireworks, Portkey, Vercel, Helicone). They can often be configured for EU regions, but EU residency is not their default posture.
• There is a real EU-based cohort. Eden AI (France), Orq.ai (Netherlands), and EU-positioned routers like Requesty (Frankfurt endpoint), Cortecs, and EUrouter make EU data residency and a GDPR DPA their headline feature. If "data stays in Europe by default" is a hard requirement, these deserve a serious look - with the caveat that their model catalogues are typically smaller than OpenRouter's.
• Self-hosting sidesteps the question. LiteLLM is open source: run it in your own EU cloud and residency is wherever you deploy it. You trade convenience for control.
• The hyperscalers offer the strongest contractual story. AWS Bedrock, Azure OpenAI, and Google Vertex AI all run in EU regions with enterprise DPAs. Notably, AWS Bedrock's EU cross-region inference profiles guarantee that requests originating in an EU region are only routed to other EU regions - residency by design rather than by configuration. The trade-off is a narrower model selection and more setup than a router gives you. But at the end, they are still US based companies.

How We Think About It at vensas

There is no single right answer - there's a fit between the workload's risk and the gateway's posture. The way we frame it for clients:

• Prototypes, internal tools, non-personal data: OpenRouter's default endpoint is hard to beat for speed and breadth. Enjoy the optionality.
• Production with personal or client data: the default endpoint is off the table. Choose between OpenRouter's enterprise EU endpoint, an EU-based gateway (Eden AI, Orq.ai, Requesty et al.), a self-hosted LiteLLM in your own EU cloud, or a hyperscaler EU region - and back it with a DPA and a documented sub-processor list.
• Always separate the two questions. "Which model is best?" and "where is the data allowed to go?" are independent. A gateway is precisely the layer that lets you change the answer to the first without re-litigating the second.

The deepest value of a router isn't cheaper tokens - it's optionality. In a market this volatile, the ability to swap models and providers without a rewrite is strategic. Just make sure the layer you bought for flexibility doesn't quietly become the layer that ships personal data across the Atlantic.

Need Support?

Trying to choose an LLM gateway that's both flexible and GDPR-defensible? We help European teams design AI architectures that keep data where it belongs without giving up the ability to use the best models. Reach out via our contact page and we'll work through it together.

How are you handling model routing and data residency in your own stack? We at vensas would love to compare notes.