What Is OpenRouter? How the AI Gateway Works

What is OpenRouter? It is an AI gateway that connects your application to multiple model providers through one API and account. Here is how model selection, provider routing, billing, and fallbacks fit together.

OpenRouter in one sentence

OpenRouter is a gateway for calling many AI models through one OpenAI-compatible API. You choose a model ID, send a request to OpenRouter, and OpenRouter selects an eligible provider endpoint, forwards the request, returns the response, and records the usage against your OpenRouter account. The model provider still does the inference. OpenRouter is the access, routing, billing, and observability layer around that inference.

That distinction matters. OpenAI, Anthropic, Google, Meta, and other labs create or operate models. OpenRouter does not turn one model into another, and an OpenRouter account is not an OpenAI or Anthropic account. It gives your application one place to reach models from different providers, rather than making you integrate each provider separately.

Checked October 15, 2026: OpenRouter’s catalog, prices, providers, limits, and routing behavior can change. Treat the official models browser and Models API documentation as the live source of truth.

What OpenRouter actually does

Think of a request as passing through five layers:

1. Your application. It creates a chat-completions request and authenticates with an OpenRouter API key.
2. The OpenRouter API. The request arrives at https://openrouter.ai/api/v1/chat/completions, using a familiar OpenAI-style shape.
3. Model and endpoint selection. OpenRouter finds the requested model and eligible providers. A model can have more than one provider endpoint.
4. Inference. The selected provider runs the model and produces tokens. OpenRouter can fall back to another eligible provider if an attempt fails.
5. Response and accounting. OpenRouter returns the completion, usage, and the model that served the request. Paid usage is deducted from your credits at the posted provider rate.

The gateway is useful because those layers are otherwise your integration problem. You would need separate authentication, model names, SDK behavior, failure handling, billing pages, and usage records for each provider. OpenRouter gives you a common request shape and a central place to change the model without rewriting the entire application.

OpenRouter versus an AI model provider

Question	OpenRouter	Model provider or lab
What is it?	A multi-provider gateway and API platform.	The company or service operating a model endpoint.
What do you select?	A catalog model ID, plus optional provider preferences.	That provider’s model and account endpoint.
Who performs inference?	The provider endpoint OpenRouter routes to.	The provider’s infrastructure.
Where do you manage the integration?	One API base URL, key, credit balance, and activity view.	That provider’s API, account, limits, and billing.
What happens when an endpoint fails?	OpenRouter can try another eligible endpoint.	You normally implement your own fallback or use the provider’s feature.

OpenRouter’s own FAQ describes it as a proxy that sends requests to model providers. It also says that inference prices are passed through without a markup, while credit purchases carry a platform fee. In other words, “one API” does not mean “OpenRouter became the model vendor.” It means the gateway standardizes the path to vendors.

How routing works

For a model with several providers, OpenRouter’s default strategy balances price and recent reliability. The provider-selection documentation says it first avoids providers with significant recent outages, then favors lower-cost candidates using weighted selection, and keeps other eligible providers as fallbacks. If you specify an explicit order or sort, that default load balancing is disabled.

You can leave routing alone for a quick prototype, or make the trade-off explicit in the request:

"provider": {
  "sort": "throughput",
  "allow_fallbacks": true,
  "require_parameters": true
}

Useful controls include:

• order to try named providers in a particular order;
• only and ignore to constrain the provider pool;
• allow_fallbacks to turn backup endpoints on or off;
• require_parameters to use only providers supporting every parameter in your request;
• data_collection and zdr to enforce data-retention preferences where eligible endpoints exist;
• sort: "price", "throughput", or "latency" to state what you value most.

There are also routing variants. A suffix such as :floor sorts eligible endpoints by price, while :nitro sorts by throughput and makes priority endpoints eligible. These are routing instructions, not new model weights. A catalog variant such as :free is different: it is its own model entry with its own availability and limits.

Models, providers, and model IDs

OpenRouter’s model catalog exposes a standardized object containing an ID, description, context length, architecture, supported parameters, provider information, and pricing. Pricing can include input tokens, output tokens, fixed request charges, image input, web search, internal reasoning, and cache reads or writes. Values in the API are in US dollars per token, request, or unit, so do not copy a raw decimal without understanding its unit.

Use the catalog rather than hard-coding a model from a blog post. The API supports filters for output modality and supported parameters, and it can sort by price, context, throughput, latency, popularity, or newest. That matters when a model is deprecated, a free variant disappears, or a provider changes its endpoint. Pin an explicit model version when reproducibility is more important than automatically following a family alias.

A reproducible first request

Set an environment variable before running this example. Do not paste a real key into source code, a notebook shared publicly, or a browser bundle.

