Managed only Proprietary

OpenRouter Managed marketplace

OpenRouter is a managed marketplace: an OpenAI-compatible API in front of 458 models from ~83 providers. There is no token markup; the paid surface is a 5.5% credit-purchase fee (minimum $0.80). It cannot be self-hosted. Zero data retention and SOC 2 are published; a HIPAA BAA is not. You can point it at your own provider accounts. Beyond chat it also serves image generation. EU data residency is available.

· 49 dated entries · 69 source references

Built by OpenRouter, Inc., founded 2023 · US company · EU region available

Compare with others Estimate cost Visit site ↗

Access at a glance

Whether this product can work for you at all, before features matter: who pays the model bill, where it can run, and which of your existing API calls keep working. Every value is the vendor’s own claim, linked to the page it came from.

Routing proxy in front of many providers. The vendor's FAQ says "OpenRouter is a proxy that sends your requests to the model provider for it to be completed" and "OpenRouter is a drop-in replacement for OpenAI" (OpenRouter FAQ); the quickstart calls it "access to hundreds of AI models through a single API endpoint" that "handles fallbacks automatically" (OpenRouter Quickstart).

Who pays the model bill

Your keys or their credits

You can start on their credits and move to your own provider accounts later.

"OpenRouter supports both OpenRouter credits and the option to bring your own provider keys (BYOK)" (BYOK).

Merchant of record: Differs by mode. Credits mode: OpenRouter invoices — "Credits are simply deposits on OpenRouter that you use for LLM inference… we deduct the request cost from your credits" (FAQ). BYOK mode: the upstream provider bills — "the provider bills you directly for inference and OpenRouter charges only the BYOK fee" (5% of list, deducted from credits, above the plan allowance) (Batch quickstart, BYOK).

Key handling: "Your provider keys are securely encrypted and used for all requests routed through the specified provider"; keys live in workspace BYOK settings, can be Prioritized or Fallback, and can be filtered by allowed_models, allowed_api_key_hashes, allowed_user_ids (100 entries max each) (BYOK). Content visibility: "OpenRouter does not store your prompts or responses, unless you opt in"; metadata (tokens, latency) is always stored and "does not include the content of your prompts or responses" (Data collection, FAQ). Batch inputs/results are stored as JSONL in Google Cloud Storage and deleted after 30 days (Batch quickstart).

Where it can run

1 of 5 shapes documented
  • Vendor-hosted
  • Self-host
  • Your VPC
  • On-premise
  • Air-gapped

Dimmed shapes are not documented by the vendor, which is not the same as unsupported.

Hosted SaaS only (documented). The enterprise page frames the model as "Bring your own capacity and use OpenRouter as SaaS" (OpenRouter Enterprise); no self-host, VPC, on-prem or air-gapped mode appears on the quickstart, FAQ, API overview, BYOK or enterprise pages fetched (FAQ, BYOK).

Nothing to install: customers call https://openrouter.ai/api/v1 (Quickstart). The "self-host"-like lever is BYOK/own capacity: "Use your AWS/GCP/Azure credits and get the best throughput combining your limits plus ours" (Enterprise). Tier gating exists for BYOK volume, not deployment: pay-as-you-go includes $25,000/month of BYOK inference free, Enterprise $200,000 (FAQ).

API surfaces your code can keep using

