OpenRouter is developer infrastructure that puts 500+ models from 80+ providers behind a single OpenAI-compatible API. It classifies each request to pick a model, load balances across providers, falls back automatically when one fails, and passes provider pricing through without markup.
Used this tool? Rate it
Used this tool? Rate it
OpenRouter is infrastructure that sits between your application and the AI model providers you want to use. Its own positioning is compact: The Unified Interface For Every Model, with the promise of better prices, better uptime, and no subscriptions. In practice this means you integrate once, against one endpoint, and gain access to a catalogue that would otherwise require dozens of separate vendor accounts, SDKs, billing relationships and failure-handling paths.
The documentation states the value proposition without embellishment: OpenRouter gives you access to hundreds of AI models through a single API endpoint. It handles fallbacks automatically and selects a cost-effective option per request. Those two sentences contain the entire product: aggregation, plus intelligence about which model and which provider should serve a given call.
It is worth being direct about the audience, because OpenRouter is frequently miscategorised. The site does host a browser chat interface, and that leads some directories to file it alongside consumer AI chat products. That is a misreading. The chat page exists so developers can try models and debug prompts; the product is an API layer with billing, routing and observability attached. If you do not write code or configure an application to call an API, this is not a tool you would use directly. If you do, it addresses a problem that grows painful quickly — every model provider has its own SDK, its own auth, its own rate limits and its own outages.
The service is operated by OpenRouter, Inc., registered at 169 Madison Avenue, New York, with the terms governed by New York State law. It was founded by Alex Atallah, previously a founder of OpenSea, and investor commentary describes the proposition as one API, one centralized billing. That phrase captures the second half of the value: consolidating spend across many providers into a single account rather than reconciling a dozen invoices.
Consider what integrating five model providers directly involves: five API keys to rotate, five SDKs to keep updated, five pricing pages to monitor, five status pages to watch, and custom logic to fail over when one degrades. Multiply that by the pace at which new models appear, and integration maintenance becomes a standing engineering cost. OpenRouter converts that recurring cost into a single dependency. Whether that trade is worth making is the real evaluation question, and it is addressed in the limitations section.
The most distinctive feature is automatic model selection, and its mechanism is unusual enough to be worth understanding precisely. The router first assigns each prompt one of ~30 fine-grained task types — categories like code debugging, multi-step agent planning, knowledge QA, mathematics or customer support. Classification happens in flight and, according to the documentation, without requiring prompt retention.
The second step is where it diverges from conventional routing. Rather than relying on a fixed quality ranking, the router looks at what the community actually spends money on for that task type, measured over a trailing 7-day window for each task type. The company compares this to a market index: as usage shifts toward a newly released model that performs better at, say, debugging, the routing follows the spend automatically. Two slugs run this system — openrouter/auto for the stable track and openrouter/auto-beta for early-access routing behaviour.
Choosing a model is only half the problem, because a single model is often served by several providers with different prices, speeds and reliability. By default, requests are load balanced across the top providers to maximize uptime. Beyond that default, the routing is extensively configurable through a provider object in the request body, exposing fields including provider ordering, fallback permission, parameter-support requirements, data collection policy, zero-retention restriction, allow and ignore lists, quantization filters and price ceilings.
For engineering teams, the sorting and threshold controls matter most. You can Sort providers by price, throughput, or latency, and set preferred minimum throughput or maximum latency with percentile cutoffs, plus a maximum price for the request. This turns a vague preference like "cheap but not slow" into an explicit, enforceable request parameter.
Reliability is the argument that often decides adoption. The documented behaviour is unambiguous: If a provider returns an error OpenRouter will automatically fall back to the next provider. This happens transparently, meaning your application does not need retry-and-reroute logic of its own. For production systems where a single provider outage would otherwise cause a user-visible failure, this is the feature that justifies the dependency.
The platform offers the raw API for full control in any language, type-safe Client SDKs, and an Agent SDK for building agents with tool use, loops, and state. The tiering is sensible: a script hitting the endpoint with curl needs nothing installed; a typed application benefits from the SDK; an agentic system with tool calling and state management gets a purpose-built layer rather than hand-rolled orchestration.
The feature surface extends well past model selection. The documentation covers response caching, prompt caching, tool calling, structured outputs, message transforms, streaming, batch processing, custom classifiers, guardrails, service tiers, presets and zero-completion insurance. On the team side there are workspaces with budgets, single sign-on, SCIM group mappings and analytics. This is the difference between a hobby proxy and something an organisation can standardise on.
The primary use case is straightforward: you are building a product that calls an LLM and you do not want to commit irreversibly to one provider. Integrating through OpenRouter means switching models is a string change rather than a refactor. When a better or cheaper model launches, you evaluate it without an integration project first.
Different tasks warrant different models, and paying frontier prices for simple classification is waste. Because pricing is passed through and providers can be sorted by price with a maximum price ceiling per request, teams can route cheap tasks to cheap models and reserve expensive models for work that needs them — all within one billing relationship.
For applications where model calls sit on a user-facing critical path, automatic provider failover converts a hard dependency into a soft one. Combined with throughput and latency preferences, this supports meaningful service-level targets without building a routing layer in-house.
Teams comparing models for a specific task can run the same prompts across many models through one interface. The public rankings and app leaderboards add a second signal: what other developers actually use in production for comparable work.
Agentic workloads amplify every weakness of a single-provider setup — they issue many calls, they need tool calling, and a mid-run failure wastes the whole trajectory. The Agent SDK plus automatic failover targets exactly this shape of work.
For regulated organisations, the platform supports in-region routing in the EU and US for enterprise customers, alongside zero-retention endpoint restriction and provider-level data policy controls. That combination lets compliance requirements be expressed as request configuration rather than as vendor negotiation.
Usage runs on prepaid credits. New accounts receive a small free allowance for testing, and credits are purchased through the platform before production use.
Create a key from the dashboard. Because a single key can reach every model in the catalogue, key management deserves the same care as any high-privilege credential — the terms make you solely responsible for keeping account credentials confidential.
This is usually the shortest step. The API implements the OpenAI specification, so you send standard HTTP requests to the /api/v1/chat/completions endpoint — in most cases changing a base URL and an API key in an existing OpenAI SDK integration is sufficient.
Decide whether to name a specific model, or delegate to the Auto Router. Naming a model gives determinism; the Auto Router gives adaptation as the model landscape changes. Many teams do both — pinned models for output-sensitive paths, auto routing for general work.
If you have constraints, express them explicitly rather than accepting defaults. Set price ceilings for cost control, latency or throughput thresholds for user-facing paths, and data collection or zero-retention restrictions where compliance requires. These are per-request parameters, so different code paths can carry different policies.
Verify that fallback behaves as you expect for your configuration, especially if you have narrowed the provider list. Restricting providers aggressively reduces the pool available to fall back to, which quietly weakens the reliability benefit you adopted the platform for.
Use the dashboard analytics to track consumption by model and application. Because per-token costs vary by orders of magnitude across the catalogue, a routing change can move spend substantially, so treat monitoring as part of the integration rather than an afterthought.
Set a maximum price per request. The max_price parameter is the simplest guard against an unexpectedly expensive model being selected. On automatic routing paths especially, this converts an open-ended cost into a bounded one.
Match the routing strategy to the code path. Use pinned models where output consistency matters — prompts tuned against one model can behave differently on another. Use auto routing where the task is generic and adaptation to a moving market is worth more than determinism.
Do not over-restrict your provider list. Narrowing to a single preferred provider reproduces the single-point-of-failure you were trying to escape. Allow fallbacks unless a specific compliance rule forbids it.
Express data policy in code, not in a document. If your workload must avoid retention, set the zero-retention restriction and the data collection policy on the request. A configured constraint is enforceable; a written intention is not.
Use the free models for evaluation, not production. The documentation is explicit that free models carry low rate limits and are usually not suitable for production use. They are a testing convenience.
Verify the plugin id when configuring auto routing. Settings sent under the wrong slug's plugin id are accepted but silently ignored — a failure mode that produces no error while your model restrictions and cost tier quietly do nothing.
Attribute your app if you want visibility. The optional attribution headers place your application on the public leaderboards, which is useful for discovery if you are building something public-facing.
Budget before you scale. Workspace budgets and analytics exist because token spend grows non-linearly with usage. Configure limits before a traffic spike rather than after an invoice.
Application developers integrating LLMs are the core audience — anyone who would otherwise write and maintain integrations against multiple model APIs.
Teams optimising inference cost benefit from pass-through pricing plus routing controls, which together allow deliberate cost-versus-quality decisions per request rather than one global compromise.
Engineers responsible for production reliability get automatic failover across providers, which is difficult and tedious to build well in-house.
Agent builders are served by the Agent SDK and by the resilience that multi-step workloads require.
Enterprises with governance requirements are addressed through workspaces, SSO, SCIM, regional routing and data policy controls.
AI researchers and evaluators can compare many models through one interface without separate accounts for each.
Who this is not for: end users looking for a chat assistant. Although a chat interface exists on the site, this is developer infrastructure, and using it means writing code or configuring an application. Anyone wanting a ready-made consumer product should use a consumer product instead. Teams committed to a single provider with an enterprise contract may also find the routing layer adds little.
OpenRouter is delivered as a web API, so the practical platform question is not operating system but integration surface. The API implements the OpenAI specification at the chat completions endpoint, which means any language with an HTTP client can use it, and existing OpenAI SDK code typically works with a changed base URL.
Officially maintained integration paths include the raw API, typed client SDKs and an Agent SDK. Beyond those, the documentation provides dedicated guides for LangChain … LiveKit … Langfuse … Mastra … OpenAI SDK … Anthropic Agent SDK … PydanticAI … Replit … TanStack AI … Vercel AI SDK … Xcode … Zapier, which is a useful signal: these are first-party documented integrations rather than community claims.
The published scale figures on the homepage are 200T+ Monthly Tokens, 10M+ Global Users, 80+ Providers, 500+ Models. Treat these as vendor-reported and as a snapshot — investor commentary from a different period cites materially different counts, which tells you these numbers move quickly and should be checked live rather than quoted from any article, including this one.
Team and enterprise capabilities include workspaces with budgets, single sign-on, SCIM group mappings, and for enterprise customers, in-region routing in the EU and US.
The pricing model is the most frequently misunderstood aspect of OpenRouter, and it is unusual enough to state precisely.
There is no markup on inference. The documentation is explicit: We pass through the pricing of the underlying model providers without any markup, so you pay the same rate as you would directly with the provider. Per-token costs are therefore whatever the provider charges. Because those rates vary widely across a catalogue of hundreds of models and change as providers adjust their own pricing, no specific per-token figure is quoted here — check the models page for current rates.
Revenue comes from credit purchases. A fee is charged when you buy credits, not when you make inference calls. The company describes this as a small fee and reiterates that provider pricing is never marked up. The exact percentage is presented dynamically on the site rather than in retrievable page text, so verify the current figure at the point of purchase.
Credits are prepaid, with defined limits. Purchases run from a minimum of five dollars to a maximum of twenty-five thousand dollars per transaction. Stripe payments settle in U.S. dollars and Coinbase payments go through a crypto wallet, and auto-recharge can top up the balance when it falls below a threshold you set.
Bring your own key has its own economics. If you hold direct provider contracts, BYOK lets you use them through the platform. It carries a plan-dependent free allowance measured by list-price inference cost, not request count — an important distinction, since the allowance is consumed by expensive calls faster than by numerous cheap ones. Usage beyond the allowance incurs a percentage fee deducted from credits.
Free access exists but is deliberately limited. New accounts get a small free allowance, and the catalogue includes free models. These carry low daily request caps and are usually not suitable for production use. Notably, the free-model rate limit scales with credits purchased, so paying accounts receive higher free-tier ceilings.
Refunds are narrow. Unused credits may be refunded within twenty-four hours of the transaction; after that window, any unused Credits become non-refundable. Cryptocurrency payments are not refundable at all. Buy in increments you expect to consume.
No subscription. The homepage promise of no subscriptions is accurate for the standard product — you pay for what you use rather than a recurring platform fee, with enterprise arrangements handled separately.
The comparison set depends on which part of the value you are replacing.
Direct provider APIs — OpenAI, Anthropic, Google and others. Going direct removes a dependency and any credit-purchase fee, and is reasonable if you have settled on one provider. You give up cross-provider failover, unified billing and the ability to switch models without integration work.
Other aggregation and gateway layers — Together AI, Fireworks, Replicate and similar services also offer multi-model access, though with different catalogue composition and pricing structures. The distinguishing questions are breadth of catalogue, whether pricing is marked up, and how sophisticated the routing controls are.
Self-hosted gateways — LiteLLM and comparable open-source proxies give you the unified-interface benefit while keeping the routing layer inside your infrastructure. You avoid the third-party dependency and any fees, and you take on the operational burden of running, updating and monitoring it yourself, plus maintaining provider accounts individually.
Cloud provider model gardens — AWS Bedrock, Google Vertex AI and Azure AI Foundry offer multi-model access within their own ecosystems. These integrate naturally with existing cloud commitments and compliance postures, but their catalogues are narrower and typically slower to add newly released models.
The honest summary: OpenRouter competes on catalogue breadth, routing sophistication and the no-markup pricing structure. If you use one model from one provider forever, direct is simpler. If model choice is an ongoing decision, the layer earns its place.
You are adding a dependency on your critical path. Every inference call passes through a third party. This buys resilience against individual provider outages but introduces the platform itself as a potential point of failure. For applications where model calls are load-bearing, this trade should be a deliberate architectural decision.
A latency hop is unavoidable. Routing through an intermediary adds network overhead relative to calling a provider directly. The company works to minimise this, and latency preference controls exist, but the hop is real and matters for tight interactive loops.
Credits are prepaid and the refund window is short. Unused credits become non-refundable after twenty-four hours, crypto payments are never refundable, and the terms state that Credits are not legal tender or currency. Deleting your account forfeits unused credits.
Silent configuration failures are possible. The auto-routing plugin id mismatch is the clearest example: incorrect settings are accepted but silently ignored, so model restrictions and cost tiers can fail to apply without raising an error. Verify configuration effects rather than assuming they took hold.
Free models are not a production tier. Low rate limits and explicit guidance that they are unsuitable for production mean the free catalogue is for evaluation only.
Data handling is configurable, which means it is your responsibility. The default for the data collection policy is to allow providers that may store data. Zero-retention routing and policy restrictions are available, but they must be set. A team that assumes strict handling by default may be wrong about its own posture.
Usage rules are enforceable contract terms. The terms prohibit illegal use, identity misrepresentation, scraping, circumventing security features and unauthorised red teaming of models. Research teams planning adversarial testing should read this clause before starting.
Vendor-reported metrics vary by source. Model counts, provider counts and token volumes differ between the homepage and third-party write-ups from different periods. Treat any specific figure as time-sensitive.
Model behaviour is not uniform. A prompt tuned for one model may perform differently on another, so automatic routing can change output characteristics. Where consistency matters, pin the model.
It is developer infrastructure. The product is an API that your application calls, plus the routing, billing and observability around it. A chat interface exists on the site for trying models and debugging prompts, which is why some directories misfile it, but using OpenRouter meaningfully requires writing code or configuring an application.
No. The documentation states that provider pricing is passed through without markup and that you pay the same rate as you would directly with the provider. The company's revenue comes from a fee charged when you purchase credits, not from inference.
A lightweight classifier assigns your prompt one of roughly thirty fine-grained task types, then the router ranks models by how much the OpenRouter community actually spent on that task type over a trailing seven-day window. It behaves like a market index, shifting toward models that gain real-world adoption for that kind of work.
Usually not. The API implements the OpenAI specification at the chat completions endpoint, so an existing OpenAI SDK integration typically works after changing the base URL and API key. Typed client SDKs and an Agent SDK are available if you want more than raw HTTP.
The platform automatically falls back to the next provider, transparently to your application. This is the core reliability argument: your code does not need its own retry and rerouting logic to survive a single provider's outage.
New accounts get a small free allowance, and the catalogue includes free models. Those free models have low daily request limits and the documentation states they are usually not suitable for production. The free-model limit increases once you have purchased credits, so the free tier is best treated as an evaluation path.
Yes, and this is a per-request configuration rather than an account-wide setting. You can set the data collection policy to deny providers that may store data, restrict routing to zero-retention endpoints only, and use allow or ignore lists for specific providers. Enterprise customers can additionally require in-region routing in the EU or US.
Yes, through BYOK. It carries a plan-dependent free allowance measured by list-price inference cost rather than request count, and usage above that allowance incurs a percentage fee deducted from your credits. This suits teams that already hold negotiated provider contracts but still want unified routing.
Only within twenty-four hours of the transaction, via the refund button on the credits page. After that window unused credits are non-refundable, and cryptocurrency payments cannot be refunded at all. Unused credits are also lost if you delete your account.
Three considerations dominate. You add a third party to your inference critical path. You accept an additional network hop and its latency cost. And you commit to a prepaid credit model with a narrow refund window. If you have standardised on one provider under an enterprise agreement, or if you need absolute minimum latency, calling that provider directly may serve you better.
