What Is OpenRouter? One API for Hundreds of Models

The model ID is the first thing people misread about OpenRouter: the anthropic/ in anthropic/claude-sonnet-4.5 names the developer that released the model, not the company that will run your request. OpenRouter is a hosted router. You send an OpenAI-compatible chat-completion call to https://openrouter.ai/api/v1, the model field carries a catalog ID, and OpenRouter selects a hosting provider that serves that model, returns the answer in chat-completion format, and deducts the cost from your prepaid credit balance. One key and one balance cover every model in the catalog, and the provider behind any single call gets decided at request time.

Four things decide whether it fits your stack: where a request goes, which key and base URL you configure, how you pick a model ID, and what the credits and platform fee cost.

What is OpenRouter?

OpenRouter is a hosted API router. One OpenAI-compatible interface provides model access, provider routing, and consolidated billing, and OpenRouter works the access layer between your code and the hosting providers instead of replacing the models themselves. Your client sends every request to the same endpoint, and a provider OpenRouter selects runs the model.

The catalog is where model selection happens. Each entry maps an ID string such as anthropic/claude-sonnet-4.5 to a concrete model and lists context length, supported input types, and price. The prefix in that ID identifies the developer that released the model; it does not by itself name the provider that will host your request. Models such as meta-llama/llama-3.3-70b-instruct are served by several hosting providers under the same ID, which is exactly why a routing layer has to exist.

Making the service work takes three jobs:

• The catalog keeps model names, capabilities, and prices current across a wide set of providers.
• Routing picks an eligible hosting endpoint for the model you named and reacts when that endpoint fails.
• Billing keeps per-vendor accounts out of your code, so one OpenRouter key and one credit balance replace one credential and one bill per provider.

If you already keep three provider accounts and reconcile three invoices, the billing layer is the part you notice first. If you want to compare models you have never run before, the catalog carries more of the value.

How does an OpenRouter request reach a model?

Three hops, and only the first one is yours: your application, OpenRouter, and a hosting provider that serves the model you selected. Everything after hop one happens behind the same OpenAI-compatible endpoint, which is why a working prototype needs no per-provider code.

What each hop does

Your application goes first. Your client POSTs a JSON body to https://openrouter.ai/api/v1/chat/completions using an OpenAI-compatible chat-completion shape: a model field, a messages array, and optional parameters such as temperature, max_tokens, or stream. Chat Completions is the route in the example, not the only inference route OpenRouter exposes.

OpenRouter handles the middle hop. Picture a switchboard operator who can see which lines are busy before connecting the call, and you have the right picture of the routing layer. It reads the catalog ID, checks which providers can serve that model at that moment, and selects an endpoint. The default strategy is price-based load balancing that prioritizes lower-cost providers while skipping providers with significant outages in the last 30 seconds. You can replace that default with per-request provider settings, covered in the model-selection section below. OpenRouter then forwards your messages to the chosen provider’s API.

The hosting provider runs the selected model on its infrastructure, and that is the last hop. Tokens return from that provider to OpenRouter, which returns them to your client in the OpenAI-compatible chat-completion format and adds usage fields such as prompt_tokens, completion_tokens, and total_tokens. For a plain-text, nonstreaming call like the one in the next section, the format is the one the OpenAI SDK parses, so existing parsing code handles this case. Tool calls, refusals, errors, empty choices, multimodal content, and streaming events each need their own handler.

If the upstream provider accepts the request, that path holds. If the provider is down or returns an error, OpenRouter can try another provider that serves the same model before the error reaches you. What happens next depends on the model and on the routing parameters covered in the model-selection section.

How do you make your first OpenRouter API call?

For credit-paid calls you need one OpenRouter account, one API key, and a credit balance on the account. The Keys area of the dashboard creates the key and lets you name it. OpenRouter also lets you set an optional per-key credit cap, and the GET /api/v1/key endpoint reports the remaining limit, so you can monitor it before requests start failing.

Use the OpenRouter key with the OpenRouter endpoint. Check the available balance, any per-key spending cap, and the catalog ID before the test. If the call fails, the response body tells you whether you hit a payment or key limit or are looking at transient throttling.

A minimal Python call with the OpenAI SDK

Install the openai package, put your own key in the OPENROUTER_API_KEY environment variable, then run the pattern that OpenRouter’s quickstart documents. Relative to a native OpenAI setup, two values change: base_url and api_key. The model string changes too, because catalog IDs carry a developer prefix such as anthropic/ or google/.

pip install openai
export OPENROUTER_API_KEY="your-key-here"   # use the key from your dashboard

from openai import OpenAI
import os

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

completion = client.chat.completions.create(
    model="anthropic/claude-sonnet-4.5",
    messages=[
        {"role": "user", "content": "Explain model routing in one paragraph."}
    ],
)
print(completion.choices[0].message.content)

The example prints a text response from a successful nonstreaming call. Before you depend on that output, handle SDK exceptions and confirm that a text choice is present. Error objects and partial streams get their own treatment in the prebuild checklist below.

Copy the full ID from the model’s catalog page, developer prefix included, into model. That page also lists input types and price. Credit-paid calls use the OpenRouter balance; BYOK uses your own provider credentials and a separate fee arrangement.