7 of 7 documented
  • OpenAI chat POST /v1/chat/completions Yes

    POST /api/v1/chat/completions, "implements the OpenAI API specification for /completions and /chat/completions endpoints" (API overview, FAQ).

  • Anthropic messages POST /v1/messages Yes

    Native Anthropic Messages surface documented as POST /messages on the https://openrouter.ai/api/v1 server (Create a message); also a valid Batch API shape as /v1/messages (Batch quickstart).

  • OpenAI Responses POST /v1/responses Yes

    "OpenAI-compatible Responses API endpoints" are listed in the API reference navigation (API reference) and /v1/responses is an accepted Batch endpoint shape (Batch quickstart).

  • Embeddings POST /v1/embeddings Yes

    /v1/embeddings is a documented batch shape ("Embeddings are rolling out on providers that support them") and models can be filtered with /api/v1/models?output_modalities=embeddings (Batch quickstart, Models).

  • Images POST /v1/images/generations Yes

    POST /api/v1/images (Image generation).

  • Audio POST /v1/audio/* Yes

    STT and TTS endpoint categories are listed in the API reference, and audio input/output runs through /api/v1/chat/completions (List all models, Audio).

  • Batch jobs POST /v1/batches Yes

    POST https://openrouter.ai/api/beta/batches, 24h completion window, text-only (Batch quickstart).

An asterisk marks a qualified verdict: support that is indirect (SDK compatibility or provider passthrough rather than a native endpoint), or a gap that is narrower or wider than the label suggests. Read the note before porting.

Drop-in base-URL swap: "any SDKs that support OpenAI by default also support OpenRouter" (FAQ); first-party SDKs (@openrouter/sdk, Python openrouter, Agent SDK) are optional (Quickstart). Schemas are "very similar to the OpenAI Chat API" but not identical, unsupported params are silently ignored, and streaming is SSE with an occasional comment payload to ignore; usage arrives once in the final chunk (API overview). Batch is text-only — image/audio/video/file parts are rejected (Batch quickstart).

How much it reaches

Models 458
Upstream providers ~83

Models: Counted from the vendor’s own published list; no aggregate total is published.

Count of entries returned by the models API on 2026-09-25. Includes every entry exposed by that endpoint; not a count of unique base models.

"83 of 83 providers" listed on the providers directory, page undated (OpenRouter Providers).

Whose models: Routed to third-party providers: "We pass through the pricing of the underlying providers; there is no markup on inference pricing" and OpenRouter "sends your requests to the model provider" (FAQ); routing falls back "to other providers or GPUs" (API overview). No statement of OpenRouter-owned inference hardware on any page fetched.

Your own endpoints: Partially: not documented for arbitrary vLLM/Ollama URLs, but BYOK supports customer-specific Azure deployment URLs — per-deployment config takes an explicit endpoint_url such as https://example-project.openai.azure.com/openai/deployments/... plus api_key, model_id, model_slug (BYOK). Generic private-URL registration: not documented.

How it behaves in production

What happens when an upstream model is slow, wrong, or down — and what you can see and stop while it happens. Reliability features are recorded as where you configure them, not whether the vendor lists them, because almost every product here lists all of them.

2 of 6 reachable from code 3 of 4 can block 1 documented destination

When something goes wrong

Each row says where the knob is, not whether the feature is on the marketing page. A control you can only reach by hand in someone else’s dashboard cannot be reviewed or version-controlled.

  • Request timeout Not documented

    The vendor does not document this, so any behaviour you observe today is unversioned and may change.

    No request-timeout header or key appears on the fetched routing/performance docs. The closest published control is a routing preference, not a timeout: preferred_max_latency (with preferred_min_throughput), evaluated against provider p50/p90/p99 over a rolling 5-minute window (OpenRouter latency and performance).

  • Retries Not documented

    No retry-count key or backoff strategy is published; the documented failure behavior is provider fallback, not a retry counter. Default retry count: n.a. Backoff: n.a. (OpenRouter model fallbacks).

  • Fallback to another model Per request

    Your application decides per call, so one noisy endpoint can have its own timeout without a redeploy.

    ORDERED. provider.order sets an explicit ordered provider list and allow_fallbacks (default true) controls whether other providers may be used (OpenRouter provider selection). Model-level fallback uses the models array, tried in order; via the Anthropic-compatible surface the key is fallbacks, limited to 3 entries (OpenRouter model fallbacks).

  • Load balancing Per request

    Weights are NOT user-settable: OpenRouter load-balances with price-inverse-square weighting internally; the user-facing controls are order, only, sort and the latency/throughput preferences (OpenRouter provider selection).

  • Upstream health tracking Fixed, cannot change

    The behaviour is fixed by the vendor. Predictable, but you cannot tune it for your workload.

    It is automatic unhealthy-provider ejection, not a configurable health check or circuit breaker: OpenRouter tracks provider errors and removes a failing provider from rotation using a 30-second outage window (OpenRouter reliability and failover).

  • Cross-region failover Not documented

    The fetched pages describe edge execution on Cloudflare Workers but no configurable cross-region failover (OpenRouter latency and performance).

Fallback chain: Ordered list — Try A, then B, then C. Simple and predictable, but every failover is all-or-nothing.

Reliability here is largely vendor-operated rather than user-configured: you choose ordering and preferences, the platform does ejection and weighting. allow_fallbacks: false is the switch that makes routing deterministic at the cost of resilience (OpenRouter provider selection).

How fast the hop is

Edge worker

Runs in a V8 isolate at the network edge, so the routing hop is cheap and starts fast, but you cannot run it inside your own network.

Stated runtime: "Edge computing using Cloudflare Workers" (OpenRouter latency and performance).

You can run the request path yourself Not documented
Streaming Yes

No Docker image, Helm chart, binary or npm package for a self-hosted data plane appears on the fetched pages (OpenRouter latency and performance).

Streaming caveats: Supported. Documented caveat: on stream cancellation some upstreams still bill — Bedrock, Groq, Google and Mistral are named as continuing to charge for cancelled streams (OpenRouter latency and performance).

This vendor publishes no latency or throughput figure for the routing layer. That is the most common case here, and it is why the architecture class above carries the comparison instead of a number.

No figures published, so nothing to attribute (OpenRouter latency and performance).

What it will stop

3 of 4 can block

Two separate questions per control: can it stop a request at all, and what does it do before you change any settings? A control that inspects and forwards is a logging feature, however it is named.

  • Personal data in prompts Can block the request

    Out of the box: You pick the action when configuring

    Guardrails include a DLP scanner with 7 built-in sensitive-data types, using regex plus Presidio NLP for names/addresses; per-type action is Flag, Redact, or Block, and Block returns a 403 before the model is called, so it both redacts and blocks depending on configuration (OpenRouter Guardrails docs, OpenRouter guardrails announcement)

  • Prompt injection and jailbreaks Can block the request

    Out of the box: You pick the action when configuring

    Prompt-injection detection is regex/pattern-based (30+ patterns mapped to OWASP LLM risks), not a model classifier, and shares the Flag/Redact/Block actions (OpenRouter Guardrails docs)

  • Harmful content Not documented

    The Guardrails reference documents DLP and prompt-injection scanners; no toxicity/moderation category is described (OpenRouter Guardrails docs)

  • Your own policies Can block the request

    Out of the box: You pick the action when configuring

    Policies take the form of configurable scanner rules with per-type actions; regex patterns underpin the DLP and injection scanners (OpenRouter Guardrails docs)

Where checks run On the vendor's servers
If the guardrail itself fails Not documented

Almost no vendor in this catalogue documents what happens when the guardrail service itself times out. If the control matters to you, this is a question worth asking before you sign.

No fail-open/fail-closed statement on the guardrails pages (OpenRouter Guardrails docs)

Calls out to: Microsoft Presidio. Each is a separate vendor relationship and a separate hop on the request path.

Guardrails are enforced alongside Zero-Data-Retention routing: ZDR enforcement is applied on the same request path as the model/provider allowlists (OpenRouter Guardrails docs).

What you can see

Export is limited
What gets logged Metadata only

Token counts, latency and model names are stored, but not the text itself.

You can turn bodies off Yes

Body logging is opt-in, not opt-out: leaving I/O logging off keeps usage metrics while storing no prompt/completion text (Input/output logging)

Traces Not documented

n.a. — No OpenTelemetry or agent-trace support documented on the fetched pages (OpenRouter FAQ)

Prompt and completion text is not stored unless input/output logging is explicitly enabled (Input/output logging, Data collection)

Where telemetry can go

  • CSV export

Activity export as CSV and PDF from the activity/administration API; no log/metric/trace streaming destinations documented (Activity export cookbook)

Records user feedback No
Scores live traffic No

n.a. — No feedback or score endpoint documented (OpenRouter FAQ)

n.a. — No eval or online-scoring product documented (OpenRouter FAQ)

Retention: Opt-in prompt/completion logs are retained for at least 3 months (Data collection)

Whether it fits how you work

How much work stands between you and a first call, how different that is from running it in production, and whether it slots into the stack you already have. Recorded as the shape of the work rather than a number of minutes — how long it takes you depends on which accounts and quota you already hold, which no comparison can know.

to try: base url swap to run: base url swap fits 4 of 10 common stacks

Getting to a first call

No numbered procedure published
Shape of the work Change one base URL

Your existing OpenAI-compatible client keeps working. You change a base URL and a key, and nothing else in your code moves.

Read off: the vendor’s own quickstart — no numbered procedure published.

Why the count is not the work: The quickstart is prose plus a code sample with no numbered procedure, so there is no step count to report.

Before step one

  • Your own provider key Not needed

    You can make a first call with only this product’s key. No upstream provider account needed.

    . Only an OpenRouter key is used in the examples (OpenRouter Quickstart Guide); the FAQ states OpenRouter "provides a unified API to access all the major LLM models" with no BYO-key requirement (OpenRouter FAQ)

  • Payment method No card needed to start

    Not stated as required; a free allowance exists: "All new users receive a small free allowance to test out OpenRouter," and free models have "low rate limits (50 requests per day total)" (OpenRouter FAQ)

  • Gate before models answer No gate

    Every catalogue model is callable as soon as you have a key.

    n.a. (not documented). No approval, enablement, quota, or waitlist gate is mentioned; "OpenRouter gives you access to hundreds of AI models through a single API endpoint" (OpenRouter Quickstart Guide); the FAQ also states no gate (OpenRouter FAQ)

Everything you need first: An OpenRouter API key (examples use the <OPENROUTER_API_KEY> placeholder). No account, credit card, cloud account, cluster, or separate provider key is stated as a prerequisite on the quickstart (OpenRouter Quickstart Guide)

Running it in production

The same scale applied to the path the vendor recommends for production traffic. Kept separate from the quickstart because for several products here the two are barely related pieces of work.

Shape of the work Change one base URL

Your existing OpenAI-compatible client keeps working. You change a base URL and a key, and nothing else in your code moves.

What production needs: n.a. (not documented) — no database, Redis, cluster, load balancer, or control-plane requirement appears on the quickstart (OpenRouter Quickstart Guide)

Can you run it yourself

Install command published No self-hosting

This runs on the vendor’s infrastructure only.

How it fits your stack

4 of 10

Each row is a thing you might already run. “With a caveat” means it works but not the way the vendor’s marketing implies — read the reason, because that is usually where the surprise lives.

  • Fits The OpenAI SDK Drop-in: change the base URL and key, nothing else.
  • Fits The Vercel AI SDK @openrouter/ai-sdk-provider
  • No Cloudflare Workers Their own gateway runs on Workers. That is not the same as edge support for your code.
  • No Kubernetes No Kubernetes deployment published.
  • With a caveat Terraform or OpenTofu Community provider
  • With a caveat An existing API gateway Documented by Apache APISIX, not this vendor.
  • No Cloud IAM I already run Static upstream credentials only. Your calls to it still use its own key.
  • Fits LangChain or LlamaIndex LangChain, LlamaIndex
  • With a caveat MCP servers to govern Hosted MCP server — governs nothing on your side.
  • Fits Nothing — plain Node or Python Change one base URL.

Reading this the other way round — pick what you already run and see every product scored against it.

The integration surfaces behind those answers

  • Vercel AI SDK Official provider package

    Install the package, swap the model factory, done. Maintained by a party with a stake in it.

    Named: @openrouter/ai-sdk-provider

    OpenRouter documents the official provider package @openrouter/ai-sdk-provider for the Vercel AI SDK, including use in a Next.js application. (OpenRouter Vercel AI SDK provider)

  • Cloudflare Workers Their gateway runs on Workers, not yours

    The vendor runs its own gateway on Workers. That is a fact about their infrastructure and says nothing about calling them from your Worker — it usually means low latency to their edge, not edge compatibility for you.

    OpenRouter states that it uses edge computing with Cloudflare Workers to stay close to applications. This documents OpenRouter’s own infrastructure use, not a user-facing Cloudflare Workers integration. (OpenRouter latency and performance guide)

  • Kubernetes Not documented

    No Kubernetes story published.

    n.a. (not documented)

  • Terraform Community provider

    A provider exists that the vendor does not publish. Nobody owes you a fix when the API changes.

    Named: cloudopsworks/openrouter 0.3.0 and mcmarkj/openrouter 0.0.3 on the Registry — neither is published by OpenRouter

    Terraform Registry lists an OpenRouter provider at cloudopsworks/openrouter and another at mcmarkj/openrouter. The documented versions are 0.3.0 and 0.0.3, respectively, and both support Terraform 0.13+ per the registry pages. (Terraform Registry cloudopsworks/openrouter provider)

  • Existing API gateway The gateway vendor documents it

    The integration is documented by the gateway vendor rather than this one. A working recipe, without a support commitment from this product’s vendor.

    Documented by: Apache APISIX

    OpenRouter itself documents no gateway plugin, but Apache APISIX's ai-proxy / ai-proxy-multi plugins list openrouter as a supported provider, proxying to openrouter.ai via the OpenAI-compatible driver (third-party gateway documentation, not OpenRouter's). (Apache APISIX ai-proxy plugin docs)

  • Cloud identity Static provider credentials only

    You paste static provider credentials into this product so it can reach upstream models. Your own calls to it still use its own API key, and those pasted secrets are yours to rotate.

    Partially: OpenRouter's BYOK docs accept AWS credentials (accessKeyId, secretAccessKey, region) for an AWS IAM user/role and a Google Cloud service-account key JSON for Vertex; Azure is configured with an api_key. Calls to OpenRouter still authenticate with an OpenRouter API key, so this is upstream credential reuse rather than IAM-based access to the gateway. (OpenRouter BYOK authentication docs)

  • MCP Hosted MCP server

    The vendor runs an MCP server you connect a client to. Useful for reaching this product from an agent, but it does not govern your other MCP servers.

    OpenRouter documents remote MCP support through @openrouter/mcp, connecting to MCP servers over Streamable HTTP or SSE and exposing their tools as first-class callModel tools. Its hosted MCP server is https://mcp.openrouter.ai/mcp; the quickstart states that it requires no installation and uses OAuth login. (OpenRouter Agent SDK MCP tools)

Python frameworks
  • LangChain
  • LlamaIndex

LangChain integration is documented for Python and JavaScript applications, and LlamaIndex integration is documented for Python and TypeScript RAG applications. LlamaIndex also documents the llama-index-llms-openrouter package and llama_index.llms.openrouter.OpenRouter class. (OpenRouter frameworks and integrations overview)

First-party client libraries
  • TypeScript
  • Python
  • Go

Official client SDKs include the TypeScript package @openrouter/sdk, the Python package openrouter with the OpenRouter class, and the Go package go-sdk at github.com/OpenRouterTeam/go-sdk. The Python SDK supports synchronous and asynchronous clients. (OpenRouter client SDK overview)

Agent features: The @openrouter/agent Agent SDK provides multi-turn conversation loops, tool execution, stop conditions, and state management through callModel. It sends prompts, handles model tool calls, executes tools, feeds results back, and returns the final response; sessions/threads and A2A are not documented. (OpenRouter quickstart docs)

Optional client SDKs exist (npm install @openrouter/sdk, pip install openrouter) and an Agent SDK (npm install @openrouter/agent), but the plain REST/OpenAI-SDK path needs no new dependency. OpenRouter headers HTTP-Referer and X-OpenRouter-Title are explicitly "Optional." A remote MCP server at https://mcp.openrouter.ai/mcp is offered with "nothing to install" (OpenRouter Quickstart Guide)

OpenRouter provides access to hundreds of models through a unified API, with automatic fallbacks and provider/model routing; its SDK documentation describes access to 400+ models. OpenRouter also documents remote MCP hosting and uses Cloudflare Workers, edge caching, and provider routing in its own service infrastructure; self-hosting and single-cloud requirements are not documented. (OpenRouter quickstart docs)

Silence in the docs: 1 of the integration questions on this card have no published answer either way. That is recorded as undocumented, not as a no — but it does mean you would be verifying it yourself.

What it does well

  • Largest published catalog: 500+ models, 80+ providers
  • No token markup; provider list prices pass through
  • Public models endpoint with per-model pricing
  • ZDR routing, EU/US in-region routing, SOC 2 and GDPR posture
  • Per-key credit limits with daily/weekly/monthly resets

Where it falls short

  • 5.5% credit-purchase fee (min $0.80) makes small top-ups expensive - $5 buys $5 of credit for $5.80
  • BYOK documentation describes two different meters ($25k list-price cost vs 1M requests)
  • No native content guardrails or PII redaction
  • Managed only - no self-hosting or VPC option

Choose it when

Teams that want the broadest possible model and provider catalog behind one OpenAI-compatible key with unified billing.

Look elsewhere when

You need self-hosting, air-gapped deployment, or a gateway that charges nothing on credit purchases.

Managed marketplace: One account and one key gets you hundreds of models from dozens of providers. Fastest way to start, widest catalog, least control over the data path.

How hard is it to leave?

Derived from six published facts, not from an opinion. The weights are fixed and the same for every product — see the arithmetic.

64 /100 Some work to leave
Portability score breakdown for OpenRouter
What helps you leave Points Source
Works with standard OpenAI code Switching away is a base-URL change rather than a rewrite of every call site. 22 /22 vendor page
No vendor-specific SDK required A proprietary client library spreads through your codebase and has to be torn out again. 10 /10 vendor page
Can use your own provider accounts Your keys and billing relationship stay yours, so removing the gateway does not cut off model access. 20 /20 vendor page
Can be self-hosted You can run it yourself instead of accepting a pricing or policy change. 0 /20 vendor page
Configuration lives in version control Routing and budget rules are a file you keep, not dashboard state you would have to rebuild. 0 /16 vendor page
Your request history can be exported You leave with your own logs instead of abandoning them. 12 /12 vendor page

Read the fine print: Aggregated usage export (CSV/PDF), not per-request logs.

All six inputs are published, so this is scored against the full 100. This measures technical switching cost only. It does not price the engineering time to re-test prompts against a different routing stack.

OpenRouter models & pricing

Browse every imported listing from this provider, with published token rates and a link to compare other providers for the same model. This is provider-reported coverage; an absent listing does not mean unsupported.

Loading model listings…

Official model coverage source ↗ · Model source coverage and limitations

Full specification

Every field we track. Blank fields say "Not published" rather than "No" — we do not infer an absence from silence. Switch to Technical in the header for the precise field names and the low-level details.

Overview

Interpret these fields: Self-hosted vs managed LLM gateways · Who still owns your LLM gateway?

What kind of product Category
Managed marketplace
Marketplaces resell many providers behind one key. Gateways add governance on top. Open-source projects you run yourself. Cloud platforms are hyperscaler surfaces. Inference providers host models on their own hardware.
Who runs it Deployment model
Managed only
Managed means the vendor operates it. Self-host means you run it on your own infrastructure. Both means you can choose.
Licence Licence
Proprietary
Proprietary products cannot be inspected or forked. Open licences such as MIT and Apache-2.0 let you audit, modify, and run the code without permission.
Company Company
OpenRouter, Inc.
The organisation that maintains the product.
Who you would be signing with Vendor status
Being acquired — deal not yet closed
Whether the product is still an independent company, has been acquired, is a large cloud vendor’s product line, is run by a software foundation, or has been put into maintenance mode. Maintenance mode means bug fixes and security patches only — no new features.
Last shipped an update Latest release
2026-08-19
The date of the most recent release or version tag. A product that has not shipped in a year is a different risk from one that shipped last week, regardless of what its marketing site says.
GitHub stars GitHub stars
Not published
A rough proxy for community size on open-source projects. Not a quality measure.

Cost

Interpret these fields: How LLM gateway pricing works · LLM gateway spending limits: stop a runaway agent bill? · Choosing a gateway for realtime voice agents

Markup on model prices Token markup
None
How much the product adds on top of what the underlying model provider charges. Zero means you pay the same per-token price you would pay the model provider directly.
Fee to add funds Credit purchase fee
5.5%
A percentage charged when you top up your balance, separate from token prices. It is easy to miss because it does not appear on the per-token price list.
Monthly cost per person Seat fee
Not published
A recurring per-user platform charge that applies regardless of how much you use the models.
Can use your own provider accounts BYOK supported
Yes
Bring Your Own Key: you keep direct contracts with OpenAI, Anthropic and others, and the gateway only routes traffic. This preserves negotiated rates and committed-spend discounts.
Cost of using your own accounts BYOK terms
Free up to $25,000/mo of list-price inference (pay-as-you-go) or $200,000/mo (Enterprise), then 5% of the equivalent OpenRouter cost; measured by list-price cost, not request count.
What the product charges to route traffic through your own provider keys.
Free tier Free tier
Free tier with 25+ free models and 50 free-model requests/day; 1,000/day after purchasing at least $10 in credits.
What you can do without paying, useful for evaluation.
Enterprise plan from Enterprise plan from
Not published
Annual entry price for the enterprise tier, where one is published or credibly reported.
Cost to run it yourself Self-host cost
Not published
What self-hosting actually costs once you account for infrastructure and any paid tier.
How the vendor makes money Pricing model
Percentage on tokens or top-ups
The shape of the vendor’s bill: does the routing layer charge a percentage on top of tokens, a flat monthly fee, both, neither (because inference is the product), or nothing at all (open source with no paid tier).
How pricing works, briefly Pricing model detail
Credit top-up fee (5.5% Stripe / 5% crypto) with a $0.80 minimum; 0% token markup; BYOK charged 5% above a monthly list-price allowance ($25k Pay-as-you-go / $200k Enterprise).
A one-paragraph description that covers the caveats a pricing category cannot: introductory rates, per-feature meters, tier gating, and pricing that resets on a specific date.
Minimum commitment Minimum commitment
None stated. Unused credits may expire one year after purchase.
Whether the vendor requires a minimum contract term, a minimum spend, or a provisioned-capacity purchase to get its published rate.
Charges that fire after you go over an allowance Overage terms
No log/trace-retention or request-volume overage. Only after-the-fact charge is the BYOK 5% once the monthly list-price allowance is exceeded.
The line items that scale with usage after an included allowance is exhausted — log storage, extra requests, per-feature meters, data export — which is where cost estimates usually go wrong.
Prompt cache offered Cache mechanism
Passes provider caching through
Whether the gateway offers its own response cache, what kind of match it does (exact request, prefix, semantic), or simply passes provider caching through unchanged.
Discount on cached input Cache-read discount
Not published
How much cheaper cached tokens are than fresh input, when the vendor publishes a single figure. Bundled-inference clouds usually price this per model instead of as one number.
Premium on cache writes Cache-write premium
Not published
How much more the first write of a cached prefix costs versus a plain input token. A high write premium and a low hit rate can leave you paying more than you save, so this matters as much as the read discount.
Who captures the cache saving Cache economics
Provider caching flows through unchanged. Read discounts vary by provider: 75%/50% for OpenAI, 90% for Anthropic/Alibaba/DeepSeek, 50% for Groq, ~80% for Z.AI, 75% for Gemini implicit. Cache-write premium: 0% for pre-GPT-5.6 OpenAI/Grok/Moonshot/Groq/Gemini; +25% for GPT-5.6+, Alibaba explicit and Anthropic 5-min; +100% for Anthropic 1-hour. OpenRouter itself adds 0% on cached traffic.
Whether the customer keeps the full saving from caching or the vendor captures part of it — and any conditions attached (write premium, storage fees, best-effort hits).
What you can split spend by Cost attribution
Per model, provider and API key on the Activity page; session_id grouping across turns. Per-user/team/customer not stated.
The dimensions the vendor documents for splitting spend — per key, per user, per team, per tag, per customer. Matters if you need to chargeback internally or bill an end customer.
How you get cost data out Cost export
API only (/api/v1/key, credits API, /api/v1/generation). CSV, webhook, S3 and warehouse export not stated.
The mechanisms the vendor publishes for exporting cost and usage data: CSV, an API, webhooks, S3, a data warehouse, or nothing at all. Any per-unit price is included.
Who pays the model bill BYOK mode
Your keys or their credits
Whether you bring your own provider accounts (BYOK), buy inference from this vendor, or can do either. This is the single biggest commercial difference between these products: it decides who holds the contract with the model provider and who carries the spend.

Spend governance in detail

Seven signals matter when a bill starts to hurt: who can spend, how much, on what, and who gets paged when it goes wrong. Everything below is drawn from the vendor’s own pricing and docs pages — how we read these.

  • Virtual or scoped keys Yes

    Keys that carry their own budget and rate-limit policy, so an intern experiment cannot spend against a production budget.

    API keys plus Management API for programmatic key management; 'virtual key' terminology not used.

  • Budget caps per key Yes

    A dollar or token ceiling attached to an individual key. Where enforcement is soft, one over-limit request still completes before the block kicks in.

    Per-key credit limits enforced pre-request via limit/limit_remaining.

  • Budget caps per team or workspace Not published

    A ceiling applied at a higher scope than one key — a team, a workspace, a customer, or an entire environment.

    Not stated.

  • Rate limiting as a cost control Yes

    Configurable request-per-time-window caps. Platform-set rate limits do not count as spend controls; user-configurable ones do.

    Platform-governed, not user-configurable. 20 req/min and 50 or 1,000 req/day on free models; global capacity governance across accounts.

  • Model allowlists Not published

    A policy that constrains which models a key or team can call, keeping expensive frontier models out of the wrong hands.

    Not stated.

  • Spend alerts Not published

    Alerts fired as spend approaches a threshold. Alerts that only fire after the meter has rolled over are marked as such.

    Not stated as spend alerts; auto top-up threshold is the closest control.

  • Webhook notifications Not published

    Programmatic notifications on spend events, so budget breaches can page an on-call or open a ticket.

    Not stated.

Enforcement: Enforced before each request

Catalog

Interpret these fields: LLM gateway model counts: what “500+” means · Model aliases and deprecations: build an endpoint inventory · Choosing a provider for Qwen, DeepSeek, GLM or Kimi

Models available Models available
458
How many models you can call, shown as a range because several vendors publish different totals on different pages. Vendor-reported either way, so counts are not directly comparable — some count every provider variant of the same model separately.
Model providers reachable Upstream providers
~83
How many distinct model providers or labs you can reach, shown as a range where the vendor’s own pages disagree. More providers usually means better redundancy when one has an outage.
Works with standard OpenAI code OpenAI-compatible API
Yes
If yes, you can usually switch to it by changing one base URL, and switch away just as easily. This is the main defence against lock-in.
OpenAI chat endpoint POST /v1/chat/completions
Yes
The endpoint almost every application ports first. "Not documented" means the vendor never states it, which is different from a documented no.
Anthropic messages endpoint POST /v1/messages
Yes
Whether Anthropic-shaped calls work without rewriting them. Several products support this only as SDK compatibility or provider passthrough rather than a native endpoint — the detail page says which.
OpenAI Responses endpoint POST /v1/responses
Yes
The newer stateful OpenAI surface. Support is much thinner across this market than chat completions.
Embeddings endpoint POST /v1/embeddings
Yes
Whether you can generate vectors through the same gateway, or need a second integration for retrieval workloads.
Image generation endpoint POST /v1/images/generations
Yes
Whether image models are reachable through the same surface as text.
Audio endpoints POST /v1/audio/*
Yes
Speech-to-text and text-to-speech. Frequently the first gap in an otherwise complete gateway.
Batch jobs endpoint POST /v1/batches
Yes
Asynchronous bulk processing, usually at a discount. Commonly undocumented, and commonly the reason a migration stalls late.
Needs the vendor’s own code library Requires a vendor-specific SDK
No
A proprietary client library spreads through your codebase and has to be torn out again if you leave. “No” is the better answer here, and it means the standard OpenAI client works.
You can export your request history Logs / usage data export
Yes
Whether you can get your own request logs, traces, or usage records back out — through an API, a bulk export, or a download. Decides whether you leave with your history or abandon it.
Settings can live in version control Declarative config-as-code
No
Whether routing, fallback, and budget rules can be declared in a file you keep in Git, rather than existing only as settings clicked into a hosted dashboard.
Embeddings Embeddings
Not published
Text-to-vector models, needed for search and retrieval features.
Image generation Image generation
Yes
Whether image models are reachable through the same interface.
Speech and audio Speech and audio
Not published
Text-to-speech or transcription models through the same interface.
Video generation Video generation
Yes
Whether video models are reachable through the same interface.
Batch processing Batch processing
Not published
Submitting large jobs for cheaper, slower processing. Often 50% off for work that is not time-sensitive.

Routing & reliability

Interpret these fields: How LLM gateway failover actually works · Does your LLM gateway promise any uptime? · Is routing destroying your prompt cache? · Changing models without breaking production · Choosing a gateway for realtime voice agents

Uptime it promises in writing Contractual SLA uptime
Not published
The uptime percentage in a published, contractual service level agreement. A public status page is not an SLA — it reports what happened, it does not promise anything or pay you back when it breaks.
Automatic failover Automatic failover
Yes
When a model provider goes down or rate-limits you, traffic moves to a backup automatically instead of returning errors to your users.
Load balancing Load balancing
Yes
Spreads requests across several providers or keys to raise your effective rate limit.
Rule-based routing Conditional routing
Yes
Send different requests to different models based on rules — for example a cheap model for free users and a strong model for paying ones.
Response caching Response caching
Yes
Reuses the answer when the exact same request comes in again, which cuts both cost and latency.
Similar-question caching Semantic cache
No
Reuses an answer when a new question means roughly the same thing as an earlier one. Saves far more than exact-match caching but can return subtly wrong answers if tuned loosely.
Where you set the timeout Request timeout surface
Not documented

No request-timeout header or key appears on the fetched routing/performance docs. The closest published control is a routing preference, not a timeout: `preferred_max_latency` (with `preferred_min_throughput`), evaluated against provider p50/p90/p99 over a rolling 5-minute window ([OpenRouter latency and performance](https://openrouter.ai/docs/guides/best-practices/latency-and-performance)).

Where a request timeout can be set: per request, in a config file, in the vendor dashboard, or nowhere. Nine of the twenty products documented here do not describe a request timeout at all, so the worst case of a hung upstream call is unknowable from the docs.
Where you set retries Retry policy surface
Not documented

No retry-count key or backoff strategy is published; the documented failure behavior is provider fallback, not a retry counter. Default retry count: `n.a.` Backoff: `n.a.` ([OpenRouter model fallbacks](https://openrouter.ai/docs/guides/routing/model-fallbacks)).

Where retry count and backoff are configured. Worth knowing alongside billing: a retried streaming call can be charged more than once.
Where you set fallbacks Fallback surface
Per request

ORDERED. `provider.order` sets an explicit ordered provider list and `allow_fallbacks` (default `true`) controls whether other providers may be used ([OpenRouter provider selection](https://openrouter.ai/docs/guides/routing/provider-selection)). Model-level fallback uses the `models` array, tried in order; via the Anthropic-compatible surface the key is `fallbacks`, limited to 3 entries ([OpenRouter model fallbacks](https://openrouter.ai/docs/guides/routing/model-fallbacks)).

Where the fallback chain is defined. Almost every product claims fallback; the useful question is whether you can change it from code or only by hand in a dashboard.
Shape of the fallback chain Fallback shape
Ordered list
An ordered list tries targets in sequence; a weighted split sends a percentage of traffic to each, which is what you need to trial a new model on 5% of requests. Weighted splits are much rarer than the marketing implies.
Upstream health tracking Health checks / circuit breaking
Fixed, cannot change

It is automatic unhealthy-provider ejection, not a configurable health check or circuit breaker: OpenRouter tracks provider errors and removes a failing provider from rotation using a 30-second outage window ([OpenRouter reliability and failover](https://openrouter.ai/blog/insights/reliability-failover/)).

Whether the product notices a failing upstream and stops sending traffic to it, and whether you can tune the thresholds. This is what turns a provider outage into a blip rather than a sustained error rate, and only four of the twenty expose it.
Cross-region failover you control Multi-region failover surface
Not documented

The fetched pages describe edge execution on Cloudflare Workers but no configurable cross-region failover ([OpenRouter latency and performance](https://openrouter.ai/docs/guides/best-practices/latency-and-performance)).

Whether you can define what happens when a region degrades. A vendor running many regions is not the same as a vendor letting you configure failover between them; only three document a user-controlled mechanism.
Where you set load balancing Load balancing surface
Per request

Weights are NOT user-settable: OpenRouter load-balances with price-inverse-square weighting internally; the user-facing controls are `order`, `only`, `sort` and the latency/throughput preferences ([OpenRouter provider selection](https://openrouter.ai/docs/guides/routing/provider-selection)).

Where traffic distribution across upstreams or keys is configured.

Operations

Interpret these fields: LLM gateway observability: traces, logs and export · Changing models without breaking production · Running coding agents through an LLM gateway · Model aliases and deprecations: build an endpoint inventory

Usage dashboards and logs Observability
Yes
Built-in visibility into what was sent, what came back, what it cost, and how long it took.
Spending limits Budget controls
Yes
Hard caps that stop spend before it becomes a surprise invoice. The single most valuable control for a small team.
Rate limits Rate limits
Yes
Caps on request volume per key or per user, useful for protecting against abuse and runaway loops.
Separate keys per team or app Virtual keys
Yes
Issue scoped keys with their own budgets and permissions so you can attribute cost and revoke access without rotating everything.
Prompt versioning Prompt management
Not published
Store and version prompts outside your code so they can be changed without a deploy.
Quality testing Evals
Not published
Built-in tooling to score model output against test cases, so you can tell whether a model swap made things better or worse.
MCP support MCP support
Not published
Native support for the Model Context Protocol, the emerging standard for connecting models to external tools.
What gets logged Logged content
Metadata only

Prompt and completion text is not stored unless input/output logging is explicitly enabled ([Input/output logging](https://openrouter.ai/docs/guides/features/input-output-logging), [Data collection](https://openrouter.ai/docs/guides/privacy/data-collection))

Whether full prompts and responses are stored, only metadata, or nothing. Full-body logging is the most useful debugging feature here and the one most likely to need a conversation with your compliance team.
You can turn logging off Body-logging opt-out
Yes

Body logging is opt-in, not opt-out: leaving I/O logging off keeps usage metrics while storing no prompt/completion text ([Input/output logging](https://openrouter.ai/docs/guides/features/input-output-logging))

Whether prompt and response bodies can be suppressed while still keeping usage metrics. Nineteen of the twenty document a way to do this; the mechanisms range from a per-request header to an organisation-wide setting.
Traces you can take elsewhere Distributed tracing
Not documented

`n.a.` — No OpenTelemetry or agent-trace support documented on the fetched pages ([OpenRouter FAQ](https://openrouter.ai/docs/faq))

Whether the product emits OpenTelemetry, a proprietary format, or nothing. OpenTelemetry means the traces land in the tooling you already run instead of only in the vendor’s dashboard.
Where telemetry can go Export destinations
CSV export

Activity export as CSV and PDF from the activity/administration API; no log/metric/trace streaming destinations documented ([Activity export cookbook](https://openrouter.ai/docs/cookbook/administration/activity-export))

Documented sinks for logs and metrics. This is a good proxy for how replaceable the vendor’s own dashboard is: around twenty destinations means you never have to depend on it, while a CSV download means you do.
Can record user feedback Feedback capture API
No

`n.a.` — No feedback or score endpoint documented ([OpenRouter FAQ](https://openrouter.ai/docs/faq))

Whether there is an API to attach a rating or score to a logged request, which is what lets production traffic feed quality work later.
Scores live traffic Online eval hooks
No

`n.a.` — No eval or online-scoring product documented ([OpenRouter FAQ](https://openrouter.ai/docs/faq))

Whether automated scorers can run against real production requests, rather than only against a test set you assemble yourself.

Performance

Delay it adds Proxy overhead
Not published
Extra time the product itself adds to each request, on top of however long the model takes. Usually irrelevant next to multi-second model latency, but it matters for high-volume or streaming-sensitive workloads.
Requests per second ceiling Throughput
Not published
Published sustained request rate before the product becomes the bottleneck. Only relevant at genuinely high volume.
What the request path runs on Architecture class
Edge worker

Stated runtime: "Edge computing using Cloudflare Workers" ([OpenRouter latency and performance](https://openrouter.ai/docs/guides/best-practices/latency-and-performance)).

The comparable way to talk about latency here. An edge worker, a compiled Go or Rust binary, and a Python proxy have different overhead floors no matter which figures each vendor publishes. Products that never disclose their runtime are recorded as undisclosed rather than assumed.
You can run the request path yourself Self-hostable data plane
Not documented

No Docker image, Helm chart, binary or npm package for a self-hosted data plane appears on the fetched pages ([OpenRouter latency and performance](https://openrouter.ai/docs/guides/best-practices/latency-and-performance)).

Whether the component that actually carries your prompts can run on your own infrastructure. Distinct from a vendor offering a self-hosted control plane while still proxying traffic through their network.
Streaming responses Streaming support
Yes

Supported. Documented caveat: on stream cancellation some upstreams still bill — Bedrock, Groq, Google and Mistral are named as continuing to charge for cancelled streams ([OpenRouter latency and performance](https://openrouter.ai/docs/guides/best-practices/latency-and-performance)).

Whether token-by-token streaming is documented. The caveats matter more than the yes: some products cannot cancel a stream without still being billed, and several timeout and fallback mechanisms stop applying once the first token has been sent.

Security & compliance

Interpret these fields: LLM gateway compliance: SOC 2, HIPAA and evidence · How LLM gateway guardrails fail · Which LLM gateways store your prompts? · Do you need an MCP gateway as well?

Does your prompt reach their servers Prompt transits vendor
Yes

Hosted router only; there is no self-hosted option. Your input is transmitted to whichever model provider you select.

Whether the text you send passes through this company’s own infrastructure. If it does, every other promise on this page is a policy commitment rather than a physical impossibility. Self-hosted products can answer no outright.
What they keep if you change nothing Logging default
Metadata only, not content

Both logging toggles are off by default. Token counts, latency and similar metadata are stored; prompt and completion content is not.

Defaults matter more than options. A product that stores full prompts and replies unless you find the right header will have stored them by the time you read the docs.
How long they keep it Default content retention (days)
Nothing kept by default

Prompt retention is always opt-in. Metadata is retained with no published window.

Default retention for request content, in days. Zero means nothing is kept. Read the note: several products keep nothing as a rule but make timed exceptions for abuse review or specific models.
Could they train on your prompts Training on customer data
No

OpenRouter does not train on your inputs or outputs, and offers a 1% discount if you opt in to letting it. Downstream model providers are a separate question: some of them may train on what you send.

Whether the vendor may use your prompts and outputs to train models. “Not published” means we could not find any position, which is not the same as a no — ask for it in writing.
Where it runs, and what you can pin Region and residency control
US servers by default. Enterprise adds EU region locking and in-region routing. No self-hosted or customer-VPC option.
Which regions are offered and whether you can force processing to stay in one. A global endpoint that silently picks a region is a different compliance story from an endpoint you pin yourself.
Where safety filters run Guardrail execution location
In the vendor’s cloud

PII detection and redaction run inside OpenRouter's gateway, so the data has already reached them before it is redacted.

A filter that strips personal data only helps if it runs before the data leaves your boundary. If guardrails execute in the vendor’s cloud, the vendor has already received whatever you wanted redacted.
Who else touches the data Subprocessor list
https://openrouter.ai/authorized-sub-processors
The published list of third parties the vendor passes your data to. No list means you cannot know the full chain, which most data-protection agreements require you to.
SOC 2 audited SOC 2 audited
Yes
An independent audit of security controls. Enterprise buyers and their procurement teams routinely require it.
Will sign a HIPAA agreement HIPAA BAA
Not published
Required before you may send protected health information through the service. Without a signed BAA, healthcare data is off limits.
GDPR commitments GDPR commitments
Yes
Published data processing terms for handling personal data of people in the EU and UK.
Can keep data in the EU EU data residency
Yes
Requests can be processed inside the EU rather than routed to US infrastructure. Often the deciding constraint for European customers.
Does not retain your data Zero data retention
Yes
Prompts and responses are not stored after the request completes. Sometimes a paid add-on rather than the default.
Strips personal data PII redaction
No
Detects and removes identifiers such as names, emails, and card numbers before the request reaches the model provider.
Content guardrails Content guardrails
No
Policy checks on inputs and outputs — blocking unsafe content, enforcing formats, or catching prompt-injection attempts.
Runs fully disconnected Air-gapped deployment
Not published
Can be deployed in a network with no internet access, which some regulated and defence environments require.
Blocks personal data in prompts PII / DLP enforcement
Can block the request

Guardrails include a DLP scanner with 7 built-in sensitive-data types, using regex plus Presidio NLP for names/addresses; per-type action is Flag, Redact, or Block, and Block returns a 403 before the model is called, so it both redacts and blocks depending on configuration ([OpenRouter Guardrails docs](https://openrouter.ai/docs/guides/features/guardrails), [OpenRouter guardrails announcement](https://openrouter.ai/blog/announcements/guardrails/))

Whether personal data detection sits on the request path and can stop the call, merely inspects and forwards it, or is not documented. A control that only reports is a logging feature, not a policy control.
Blocks prompt injection Injection / jailbreak enforcement
Can block the request

Prompt-injection detection is regex/pattern-based (30+ patterns mapped to OWASP LLM risks), not a model classifier, and shares the Flag/Redact/Block actions ([OpenRouter Guardrails docs](https://openrouter.ai/docs/guides/features/guardrails))

Whether injection and jailbreak detection can stop a request. Most products offering this call a partner classifier rather than shipping their own.
Blocks harmful content Toxicity / moderation enforcement
Not documented

The Guardrails reference documents DLP and prompt-injection scanners; no toxicity/moderation category is described ([OpenRouter Guardrails docs](https://openrouter.ai/docs/guides/features/guardrails))

Whether hate, violence, sexual and self-harm categories are checked inline and can stop a request, in either direction.
Your own policy rules Custom policy hooks
Can block the request

Policies take the form of configurable scanner rules with per-type actions; regex patterns underpin the DLP and injection scanners ([OpenRouter Guardrails docs](https://openrouter.ai/docs/guides/features/guardrails))

Whether you can add your own rule — a regex, a webhook, or your own classifier — rather than choosing from the vendor library.
Where guardrails run Guardrail execution location
On the vendor's servers
Whether guardrail evaluation happens inside your infrastructure or on the vendor’s servers. This decides whether the prompt you are trying to protect leaves your network in order to be checked.
If the guardrail itself fails Guardrail failure mode
Not documented

No fail-open/fail-closed statement on the guardrails pages ([OpenRouter Guardrails docs](https://openrouter.ai/docs/guides/features/guardrails))

What happens when the guardrail service times out or errors: does the request proceed unchecked, or is it blocked? This is the worst-documented field in the entire catalogue — only two vendors state it plainly, which means most teams are running a control whose failure behaviour they cannot know.
Third-party guardrail vendors Guardrail integrations
Microsoft Presidio
Named external guardrail services the product can call. A long list means the product is a router for policy engines rather than a policy engine itself — which also means another vendor bill and another hop.

Compliance evidence

Graded by how strong the evidence is, not whether the word appears on the vendor’s website. An audited report and a marketing claim are different things, and only one of them will satisfy your own auditor.

  • SOC 2 Claimed, no evidence published Type II, asserted on the enterprise page
  • ISO 27001 Not published
  • GDPR DPA Claimed, no evidence published described as GDPR compatible
  • HIPAA BAA Not published
  • FedRAMP Not published
  • ITAR Not published

Vendor source

Fit & integration

Interpret these fields: How much does an LLM gateway lock you in? · Changing models without breaking production · Running coding agents through an LLM gateway · Do you need an MCP gateway as well? · Choosing a gateway for realtime voice agents · Choosing a provider for Qwen, DeepSeek, GLM or Kimi

Work to try it Evaluation work shape
Change one base URL
The shape of the work on the vendor’s own quickstart, from swapping one base URL through to deploying infrastructure. An ordinal class rather than a duration, because elapsed time depends on accounts and quota we cannot see.
Work to run it Production work shape
Change one base URL
The same scale applied to the vendor’s recommended production path. For several products this is much heavier than the quickstart, which is exactly why both are recorded.
Steps on the quickstart Numbered quickstart steps
0

The quickstart is prose plus a code sample with no numbered procedure, so there is no step count to report.

A literal count of numbered steps on the vendor’s quickstart, recorded as evidence beside the work shape. Zero means the page publishes no numbered procedure at all. Large counts usually mean interleaved language tracks rather than more work.
Can you self-host it today Self-host install documentation
No self-hosting
Whether an install command is actually published. Several products advertise self-hosting while publishing no command to start from, which a plain yes/no would hide.
Works with the OpenAI SDK OpenAI SDK drop-in
Yes

Yes. OpenRouter documents OpenAI-compatible usage with the exact base URL `https://openrouter.ai/api/v1`; its Responses API endpoint is `https://openrouter.ai/api/v1/responses` and requires an OpenRouter API key. ([OpenRouter quickstart docs](https://openrouter.ai/docs/quickstart))

Whether an existing OpenAI-compatible client can be pointed at it by changing the base URL and key.
Vercel AI SDK support AI SDK provider package
Official provider package

OpenRouter documents the official provider package `@openrouter/ai-sdk-provider` for the Vercel AI SDK, including use in a Next.js application. ([OpenRouter Vercel AI SDK provider](https://github.com/OpenRouterTeam/ai-sdk-provider))

Whether a first-party AI SDK provider package exists, or only a community package, a documented workaround, or the generic OpenAI provider pointed at a custom base URL.
Python framework integrations Documented Python frameworks
LangChain, LlamaIndex

LangChain integration is documented for Python and JavaScript applications, and LlamaIndex integration is documented for Python and TypeScript RAG applications. LlamaIndex also documents the `llama-index-llms-openrouter` package and `llama_index.llms.openrouter.OpenRouter` class. ([OpenRouter frameworks and integrations overview](https://openrouter.ai/docs/guides/community/frameworks-and-integrations-overview))

LangChain, LangGraph, LlamaIndex and similar orchestration frameworks with a documented integration.
Callable from Cloudflare Workers Cloudflare Workers support
Their gateway runs on Workers, not yours

OpenRouter states that it uses edge computing with Cloudflare Workers to stay close to applications. This documents OpenRouter’s own infrastructure use, not a user-facing Cloudflare Workers integration. ([OpenRouter latency and performance guide](https://openrouter.ai/docs/guides/best-practices/latency-and-performance))

Whether the docs show calling this product from your own Worker. Deliberately separated from the several products whose own gateway runs on Workers, which is a fact about their infrastructure and not about your edge compatibility.
Kubernetes install Helm chart availability
Not documented

n.a. (not documented)

Whether a named, published Helm chart exists, versus Helm being referenced with no chart named, versus generic cluster documentation that has nothing to do with this product.
Terraform support Terraform provider or modules
Community provider

Terraform Registry lists an OpenRouter provider at `cloudopsworks/openrouter` and another at `mcmarkj/openrouter`. The documented versions are `0.3.0` and `0.0.3`, respectively, and both support Terraform `0.13+` per the registry pages. ([Terraform Registry cloudopsworks/openrouter provider](https://registry.terraform.io/providers/cloudopsworks/openrouter/latest))

Whether you can declare this in code: an official provider, official modules, resources inside a hyperscaler’s provider, a community provider, or only Terraform code shipped in a repo.
Reuses your cloud identity Cloud IAM reuse
Static provider credentials only

Partially: OpenRouter's BYOK docs accept AWS credentials (`accessKeyId`, `secretAccessKey`, `region`) for an AWS IAM user/role and a Google Cloud service-account key JSON for Vertex; Azure is configured with an `api_key`. Calls to OpenRouter still authenticate with an OpenRouter API key, so this is upstream credential reuse rather than IAM-based access to the gateway. ([OpenRouter BYOK authentication docs](https://openrouter.ai/docs/guides/overview/auth/byok))

Whether you can authenticate with IAM roles, workload identity or managed identities instead of another long-lived API key. Distinguished from products that only accept static upstream provider credentials.
Fits behind your API gateway API gateway integration
The gateway vendor documents it

OpenRouter itself documents no gateway plugin, but Apache APISIX's `ai-proxy` / `ai-proxy-multi` plugins list `openrouter` as a supported provider, proxying to `openrouter.ai` via the OpenAI-compatible driver (third-party gateway documentation, not OpenRouter's). ([Apache APISIX ai-proxy plugin docs](https://apisix.apache.org/docs/apisix/plugins/ai-proxy/))

Whether AI traffic can go through a gateway you already run, and who documented that — the product’s vendor or the gateway’s.
MCP support MCP surface shape
Hosted MCP server

OpenRouter documents remote MCP support through `@openrouter/mcp`, connecting to MCP servers over Streamable HTTP or SSE and exposing their tools as first-class `callModel` tools. Its hosted MCP server is `https://mcp.openrouter.ai/mcp`; the quickstart states that it requires no installation and uses OAuth login. ([OpenRouter Agent SDK MCP tools](https://openrouter.ai/docs/agent-sdk/call-model/mcp-tools))

Which kind of MCP support this is: a gateway that governs many MCP servers, a hosted MCP server you connect to, MCP tools accepted inside the completion API, or client tooling. These are different products behind one acronym.
Needs your own provider key Upstream provider key required
Not needed

No. Only an OpenRouter key is used in the examples ([OpenRouter Quickstart Guide](https://openrouter.ai/docs/quickstart)); the FAQ states OpenRouter "provides a unified API to access all the major LLM models" with no BYO-key requirement ([OpenRouter FAQ](https://openrouter.ai/docs/faq))

Whether an upstream provider account and key must exist before your first call works. A prerequisite rather than a step, and it can differ between the hosted and self-hosted forms of the same product.
Gate before models work Model access gate
No gate

n.a. (not documented). No approval, enablement, quota, or waitlist gate is mentioned; "OpenRouter gives you access to hundreds of AI models through a single API endpoint" ([OpenRouter Quickstart Guide](https://openrouter.ai/docs/quickstart)); the FAQ also states no gate ([OpenRouter FAQ](https://openrouter.ai/docs/faq))

Whether an enablement click, a quota grant, a paid tier or an approval form stands between a valid key and a working model call.
Official client languages First-party client SDK languages
TypeScript, Python, Go

Official client SDKs include the TypeScript package `@openrouter/sdk`, the Python package `openrouter` with the `OpenRouter` class, and the Go package `go-sdk` at `github.com/OpenRouterTeam/go-sdk`. The Python SDK supports synchronous and asynchronous clients. ([OpenRouter client SDK overview](https://openrouter.ai/docs/client-sdks/overview))

Languages with a first-party client library. An empty list can still mean the product is usable from any language via an OpenAI-compatible SDK.

Additional charges

These are the fees that do not appear on a per-token price list, and they are where estimates usually go wrong.

  • Crypto (Coinbase) credit purchase fee 5%
  • Card credit purchase fee minimum $0.80 per purchase
Back to top ↑

Common questions

Answered from the fields above, so these move when the catalog moves. Every figure quoted here appears in the specification with its source.

Does OpenRouter charge a markup on model prices?

OpenRouter adds no percentage markup to model prices. Buying credit costs 5.5%, with a $0.80 minimum per purchase. Other charges on the page: crypto (coinbase) credit purchase fee (5%) and card credit purchase fee minimum ($0.80 per purchase). The cost estimator itemises this against your own volume.

Can OpenRouter be self-hosted?

No. OpenRouter is available only as a service the vendor operates; there is no self-hosted build. The licence is Proprietary. Prompts therefore leave your network and reach the vendor, which makes its retention and residency terms the control that matters here rather than deployment.

Is OpenRouter SOC 2 audited, and will it sign a HIPAA BAA?

A SOC 2 report is available for OpenRouter but it does not publish a HIPAA business associate agreement. It offers a GDPR data processing agreement and EU data residency. Each of these is linked to the vendor's own page in the compliance section below.

Does OpenRouter retain your prompts?

OpenRouter publishes a zero-data-retention position. Only metadata is logged — not prompt or response bodies. Logging can be turned off. Stated retention is zero days. It states that it does not train on customer data. Retention, logging and training on customer data are three separate questions, and a vendor can answer one of them without answering the others.

Can you use your own provider keys with OpenRouter?

Yes. OpenRouter can route through your own accounts with the underlying model providers, so inference is billed to you directly. Free up to $25,000/mo of list-price inference (pay-as-you-go) or $200,000/mo (Enterprise), then 5% of the equivalent OpenRouter cost; measured by list-price cost, not request count.

How many models does OpenRouter support?

OpenRouter publishes no aggregate total; counting its catalog gives 458 models, drawn from ~83 upstream providers. Count of entries returned by the models API on 2026-09-25. Includes every entry exposed by that endpoint; not a count of unique base models. The figure on this page is dated and carries its source.

Back to top ↑

What has changed here

  1. Models available Models available 445 458 source ↗
  2. Models available Models available 429 445 source ↗
  3. Models available Models available 500 429 source ↗
  4. catalog entry catalog entry Not published Added to the catalog source ↗
See this in the full changelog Back to top ↑

Read the head-to-head

These pairs have a written verdict, not just a table.

OpenRouter vs Velokey Read the verdict → OpenRouter vs Vercel AI Gateway Read the verdict → OpenRouter vs Requesty Read the verdict → OpenRouter vs LiteLLM Read the verdict → OpenRouter vs Portkey Read the verdict → OpenRouter vs Amazon Bedrock Read the verdict → OpenRouter vs Eden AI Read the verdict → OpenRouter vs Hugging Face Inference Providers Read the verdict →

Usually weighed against

OpenRouter vs Eden AI Compare → OpenRouter vs Hugging Face Inference Providers Compare → OpenRouter vs Requesty Compare →

Follow updates about OpenRouter