What is OpenRouter, and when should you use it instead of calling providers directly?

What OpenRouter sits between

Two words do most of the work here. The model is the weights, for example a specific Claude, GPT, Gemini, or DeepSeek release. The provider is the company that actually runs those weights on its own GPUs, at its own precision, with its own request parsing and its own quirks. When you ask OpenRouter for a model by its slug, the platform chooses one of possibly dozens of providers serving that model and forwards your request there.

The interface is deliberately boring, which is the point. It is OpenAI-compatible chat completions at a single endpoint, so existing OpenAI SDKs work by changing the base URL, and there are also first-party client SDKs and an agent SDK. OpenRouter also publishes a hosted MCP server so coding assistants can look up models, prices, and usage while you build. The catalog is large: the pricing page listed 500+ models from 80+ providers on paid plans at our check date, with a free tier offering 25+ free models.

One piece of company context is worth knowing in 2026: OpenRouter announced on August 19 that it is joining Stripe, saying the product and roadmap do not change. That is an announcement about ownership, not about anything you can use today.

• Model: the weights. Provider: the company hosting and serving them.
• OpenRouter: a router that picks a provider for the model you name, with automatic fallbacks.
• The API is OpenAI-compatible, so the switching cost to try it is genuinely small.

How routing actually works

By default, OpenRouter load balances each request across providers rather than pinning one. Its documentation describes the strategy in three steps: prefer providers that have not had significant outages in the last 30 seconds; among the stable ones, pick from the cheapest candidates with a weight that follows the inverse square of price; and keep the remaining providers as fallbacks. That default is optimized for price first and uptime second, which is exactly what you want for casual use and not obviously what you want for a production agent.

The interesting part is how much control you can add. A provider object in the request can restrict which providers are tried and in what order, disable fallbacks, require providers that support all parameters you send, filter by declared quantization, cap the maximum price, and require zero-data-retention or no-training routing. Sorting can favor price, throughput, or latency, and two slug shortcuts make common cases short: nitro for fastest throughput and floor for lowest price. When you set an explicit order or sort, load balancing turns off and the router tries providers in your stated order.

The practical consequence: routing defaults are a starting point, not a policy. If you care about a specific behavior, you have to say so in the request or in account-level settings, and the section on provider differences below explains why that is worth the effort.

What it costs

The pricing model is unusual in a way that matters. OpenRouter says it passes through provider token pricing without a markup, so per-token rates match what the provider would charge you directly. The company makes money on credit purchases instead: a 5.5 percent fee with a 0.80 dollar minimum on pay-as-you-go, 8 percent on the business plan, and negotiated rates on enterprise. Crypto payments carry a 5 percent fee, and unused credits are refundable within 24 hours only.

Two more numbers change the calculus for some users. If you bring your own provider keys, the first 25,000 dollars per month of list-price inference carries no extra fee on pay-as-you-go, rising to 200,000 on enterprise, with a 5 percent fee above the allowance. And if you just want to try models, the free tier offers 25+ free models at 50 requests per day, a limit that rises to 1,000 requests per day once you have bought at least 10 dollars of credits.

As always with pricing pages, treat these as a snapshot: they were read on 2026-09-11, and fees and limits change. The structural point is that you are paying a purchase fee rather than a per-token tax, which favors heavier usage relative to someone who just tops up five dollars once.

• No markup on token prices; 5.5 percent fee when buying credits (0.80 dollar minimum).
• BYOK allowance: 25,000 dollars of list-price inference per month before any 5 percent fee.
• Free tier: 25+ free models at 50 requests per day, 1,000 per day with at least 10 dollars of credits.

What happens to your prompts

A router is one more party in the data path, so the honest question is what it stores. OpenRouter's data collection page states that it does not store prompts or responses unless you opt in: either to private logging for your own debugging, or to letting OpenRouter use inputs and outputs to improve the product, which trades a 1 percent discount on usage. Request metadata such as token counts and latency is stored to power reporting and rankings, and the page says anonymous categorization of a small number of prompts uses zero-data-retention processing.

