OpenRouter is a hosted gateway that gathers hundreds of AI models from different providers behind a single OpenAI-compatible API. Instead of opening an account and juggling keys at Anthropic, Google, Mistral and half a dozen more, you point your client at one address, pay from a single balance and pick the model by name. In this guide you will see what OpenRouter is, how its single API opens up hundreds of models, how routing, failover and pricing work, how to call it from your agent, and how it differs from running your own proxy with LiteLLM. The same explanation is available in Spanish.

Key takeaways

  • OpenRouter is a hosted gateway (SaaS): you install and maintain nothing. Its official tagline says it plainly: "The Unified Interface For LLMs".
  • A single OpenAI-compatible API opens up more than 400 models from over 70 providers; by July 2026 it moved around 100 trillion tokens a month for more than 10 million users.
  • You change the base URL to https://openrouter.ai/api/v1 and use one key; the rest of your OpenAI client code stays untouched.
  • It ships automatic routing, failover (a list of backup models) and per-provider preferences to prioritise price, throughput or latency.
  • Pass-through token pricing: you pay the provider’s rate; OpenRouter charges a 5.5% fee when you top up your balance. There are even free models with usage limits.

What is OpenRouter?

OpenRouter is a hosted gateway that sits between your application and the model providers. Its pitch is direct: one account, one key and one balance give you access to almost every commercial and open model on the market, with no separate contracts or credentials to manage with each company. Its own site defines it as "The Unified Interface For LLMs".

The service was founded in 2023 by Alex Atallah, co-founder of the NFT marketplace OpenSea, and it has grown fast. After a 12.5-million-dollar seed round led by Andreessen Horowitz and a Series A that lifted total funding to 40 million in June 2025, in 2026 it closed a Series B of 113 million led by CapitalG, the growth fund of Alphabet (Google’s parent). That round put its valuation at around 1.3 billion dollars, more than double a year earlier. Behind a tool that looks like a simple shortcut, then, is a company with resources and a clear business model.

The figure that best explains its traction is volume: by July 2026 the platform claimed to process around 100 trillion tokens a month from more than 250,000 applications. It is not an experiment: it is infrastructure already moving production traffic at scale.

A single API for hundreds of models

OpenRouter’s core value is the catalogue. From a single access point you call more than 400 models from over 70 providers: OpenAI’s GPT family, Anthropic’s Claude, Google’s Gemini, the models from Mistral, DeepSeek, Meta or xAI, and open weights that other providers serve on your behalf. Each model is identified by a string of the form provider/model, for example openai/gpt-4o or anthropic/claude-3.5-sonnet.

This solves a very concrete problem. When your product wants to compare two models, or migrate from one to another because a better or cheaper version shipped, without OpenRouter you would have to register a new account, generate a key, add a card and adapt that provider’s SDK. With OpenRouter, switching from anthropic/claude-3.5-sonnet to openai/gpt-4o is editing a string. That zero friction turns model evaluation, a theme we also touch on when discussing open models with tool calling, into something you can do on the fly.

A given open model is usually available through several inference providers, each with its own price, speed and reliability. OpenRouter presents them together and, unless you say otherwise, spreads traffic across them according to your preferences. You see one model; underneath is a marketplace competing to serve your request.

Routing, failover and pricing

This is where OpenRouter stops being a mere catalogue. Routing is controlled with two mechanisms.

The first is the list of backup models. You can send a models field with several names ordered by preference: OpenRouter tries the first and, if it fails or is unavailable, moves to the next without your application noticing. There is also the auto-router (openrouter/auto), which picks a suitable model for each request. The second is the provider object, with which you fine-tune which inference providers are used (order, only, ignore) and how they are sorted (sort). You can prioritise the lowest price (sort: "price"), the highest throughput (sort: "throughput") or the lowest latency (sort: "latency"). As a shortcut, adding :floor to the model name forces the minimum price and :nitro forces maximum throughput.

The pricing model is what most surprises anyone arriving from other gateways. OpenRouter adds no per-token markup: you pay exactly the same rate you would pay going straight to the provider. Its business is a 5.5% fee applied when you top up your balance (5% if you pay with cryptocurrency): if you deposit 100 dollars, you are credited 94.50 in inference. In exchange for that fee you avoid managing a dozen invoices and contracts. On top of that, the catalogue includes dozens of free models, handy for prototyping, though with usage limits (on the order of 20 requests per minute and 200 a day).