export OPENROUTER_API_KEY="sk-or-your-key"

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5.2",
    "messages": [
      {"role": "user", "content": "Return exactly one short sentence about APIs."}
    ],
    "max_tokens": 40
  }'

A successful response has a familiar shape. The exact text depends on the selected model, so inspect the response model and usage:

{
  "model": "openai/gpt-5.2",
  "choices": [{"message": {"role": "assistant", "content": "An API lets software exchange capabilities through a defined interface."}}],
  "usage": {"prompt_tokens": 14, "completion_tokens": 15, "total_tokens": 29}
}

If you use openrouter/free, the model field shows which free model actually served the request. That is useful for logging and for explaining why two supposedly identical free requests behaved differently.

What you pay for

OpenRouter credits are deposits used for inference. Paid requests are calculated from the selected model and provider’s posted pricing. Input and output tokens can have different rates; some models also charge per request, image, web-search operation, reasoning token, or cache operation. OpenRouter says it does not mark up inference pricing, but it does charge a fee when you purchase credits. Read the pricing page on the day you buy credits rather than assuming a static percentage.

Failed provider attempts are not the same as successful inference. The current pricing FAQ says a failed attempt is not charged for its model tokens, and routing through an automatic router adds no separate routing fee. Auxiliary services can have their own charges, so inspect the model and feature pricing before assuming every request is token-only.

Privacy and reliability are configuration questions

OpenRouter’s FAQ says basic request metadata such as timestamps, model, and token counts is logged, while prompts and completions are not logged by default; it also says provider retention policies affect where a request can be routed. Read the provider-logging and data-retention documentation for the plan and providers you intend to use. A gateway does not make every provider’s privacy policy identical.

Likewise, fallback is not a guarantee of identical output. A different provider can have different latency, tokenizer behavior, context limits, tool support, or response style. If your application depends on a particular parameter or schema, use require_parameters, validate the response, and log the serving model.

Troubleshooting checklist

• 401: check that the Bearer token is present, copied correctly, active, and loaded into the process that made the request.
• 404 or no endpoints: check the model ID and whether the model has been deprecated. Query the Models API instead of guessing a slug.
• 402: inspect error.metadata.limit_source. The problem can be account credits, a per-key cap, or a temporary in-flight spending budget.
• 403: an organization, workspace, guardrail, or key budget may be exhausted.
• 429: free-model caps or provider protection may be involved. Read the response headers and the limits documentation.
• Tool or structured-output failure: the selected provider may not support the parameter. Require supported parameters or constrain provider selection.
• Unexpected cost: inspect actual usage, model pricing, long-context overrides, images, tools, and provider selection; do not estimate from output tokens alone.

A practical decision rule

Use OpenRouter when the value is optionality: you want to compare models, keep a fallback path, centralize usage, or avoid writing a separate adapter for every provider. Go directly to a provider when you need that provider’s proprietary account features, contractual terms, region controls, or a capability that OpenRouter does not expose yet. Neither choice is automatically more reliable. The right question is which boundary you can monitor and operate.

For a small experiment, begin with one explicit model and no routing overrides. Add fallbacks only after you have measured what changes when the provider changes. In production, store the returned model, usage, latency, status code, and request ID. That turns “the AI was weird today” into a diagnosable event.

Limitations worth planning for

• A common API shape does not make every model support the same parameters.
• Fallback can improve availability but can change output quality, latency, privacy characteristics, and cost.
• The catalog and pricing are current metadata, not a forever contract. Refresh model information and pin versions where needed.
• Free routing is useful for prototypes but is not a stable capacity guarantee.

What is OpenRouter FAQ

Is OpenRouter an AI model?

No. It is a gateway that exposes models from many providers through a common interface.

Can I use an OpenAI SDK?

Yes. OpenRouter documents an OpenAI-compatible base URL, https://openrouter.ai/api/v1. You still use OpenRouter model IDs and OpenRouter authentication.

Does one model ID always mean one server?

No. A model can have multiple provider endpoints, and routing can select among them. Log the returned model and configure provider preferences when the distinction matters.

Is OpenRouter always cheaper than going direct?

Not automatically. OpenRouter says it passes through inference list pricing, but credit purchases have fees and providers can differ in features or commercial terms. Compare the whole workflow, not only a token price.

Where should I go next?

For a broader implementation path, read our OpenRouter API guide. Also see our n8n credentials guide and the AI agent security checklist.

Official references

• OpenRouter FAQ
• Provider routing

Documentation reviewed 15 October 2026. Examples illustrate the request pattern; confirm model availability and account settings before use. No uptime or performance benchmark is claimed.