OpenRouter Setup & Routing Best Practices
Ten practices for a clean, swappable OpenRouter integration from day one.
Search across all documentation pages
Ten practices for a clean, swappable OpenRouter integration from day one.
Use this list when wiring the first gateway client so auth, slugs, routing, and observability do not need a rewrite two sprints later.
https://openrouter.ai/api/v1.HTTP-Referer and X-OpenRouter-Title are rankings metadata, not auth.fast / balanced / strong (or route names) in config.response.model, usage, and latency every call. Especially for auto-router and fallback chains.models arrays and/or provider preferences; avoid improvised retry-to-random-model code.# one module, many importers
from app.llm.openrouter import client, completeRotate keys on any exposure alert.
Do not embed keys in frontends.
{
"balanced": {
"model": "anthropic/claude-sonnet-4.5",
"fallbacks": ["openai/gpt-4o-mini"]
}
}Illustrative slugs only - verify at build.
Emit structured logs:
policy=balanced requested=anthropic/claude-sonnet-4.5 resolved=... tokens=... ms=...Prefer price/uptime defaults until you have a compliance reason to pin providers.
When you pin, document why allow_fallbacks is false.
For agents, pass session_id when using openrouter/auto so multi-turn model choice stays sticky.
| Test | Expect |
|---|---|
| curl with valid key | 200 + content |
| wrong key | 401 |
| bad slug | 400 |
| stream | tokens without JSON parse crash on comments |
| fallback map (optional) | resolved model logged |
Practices 1-3 and 10 are enough for a prototype.
Add 4-9 before shared production traffic.
No.
The policy-map habit applies to direct providers too; OpenRouter makes multi-model ops easier.
No.
Use it for mixed unknown prompts with constraints; pin models for scored, regulated, or SLA paths.
On every model change PR and on a scheduled dependency review (for example monthly).
In route config and account privacy settings - expand in the cost and fallback section.
request_id, policy, requested_model, resolved_model, status, latency_ms, prompt_tokens, completion_tokens, error_type.
They help with client construction.
They rarely enforce policy maps, fallback discipline, or smoke tests for you.
Per-key limits are a safety rail, not a substitute for agent max-turn budgets.
Default on for user-facing chat; default off for batch evals and many background agents.
CI: auth shape, slug validation, unit tests for the resolver.
Production: error rate, p95 latency, cost per successful task, fallback rate.
Those rules are product-level.
This checklist is the OpenRouter-specific implementation of the same idea.
When OpenRouter is a single point of failure for a critical path and the business accepts multi-key operational cost.
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