Using it from your agent (OpenAI-compatible API)

The reason OpenRouter is adopted in minutes is that it speaks the dialect almost the whole ecosystem already uses: the OpenAI API. There is no mandatory in-house SDK. You take your OpenAI client, change the base_url and the key, and keep calling chat.completions.create as always. This Python example routes the request to Claude through OpenRouter:

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="your-openrouter-key",
)

response = client.chat.completions.create(
    model="anthropic/claude-3.5-sonnet",
    messages=[{"role": "user", "content": "Explain what a model gateway is"}],
    extra_headers={
        "HTTP-Referer": "https://jacar.es",
        "X-Title": "My agent",
    },
)
print(response.choices[0].message.content)

The HTTP-Referer and X-Title headers are optional: they identify your application so it appears on OpenRouter’s public leaderboard. Failover is declared in the request body itself, with no extra code, by passing a models list instead of a single name:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["openai/gpt-4o", "anthropic/claude-3.5-sonnet"],
    "provider": {"sort": "price", "allow_fallbacks": true},
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Because it speaks OpenAI, it fits out of the box with agent frameworks and observability tools. You can, for instance, put Helicone in front to measure cost and latency, or take advantage of the prompt caching to cut costs that several of the catalogue’s models offer.

OpenRouter versus a self-hosted proxy (LiteLLM)

The natural comparison is with LiteLLM, the open-source proxy that unifies model providers. They solve the same problem, unifying access to many models, but from opposite philosophies.

LiteLLM you run yourself. It is free software you deploy as your own server; you supply your own provider keys, and in exchange you control everything: virtual keys per team, budgets, redaction of sensitive data, and no traffic leaving your perimeter. The cost is that you administer that piece, with its database and its updates. OpenRouter someone else runs. You deploy nothing, supply no provider keys and maintain no infrastructure; in exchange, your traffic and your billing pass through a third party, and you depend on its availability and its data policy.

The rule of thumb is simple. If you want immediate access to the whole model market, to experiment without opening ten accounts and to run no servers, OpenRouter wins. If you need control over your own keys, per-team governance or data that never leaves home (for example, serving models on your own machine with Ollama), a self-hosted proxy like LiteLLM is the answer. They are not mutually exclusive: it is common to use OpenRouter to prototype and test models, and migrate critical workloads to a self-hosted proxy once volume and compliance demands justify it.

Frequently asked questions

Does OpenRouter make calls more expensive than going straight to the provider?

Not per token: OpenRouter passes through the provider’s rate with no markup, so the price per million tokens is the same you would pay directly. The cost is the 5.5% fee when you top up your balance (5% with cryptocurrency). In practice, for most teams that fee is smaller than the time spent managing several accounts, keys and invoices separately. If you move very high volumes and only use one or two providers, going direct may come out slightly cheaper.

Do I need to learn a new SDK to use OpenRouter?

No. OpenRouter exposes an OpenAI-compatible API, so you reuse the OpenAI client (or any library that already speaks it) by changing only the base_url to https://openrouter.ai/api/v1 and the key. Most agent frameworks and observability tools work unchanged, because they assume that same dialect.

Is it safe to send sensitive data through OpenRouter?

It depends on your case. Being a hosted gateway, your prompts travel through a third party before reaching the provider, which can clash with strict compliance requirements. OpenRouter lets you exclude specific providers and offers privacy controls, but if the requirement is that no data leaves your network, the right option is a self-hosted proxy such as LiteLLM or serving the model on your own infrastructure.

Conclusion

OpenRouter turns the fragmentation of the model market into a single line of configuration: an OpenAI-compatible API, one key and one balance give you access to more than 400 models with routing, failover and pass-through token pricing. It is the fastest way to test and combine models without opening ten accounts or standing up servers, backed by a company valued at around 1.3 billion dollars. Its downside is the dependence on a third party, which is precisely what you avoid with a self-hosted proxy like LiteLLM. The next step is to create a key, point your client’s base_url at OpenRouter and compare two models with the same code.

Sources

  1. Official OpenRouter documentation
  2. Provider routing in the OpenRouter docs
  3. OpenRouter repositories on GitHub
  4. OpenRouter more than doubles valuation to 1.3B, in TechCrunch

Route: Agent Ecosystem: MCP, Gateways and Platforms