The provider side is where the policy enforcement gets interesting. OpenRouter states that it works with providers to keep prompts and completions from being logged or used for training when possible, and that providers which log or cannot be confirmed are excluded from routing unless you enable the training toggle in privacy settings. Requests can also enforce this per call: a data_collection deny setting or a zero-retention requirement will refuse a route rather than silently accept a policy mismatch.

For teams with residency requirements, in-region routing for the EU and US exists on the enterprise plan. None of this makes a routing layer risk-free by default. The defaults are good, but the settings are yours to set, and privacy-sensitive workloads deserve a read of the linked pages before the first request, not after.

The part the marketing glosses over: same weights, different providers

This is the section other explainers skip. The same model weights served by different providers are not interchangeable in practice, and the evidence is now specific. An independent operator who runs roughly a third of a production assistant's traffic through OpenRouter published a month of measurements in September 2026. On OpenRouter's own per-provider board for DeepSeek V4 Flash 0731, first-party DeepSeek scored 90.2 percent on GPQA Diamond and 81.3 percent on TAU-Bench Airline, while DigitalOcean, serving the same weights, scored 75.3 and 58.4. Most other hosts clustered five to seven points below first-party on the tool-calling task, and a handful fell far below it on knowledge.

The documented causes read like a maintenance checklist. Some providers silently ignored the reasoning-effort setting. A declared-quantization filter did not buy quality: fp4 and fp8 hosts landed in the same score range. Two hosts of the same vision model returned plausible-looking responses while failing to process images at all. Tool calls sometimes leaked into plain text instead of structured fields, some responses arrived as HTTP 200 with empty content, and one provider rejected a message history format that three others accepted. And when the operator pinned three supposedly reliable providers for fallback-free routing, all three degraded within two weeks.

OpenRouter's side of this is visible in the same discussion: a staff account replied that the company runs live per-provider benchmarks in production and removes providers that underperform from the routing pool, and that the per-provider charts on model pages are that benchmarking data. That is a real mechanism, and it is also per-model and continuous, which is why the durable advice is procedural: check the per-provider board for your model before you rely on it, and re-check when you switch models.

• Identical weights can differ by 20+ points on a tool-calling benchmark depending on the provider.
• Defaults optimize price and uptime; quality-variance is something you manage, not something the default guarantees.
• The move that works: pin or sort deliberately, check the board, and re-test after any model or provider switch.

When to route through it, and when to go direct

Route through OpenRouter when the value is in the layer above the model: you want to try several models without maintaining several integrations, you want one bill and one usage view across models, you want fallbacks you did not have to build, or you want policy-based routing against providers you have vetted. It is also the low-friction path for small projects and for tools that let you paste a base URL, and the free tier makes a weekend of model comparison essentially free.

Go direct when the layer gets in the way. If your workload is optimized around a single vendor and you already have that relationship, an extra hop to standardize an API you are not varying has little upside. If you depend on vendor-specific features, SLAs, support channels, or enterprise data terms, those live with the vendor. And if your threat model is strict about data paths, fewer parties is simpler to reason about, even though the router's privacy controls are real.

A practical middle path that the documentation itself implies: use OpenRouter for discovery, comparison, and multi-model product surfaces, and keep direct integrations for the one or two models you have measured as your production defaults. Because both directions use an OpenAI-compatible interface or a provider SDK, moving traffic is an afternoon of work, not a migration project.

A useful next action

Do the five-minute version of due diligence with a real model. Open one model's page on OpenRouter and find two things before writing any code: the per-provider performance board for that model, and the logging policy of the providers on it. Those two tabs tell you whether the default routing pool is acceptable for your data and whether your task sits in a range where provider choice matters.

Then run a small controlled test that takes under an hour. Send 30 to 50 representative prompts twice, once with default routing and once with a pinned provider, and compare success rate, latency, and cost. If the numbers are close, keep the defaults and move on. If they are not, you have just learned which routing rule your application needs, and you can write it down while it is fresh.