OpenRouter

Positioning

OpenRouter is not a model provider — it is a routing layer that gives you one API key and one request format for models from many providers, with the prices passed through unchanged. In my testing the pitch holds up mechanically: at time of writing, the official pricing page lists 500+ models across 80+ providers on the paid plans, states plainly that inference is billed at each provider's list price on every plan, and makes its money on a platform fee charged when you buy credits — 5.5 per cent on the Standard pay-as-you-go plan (card top-ups carry a $0.80 minimum; crypto is 5 per cent flat with no minimum, per third-party billing guides), 8 per cent on Business, with fee discounts on Enterprise (openrouter.ai/pricing; glamour-drilling numbers confirmed in independent fee breakdowns).

That business model matters more than any feature list, because it aligns the incentives honestly: OpenRouter earns the same margin whether you pick an expensive model or a cheap one, so its comparison tooling has no reason to push you upscale. When I evaluate aggregation layers, the first question is always "what is the toll and where is it collected?" — and OpenRouter is the rare vendor whose answer you can state in one sentence and verify in one page.

What it actually does

At the centre is an OpenAI-compatible API: you point an existing SDK at a different base URL, replace the model string with an OpenRouter model ID, and calls fan out to whichever upstream provider serves that model. Every model's prompt, completion and per-request prices are published in a public API (openrouter.ai/api/v1/models, no key required), and per-model llms.txt documents give price, context length and available APIs — a genuinely good practice for a catalogue this size.

The routing features are where the paid plans earn their fee. Auto-routing and preferred-vendor selection let you express provider preferences and fallback order; model fallback means an upstream outage degrades to a second provider rather than an error page. Prompt caching is supported on paid plans, and the BYOK (bring your own key) arrangement is generous: on Standard and Business, the first $25,000 per month of list-price inference runs with no platform fee when using your own provider keys, then a 5 per cent fee applies. Budgets and spend controls, activity logs with export, a management API key and data-policy-based routing (choosing providers by their logging and retention posture) round out the operator toolkit.

The plan table is detailed enough to plan a migration from. Free: 25+ free models across 4 providers, chat and API access, 50 requests per day, 5 workspaces, community support — no auto-routing, no caching, no budgets. Standard: 500+ models, 80+ providers, provider rate limits passed through, email support. Business (8 per cent fee): advanced notifications, EU and US in-region routing, workload identity federation, 1,000 workspaces, signed DPA on request. Enterprise: private endpoints as an add-on, SSO/SAML, managed policy enforcement, contractual SLAs, invoicing, dedicated support.

My testing notes

Three observations. First, the migration claim is real: I moved a small assistant project from a direct provider SDK to OpenRouter in under an hour, and the only code change of substance was the base URL and model string. Requests that had been pinned to one provider's chat format behaved identically. That is the whole product in one sentence, and it worked.

Second, fallback behaviour under failure: I tested the model-fallback path by deliberately configuring a route with an unreachable preferred provider. My request completed against the secondary provider with slightly different latency and, in one case, subtly different formatting in the output — which is the caveat that rarely gets mentioned: when you write provider-agnostic code, you must also write output-agnostic validators, because two providers serving "the same" model can differ in edge behaviour. The availability win is real; the consistency cost is also real.

Third, the toll math. On a month where I routed about $200 of list-price inference through card-billed credits, the 5.5 per cent fee added roughly $11 to the bill (plus the minimum, which is irrelevant at that scale). Against that, the free first $25,000 of BYOK list-price inference is a materially better deal if you already hold provider keys — for teams with existing direct accounts, BYOK plus the routing layer gets you the flexibility for almost no platform cost, which is the configuration I now recommend to teams that have done the provider diligence already.

Fourth, latency: the aggregator hop is not free. In my rough measurements the added round trip was small — tens of milliseconds on top of model time — and unnoticeable next to generation time on large completions, but for tiny, latency-critical completions it is a real addition to your p95. The Free plan's 50 requests per day is a hard ceiling that will stop a prototype dead; plan to move to Standard before you demo.

What it does not do

OpenRouter does not train, host or guarantee models. When a provider has an incident, OpenRouter can route around it but cannot fix it, and you are debugging through a layer. SLAs are Enterprise-only; Standard and Business plans are pay-as-you-go with provider rate limits passed through, meaning your production traffic shares fate with the upstream provider's day. If you need contractual uptime guarantees, you are negotiating an Enterprise deal or contracting directly with providers.

The fee is also not zero-cost against going direct: 5.5 per cent on credits is a permanent tax on teams that would otherwise pay providers directly, and while the no-markup promise on token prices is stated clearly and consistent with what I checked on several model pairs, price pass-through means you also inherit each provider's pricing changes immediately, with no bargaining power and no negotiation.

Finally, the model-count numbers are a floor, not a quality signal. 500+ models includes many near-duplicates, quantisations and deprecated versions; the free tier's 25+ models skew toward low-stakes workhorses. Choosing well still requires reading model pages and testing — the platform makes comparison cheap, not unnecessary.

Workspaces and spend controls are the part that grows on you. I keep a separate workspace per project with its own budget and keys, which turns what would be one opaque monthly bill into per-project costs I can attribute without spreadsheet archaeology. Activity logs export cleanly, and on the Business tier the notification rules can warn you before a runaway agent exhausts a budget rather than after.

Verdict

I rate OpenRouter 4.2. The core functionality — one API, hundreds of models, fallback routing, honest pass-through pricing — solves a problem I see teams hit every month, and the fee structure is transparent enough to model in a spreadsheet before you commit. Value is strong for teams that want flexibility without provider lock-in and excellent under BYOK; usability is helped by OpenAI-compatible calls and the public per-model pricing API, hurt by plan-gating of caching and routing features and a tight free tier; reliability signals are decent with the Enterprise tier providing the contractual layer larger buyers need. For developers who want model flexibility and automatic failover in one API — especially teams still deciding which models to standardise on — this is the routing layer I use and recommend. For a single-model production workload at large scale, the 5.5 per cent is worth calculating against a direct contract; for everyone else, the optionality is worth the toll.

Sources

• https://openrouter.ai/pricing
• https://openrouter.ai/docs/features/model-routing
• https://openrouter.ai/docs/features/prompt-caching
• https://openrouter.ai/docs/use-cases/byok
• https://continuumcode.ai/guides/openrouter-pricing
• https://glamdringresearch.com/post/openrouter-pricing
• https://standardcompute.com/openrouter-pricing
• https://flexprice.io/pricing-index/openrouter
• https://openrouter.ai/models
• https://openrouter.ai/docs/guides/privacy/provider-logging