OpenRouter - Unified Interface for LLM Access

OpenRouter sells itself as “One OpenAI-compatible API in front of hundreds of models.” The useful thing about that pitch is that you do not have to believe it: the catalogue is a public, unauthenticated endpoint, and reading it tells you more about whether the service fits your project than any marketing page can.

curl -s https://openrouter.ai/api/v1/models | jq '.data | length'

No key, no account. Run it and you get the inventory. We did, on 11 October 2026, and the numbers below come from that response rather than from the homepage.

What the catalogue actually contained

458 models, across 62 distinct author namespaces — Anthropic, OpenAI, Google, Meta, Mistral, DeepSeek, Qwen, xAI, Cohere, NVIDIA, IBM Granite, Microsoft, Perplexity and a long tail of smaller labs and fine-tuners. “Hundreds of models” is accurate and, if anything, understated.

Eighteen of those entries are ~-prefixed aliases such as ~anthropic/…-latest, which track a moving target rather than a pinned build. That distinction matters: an alias is convenient for a prototype and a liability in production, where you want the behaviour you tested. Pin the dated slug.

Nineteen models were priced at zero for prompt tokens — a real free tier for evaluation, though a free tier is also where rate limits and data-handling terms deserve the closest reading.

The capability split is the part worth planning around

Not every model behind one API can do what your code assumes. Counted from supported_parameters:

390 of 458 support tools — function calling.
391 support response_format, and 377 support structured_outputs.
330 expose reasoning controls (reasoning / include_reasoning).
144 support logprobs.
Only 19 offer web_search_options.

So roughly 85% of the catalogue will take a tool-calling request and about 4% will do a web search for you. If your application is built on tool calls, most of the inventory is available to you; if it depends on logprobs for scoring or evaluation, two thirds of it is not, and discovering that at runtime is an avoidable outage.

Modality follows the same pattern: 149 entries are text-only, while the remaining 309 accept some combination of images, files, audio or video. A “unified interface” unifies the transport, not the capabilities.

Two fields almost nobody mentions

The schema carries two bits of planning information that rarely make it into a comparison blog post.

expiration_date was set on 18 models. Those entries have a published retirement date. If you are choosing a model for something with a twelve-month life, checking this field before you commit is the cheapest migration planning available — and it is machine-readable, so a CI job can warn you when a model you depend on acquires one.

knowledge_cutoff was present on 172 models and absent on the rest. If your product makes any claim about currency, that is the field to read, and its absence is itself a finding.

Alongside those, 140 models reported is_moderated: true on their top provider — meaning an additional moderation layer sits in front of them. Useful to know in both directions, depending on whether that is a compliance requirement or an interference risk for your use case.

On price, and on the “no markup” claim

OpenRouter states it takes “no markup on the provider’s price.” The catalogue prices per token, which makes the spread easy to miss until you normalise it: the cheapest paid model in the response worked out to about $0.016 per million prompt tokens, and the most expensive, openai/o1-pro, to $150 per million — a range of roughly four orders of magnitude.

That o1-pro figure is also a useful sanity check on the unit interpretation, because it matches the price OpenAI publishes directly. The arithmetic lines up, which is the kind of corroboration worth doing once before trusting a feed.

Separately, 304 models published an input_cache_read price, usually a small fraction of the prompt price. For any agent that re-sends a long system prompt on every turn, prompt caching is the largest single cost lever available, and the catalogue tells you which models support it before you build around it.

How to use this

The honest recommendation is not “adopt OpenRouter” or “don’t”. It is: treat the models endpoint as a configuration source rather than reading it once by hand.

A fifteen-line script that fetches the catalogue, filters on the parameters your code requires, and fails your build when a model you depend on loses a capability, gains an expiration_date or changes price is worth more than any amount of comparison-shopping. The endpoint is free and needs no key, so there is no reason not to.

This pattern shows up downstream, too. Agent projects frequently name OpenRouter as a supported provider precisely because it collapses provider integration to one base URL — dexter and TradingAgents both list it among their options, which is the practical argument for the layer: you swap a model string instead of a client library.

The trade remains real. You add a dependency between your application and the providers, and you inherit its availability. What the catalogue shows is that the optionality you are buying is substantial and specific — and that the specifics are published, in JSON, for anyone willing to run one curl.