OpenRouter

Anyone building with language models for more than a few months ends up with the same mess: four vendor accounts, four billing relationships, four SDKs with slightly different request shapes, and no way to compare cost or quality across them without writing an adapter layer first. Then a provider has a bad afternoon and your app goes down with it.

OpenRouter collapses that into one endpoint. It fronts 500+ models from 80+ providers behind a single OpenAI-compatible API, aggregates the billing into one credit balance, and pools provider uptime so that a failure at one supplier does not become a failure in your product. It implements the OpenAI specification for the /completions and /chat/completions endpoints, which is the practical part: any SDK that already talks to OpenAI talks to OpenRouter by changing the base URL and the key. There is also a browser chatroom for people who just want to try models side by side, plus support for text, images and PDFs, streaming over server-sent events, function calling, and prompt caching.

This is the part worth getting exactly right, because the model is unusual and widely misdescribed.

OpenRouter does not mark up inference. It passes through the underlying provider's pricing, so the per-million-token rate shown on the models page is what gets deducted from your balance. Its revenue comes from a 5.5% fee charged when you purchase credits, with a $0.80 minimum. Crypto payments in USDC are charged 5% instead. Credits are simply a dollar-denominated deposit that gets drawn down as you make requests, with manual or automatic top-ups.

Two consequences follow. First, the $0.80 floor makes small top-ups expensive in percentage terms — on a $10 purchase the minimum fee is an 8% effective rate, not 5.5% — so batch your top-ups. Second, the economics of OpenRouter get better the more models you use, because you are paying a one-off percentage on money in rather than a recurring premium on every token out.

Bring-your-own-key sits alongside this. You can plug your own provider credentials into OpenRouter and keep rate limits and commercial terms with the provider directly, while still getting the unified interface and analytics. Pay-as-you-go accounts include $25,000 per month of list-price inference with no BYOK fee; above that, OpenRouter charges 5% of what the same model and provider would have cost on its own platform, deducted from credits. Enterprise raises the allowance to $200,000 per month. Note that the allowance is measured in list-price inference value, not request count.

The fine print worth knowing before you load a large balance: there are no volume discounts on pay-as-you-go, refunds on unused credits are only available within 24 hours of purchase, platform fees are never refundable, crypto payments are never refundable, and the terms reserve the right to expire unused credits after a year.

There is a real free plan, and it is more than a trial. It covers 25+ free models across 4 providers, chat and API access, activity logs and export, auto-routing, budget and spend controls, prompt caching and data-policy-based routing. Models with the :free suffix are always free.

The ceiling is request volume, not features. Free-model usage is capped at 50 requests per day; purchase at least 10 credits and that rises to 1,000 requests per day. OpenRouter's own documentation says plainly that free models have low rate limits and are usually not suitable for production. Treat the free tier as a way to evaluate models, not to run on. A openrouter/free router endpoint will pick a free model automatically if you do not care which one.

The routing layer is the reason to use a gateway rather than write your own switch statement. When a provider returns an error, OpenRouter falls back to the next provider transparently — which is the single most valuable thing it does for anything running in production. Failed attempts and fallbacks are handled behind one request rather than becoming your retry logic.

On top of that, model slugs accept variant suffixes that change routing behaviour without changing your code structure. :nitro sorts providers by throughput rather than the default ordering, for when latency matters most. :floor sorts by price, for when cost matters most. :exacto sorts using quality-first signals tuned for tool-calling reliability, which is the one to reach for when an agent keeps mangling its function calls. Static variants also exist per model: :free, :extended for longer context, and :thinking for models that reason by default. The older :online web-search variant has been deprecated in favour of a dedicated server tool.

Every model page publishes time-to-first-token and throughput for each provider serving it, which is enough to make an informed routing decision rather than a superstitious one.

Most people arrive for the model catalogue and stay for the data policy, because it is stricter than the defaults at many individual providers.

OpenRouter logs request metadata — timestamps, model, token counts, latency — and states that it does zero logging of prompts and completions, even when a request errors, unless you explicitly opt in. Two opt-ins exist and both are off by default: private input and output logging, so you can inspect your own traffic for debugging, which OpenRouter says it does not access or use, and permission for OpenRouter to use your inputs and outputs to improve the product in exchange for a 1% discount on usage. In the chatroom, conversations are stored locally on your device rather than synced.

Downstream matters more. OpenRouter documents each provider's logging policy and will not route to providers that log, or whose policy it could not confirm, unless you turn the model-training toggle on in privacy settings. If you pin specific providers in a request but none of them meet the privacy level configured on your account, the request errors rather than quietly falling through to a weaker policy. For teams that would otherwise have to negotiate data terms lab by lab, that is a meaningful amount of procurement work done for you.

Be honest about the tradeoff: adding a gateway cannot make you faster than the fastest direct path to a provider. You are inserting a network hop and a routing decision between your application and the model. For most workloads that is invisible next to model generation time, and the :nitro variant plus published per-provider throughput data give you tools to manage it. But if your product's competitive edge is single-digit-millisecond response time against one specific model, direct integration is the right answer.

The other cost is abstraction. A unified OpenAI-compatible surface, by definition, exposes the common denominator well and provider-specific novelties less immediately. If you depend heavily on one lab's proprietary features, the gateway is friction rather than convenience.

Go direct when you have standardised. One lab, features you use deeply, an existing enterprise agreement — a gateway adds a fee and a hop and buys you little.

Use OpenRouter when model choice is a live question. That covers benchmarking several models on identical prompts, running production traffic that must survive a provider outage, reaching open-weights and smaller-lab models without opening a dozen accounts, consolidating spend across teams into one analytics dashboard, and enforcing a data-retention policy across a fleet of suppliers from one settings page. For that set of jobs, 5.5% on credit purchases is a modest price, and no-markup token pricing means the fee does not compound as you scale usage.