Search across all documentation pages
OpenRouter is an OpenAI-compatible API gateway that routes chat, completion, and related calls to hundreds of models across many providers through one base URL, one key shape, and one request format.
You pick a model slug. OpenRouter picks (or you constrain) which upstream provider actually serves the tokens.
/api/v1 surface and bills usage through credits (or BYOK).OpenRouter sits between your app and model hosts (OpenAI, Anthropic, Google, Meta-hosted endpoints, open-weight hosts, and many more).
Your code talks to https://openrouter.ai/api/v1 using the familiar chat completions shape (and related endpoints).
OpenRouter maps that request onto the selected model's upstream API, returns a normalized response, and records usage metadata.
The product promise is access + routing + aggregation, not "we train the frontier model."
Model inventory is large and moves quickly (manifest pin: ~315+ models; live catalog often higher - verify at build on openrouter.ai/models).
Each model is addressed by a slug, typically provider/model-name, sometimes with a variant suffix such as :free, :nitro, :floor, or :exacto.
That slug is the main control surface for agents: swap the string to A/B models without rewriting client code.
OpenRouter is not a substitute for:
It is a practical default when agents need flexible model choice and production-minded failover.
A typical request path:
Authorization: Bearer ...).model to a slug (for example anthropic/claude-sonnet-4 or an alias like ~openai/gpt-latest - verify at build).Compatibility is the integration story.
Most OpenAI SDKs and agent frameworks accept a custom base_url / baseURL. Pointing that at OpenRouter is enough for chat completions, streaming (SSE), and tool/function calling when the target model supports it.
Optional headers (HTTP-Referer, X-OpenRouter-Title) attribute traffic to your app for rankings. They are not required for correctness.
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key="...", # OPENROUTER_API_KEY
)
resp = client.chat.completions.create(
model="openai/gpt-4o-mini", # slug; verify catalog at build
messages=[{"role": "user", "content": "ping"}],
)Agents care about three OpenRouter features more than branding:
| Feature | What it does for agents |
|---|---|
| Model swap by slug | Eval and production can change models via config |
| Provider fallback | Softens single-vendor outages mid-loop |
| Routing preferences | Trade cost, latency, or tool-call reliability (:floor, :nitro, :exacto) |
Billing and privacy are separate control planes.
Credits fund shared OpenRouter capacity. BYOK attaches your provider keys so inference bills the lab while OpenRouter still normalizes the API (with a free monthly request threshold, then a percentage fee - verify at build).
Data policies let you prefer zero-retention or non-training endpoints - critical when agents touch customer data.
For multi-agent systems, treat OpenRouter as infrastructure, not as the agent framework.
LangGraph, CrewAI, Vercel AI SDK, OpenAI Agents SDK, and similar stacks remain the loop owners. OpenRouter is the model transport.
Patterns that work well:
data_collection: deny filters on sensitive tools; freer routing on public content.Trade-offs versus direct provider APIs:
| Approach | Strength | Weakness | Best fit |
|---|---|---|---|
| OpenRouter only | One integration, broad catalog, fallbacks | Extra hop; credit fee on purchase | Multi-model agents, startups, evals |
| Direct provider APIs | Closest SLA/features; simple vendor relationship | N integrations; hard failover | Single-provider products |
| Hybrid (direct primary + OpenRouter backup) | Control + safety net | Two billing systems | Enterprises with a preferred lab |
| Self-hosted open weights | Data residency and cost at scale | Ops burden | Air-gapped or high-volume open models |
Enterprise buyers should still review Terms, Privacy, subprocessors, and whether specific model endpoints meet compliance - the gateway does not magically unify every lab's legal terms.
base_url at OpenRouter replaces agent architecture." You still need loops, tools, stop conditions, and evals.The request/response shape is intentionally compatible, so OpenAI SDKs usually work with a different base URL and key. Upstream models, pricing, routing, and headers are OpenRouter-specific.
Hundreds across many providers. Treat any fixed count as stale; check the models API or site catalog at build time. This guide's stack pin uses ~315+.
No. One OpenRouter client can call Claude, GPT, Gemini, Llama hosts, and others by changing the model slug (when each is listed).
A string ID such as google/gemini-2.5-flash that selects the model (and optional behavior via suffixes like :free or :nitro). Exact slugs change over time - verify at build.
By default OpenRouter does not log prompt/completion content for training; logging is opt-in. Upstream providers may have different policies. Use privacy settings and data-policy filters for enterprise control.
When you are locked to one provider's exclusive features, need a pure bilateral enterprise contract without a gateway, or must stay fully on-prem with no external hop.
Yes when the selected model and provider endpoint support tool/function calling. Normalize tool schemas on your side; capability still varies by model.
OpenRouter can fall back to other providers for the same model if your routing allows it. If no eligible endpoint remains, you get an error (often 503-class) and your agent should retry or degrade.
Yes via server-sent events when stream: true, similar to OpenAI-compatible streaming.
Those frameworks orchestrate agents. Configure their model provider/base URL to OpenRouter so the framework keeps control of tools and memory while OpenRouter supplies models.
Often related weights, but free variants may differ in capacity, rate limits, logging, or hosting. Never assume parity without evals.
OpenRouter API keys, and separately any BYOK provider keys. Scope keys per environment and set per-key spend limits when available.
No. MCP and A2A are tool/agent protocols. OpenRouter is model inference transport.
OpenRouter's activity dashboard and credits/key APIs. Agent platforms should still log their own traces with model slug, tokens, and provider when exposed.
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.
Reviewed by Chris St. John·Last updated Jul 16, 2026