This compatibility note covers the plain-text, nonstreaming completion shown above. OpenRouter is a drop-in replacement for OpenAI for the endpoints it documents, but that does not make every native provider API interchangeable. If a model has provider-specific parameters or response behavior, read the model’s documentation instead of trusting an SDK default to transmit or parse it.

How do you choose which model to call?

You choose a model per request by sending its catalog ID in the model field. Each model page shows the exact ID, context length, supported input types, and current price. When several providers host the same ID, the routing layer decides which provider handles the call.

Request-level provider controls and fallbacks

OpenRouter’s provider-routing documentation defines request-level controls for the chat-completions route:

• only restricts the request to a list of provider slugs.
• ignore removes listed providers from consideration.
• order names the sequence of providers to try first, while other providers stay eligible as fallbacks unless disabled.
• allow_fallbacks, true by default, controls whether a backup provider may serve the request when the primary provider is unavailable.

Two other controls steer data and compatibility rather than speed. data_collection: deny limits routing to providers that do not store your data for training, and require_parameters: true limits routing to providers that support every parameter in the request. If no provider satisfies those constraints, the request can fail instead of silently ignoring the requirement.

Model-level fallbacks are separate from provider-level ones. A top-level models array lists the IDs to try in order, so when every provider for the first model is exhausted, the router can move to the next model you included.

A fallback can run only while an eligible backup remains: another provider serving the same model, or a fallback model you listed and that is eligible under the request’s own constraints. If none exists, the failure returns to your application. Test that path instead of assuming the router absorbs every outage.

What does calling OpenRouter cost?

OpenRouter is pay as you go and has no required subscription. You add credits to an account balance, and every paid request deducts its cost from that balance. For most models the deduction is a listed price per million tokens, and OpenRouter’s FAQ notes that some models also charge per request, per image, or for reasoning tokens; the model page shows which applies. The FAQ adds that each model and provider has its own price per million tokens, and that OpenRouter passes through provider inference pricing without markup.

The platform fee is separate from model consumption. On the pricing page checked September 20, 2026, Standard lists 5.5% and Business lists 8%; enterprise terms can differ. The FAQ places the credit-purchase fee at top-up. Compare the plan and checkout total, including any applicable taxes or payment charges.

Free models and a free tier exist for evaluation but carry documented limits far below paid usage. Credits also carry conditions: OpenRouter’s terms reserve the right to expire unused credits one year after purchase, refunds of unused credits are limited to the first 24 hours, and cryptocurrency purchases are never refundable. Read those three conditions before you deposit a large balance.

The fee structure, row by row

Each row separates what you consume from what you pay OpenRouter.

If the purchase fee changes your unit economics, the listed model rates and the credit-purchase fee of each candidate belong on the same sheet. When you want MixRoute’s fee model on that sheet, compare MixRoute prepaid pricing and let concrete rates, not category labels, make the call.

Is OpenRouter an AI gateway?

OpenRouter is a hosted model API router, and it performs the functions people usually group under an AI gateway: one interface for many models, catalog-based model selection, provider routing with fallbacks, and consolidated billing. Whether the gateway label applies depends on where the person using the term draws the boundary, and vendors draw it differently.

MixRoute describes itself as an AI API gateway focused on unified access, routing, reliability, and cost governance. OpenRouter describes itself as one API for any model. Vercel AI Gateway describes itself as a unified API to access hundreds of AI models. Three true descriptions with different labels is normal in this market, so a category name proves little about capabilities.

Ask functional questions instead:

• Does one OpenAI-compatible client reach the models you need?
• How is the fee expressed, and at what moment is it charged?
• Which provider controls exist per request?
• What happens when an upstream provider fails?

OpenRouter answers those with a model catalog, one credit balance, and request-level routing parameters. Before you sort products into categories, read how an AI API gateway is defined and apply the same yardstick to each vendor.

What should you check before you build on OpenRouter?

Much of the multi-provider integration work disappears once you route through OpenRouter, but a few checks separate a clean production path from surprises. None of them take long.

Check errors and partial output

With raw HTTP, a 200 status can precede a later generation error. Check a nonstreaming body for a top-level error and verify that choices contains the output you need. In streaming mode, handle error events as well as tokens. A retry after partial output starts a new generation; replace or clearly separate the partial result instead of appending fresh text as though it resumed the old response.

A short prebuild checklist

1. Confirm the models exist in the catalog today. Search for the exact IDs you plan to ship with and note each model’s context length and supported inputs. If an ID is missing, that capability is not available through OpenRouter at the moment.
2. Price a realistic month, not a single request. Estimate prompt and completion tokens per request, multiply each by the model’s listed per-million rates, and remember models that charge per request, per image, or for reasoning tokens. The platform fee lands when you buy credits instead of per request, so confirm the checkout total for your payment method.
3. Decide what the application does when a provider fails. Prefer a model that multiple providers serve, or configure a fallback models array, then test the failure case instead of assuming the router absorbs it.
4. Do not size production from free models or the free tier. Those are for evaluation and carry tighter documented limits. A paid workload needs the credit balance and the purchase fee in the operating budget from day one.
5. Compare before hardening an integration. The first code path tends to become the permanent one, and OpenRouter is one of several hosted routers, alongside direct provider contracts and self-hosted gateways. Review the OpenRouter alternatives breakdown against the same checklist before you commit.

It earns its place when model variety and one bill matter more than the credit-purchase fee.