LiteLLM vs OpenRouter vs Portkey: Which AI Gateway for Your Team in 2026?

Introduction — gateways became infrastructure

AI gateways stopped being optional in 2026. Any team spending more than a few thousand dollars a month on LLM APIs now runs one — either an open-source proxy like LiteLLM, a SaaS marketplace like OpenRouter, or an enterprise gateway like Portkey. The three look similar on the surface (all put a routing layer between your app and multiple LLM providers) but make fundamentally different bets. Picking the wrong one adds either operational overhead you didn't budget or per-token fees you'll regret at scale.

This post is the honest 2026 comparison. Real pricing (including the fees the marketing pages downplay), real trade-offs, real weaknesses of each. If you're evaluating your first gateway, read start-to-finish. If you're weighing a switch, skip to pricing, honest weaknesses, and the team decision matrix. If you already run one and want to defend it, at least read the concessions section in the verdict.

Companion posts: the frontier model comparison covers the underlying models these gateways route to. The coding tool comparison covers the layer above (IDE tools). For the cross-cutting cost framework, see the Cost Optimization Playbook.

The contenders — three different bets

Each gateway makes a different bet about what teams need most:

• OpenRouter bets you want access to every model through a single API key with zero infrastructure. Sign up, add credits, call 300+ models. Think "Stripe for LLMs" — they handle provider credentials, routing, and billing while you focus on the app.
• LiteLLM bets you want full control, self-hosted, with zero vendor lock-in and zero markup on the underlying provider rates. You run the proxy; you pay only provider costs.
• Portkey bets you need enterprise-grade observability, guardrails, and reliability features more than you need another API proxy. Managed SaaS with a self-hosted gateway option for the routing layer.

Three genuinely different products. If you're trying to pick between them based on "which routes to more models," you're asking the wrong question. All three route to enough models. The right questions are about operational model, cost structure at your scale, and which features you actually need.

Deployment model — OSS vs SaaS vs marketplace

This is the fastest way to eliminate one option. If your team can't or won't run infrastructure, LiteLLM is off the table. If you can't tolerate a per-token or per-purchase markup at scale, OpenRouter becomes painful past a certain volume. If you don't need guardrails and SOC 2 today, Portkey is likely overkill.

LiteLLM — you run the proxy

LiteLLM ships as a Python package and Docker image. Deploy on any container platform (Kubernetes, ECS, Fly.io, Railway, your own VMs). Configuration lives in a config.yaml file — see the model_list not loading error page for the specific YAML structure and common gotchas.

Operational reality: you need to run and maintain Redis for shared router state across instances, Postgres for virtual key persistence, and a load balancer for HA. Not hard, but not zero. Budget one engineer-day per month for maintenance at typical scale; more if you're pushing the load balancer or Redis to their limits.

OpenRouter — no infrastructure

Sign up at openrouter.ai, buy credits, get one API key, use it. That's the entire onboarding. Your app calls https://openrouter.ai/api/v1/chat/completions exactly like OpenAI's endpoint, with a model string like anthropic/claude-sonnet-4-6. Done.

No infrastructure means no maintenance, no Redis, no load balancer. Also no self-hosted data residency (if your compliance requires EU-only, OpenRouter's US infrastructure is a problem). And no way to run in air-gapped environments.

Portkey — SaaS with self-hosted gateway

Portkey's hosted service handles routing, virtual keys, observability, and guardrails. Or you can run just the gateway component self-hosted while sending observability data to their hosted dashboard — see the observability traces missing page for the specific setup pattern.

Hybrid model gets you data residency for the routing layer while keeping the dashboard convenient. Fully self-hosted is possible but you lose the managed observability dashboard unless you build your own logging pipeline (Elasticsearch, DataDog, etc.).

Pricing head-to-head — the real math

Pricing gets confusing because each gateway prices differently. Real cost comparison requires modeling your actual traffic pattern, not comparing per-token headline numbers.

The break-even math

Real spend depends on your monthly AI API budget:

• Under $2,000/mo: OpenRouter is simplest. The 5.5% fee is $110/mo on $2K — often less than the operational cost of running LiteLLM. Portkey Developer plan (~$99/mo) plus provider costs is competitive if you need observability.
• $2,000-$10,000/mo: All three are viable. OpenRouter costs $110-$550/mo in markup fees. LiteLLM's infrastructure cost is roughly $200-$500/mo (Redis + Postgres + proxy instances). Portkey Production (~$499/mo) plus direct provider costs breaks even around $5K/mo AI spend.
• Over $10,000/mo: LiteLLM becomes the clear cost winner. On $20K/mo AI spend, OpenRouter's 5.5% fee costs $1,100/mo — pays for LiteLLM's infrastructure many times over. Portkey Enterprise pricing is negotiated but roughly breaks even against LiteLLM once you value observability and guardrails at $500-1000/mo internally.
• Over $50,000/mo: LiteLLM is a slam dunk on cost alone. OpenRouter's $2,750+/mo fee at that spend is real money. Portkey Enterprise makes sense only if you need the specific enterprise features (compliance, RBAC, guardrails).

The hidden cost every team forgets

All three gateways help you save money via caching, routing, and provider fallbacks. But the biggest cost lever is model selection, not routing choice. A router that sends every request to Claude Opus when Haiku would suffice costs 30x more. See Chapter 5 of the Cost Optimization Playbook for the routing patterns that actually move the cost meter.

Instrument spend per workload_tag from day one (all three gateways make this easy). The wrong gateway with good model selection beats the right gateway with bad model selection.

Multi-provider routing & fallbacks

Routing is what these tools were built for. Implementation differs meaningfully.

LiteLLM — most powerful, most configuration

LiteLLM supports four separate fallback lists per model: fallbacks (generic errors), content_policy_fallbacks, context_window_fallbacks, and budget_fallbacks (added v1.85+). Deployments have order priorities; the router tries order=1 exhaustively, then order=2, then falls through to cross-model fallbacks. Routing strategies include simple-shuffle, least-busy, usage-based-routing, and latency-based-routing.

This power is a two-edged sword. Misconfigured fallbacks can trigger cost spirals — see the fallback retry loop cost spiral page. A rate-limited Sonnet request cascading to Opus (5x cost) then to Terra (parallel expense) can 10x a single request's cost. Cap num_retries: 2 and max_fallbacks: 1 explicitly.

OpenRouter — automatic with variant hints

OpenRouter's default routing load-balances across providers for your chosen model, weighted by inverse-square price. Provider A at $1/M is 9x more likely than Provider C at $3/M. Overrides via provider object (sort, only, ignore, max_price) or variant suffixes (:nitro for throughput, :floor for price). See the provider preferences ignored page for common configuration mistakes.

Simpler than LiteLLM but less powerful. No content-policy-specific fallback, no context-window-specific fallback. For most workloads, that's fine.

Portkey — config-based routing with load balance + fallback

Portkey's Gateway configs define routing strategy explicitly. Load-balance across weighted targets, fallback on specific status codes, or single-target with retries. Configs are versioned in the dashboard and referenced by ID (e.g., pc-request-edf21c). See the config version mismatch page for the referencing gotchas.

Nice middle ground: more powerful than OpenRouter's simple picker, less finicky than LiteLLM's YAML. UI-managed configs mean routing changes don't require code deploys.

Caching strategies — simple, semantic, hybrid

Prompt caching is the single highest-ROI cost optimization for most workloads (see Chapter 3 of the Cost Optimization Playbook). Gateway-level caching adds a second layer on top of provider-level caching — exact-match or semantic-match cache hits skip the provider call entirely.

LiteLLM — Redis-backed simple cache

LiteLLM's cache uses Redis. Exact-match on request payload; TTL configurable per request or globally. Works well for FAQ workloads, deterministic prompts, and templated content. No semantic cache in the core OSS; you'd add embedding-based caching yourself if needed.

OpenRouter — no native caching

OpenRouter doesn't offer gateway-level caching. Provider-level caching (Claude cache_control, OpenAI's automatic caching, Gemini context caching) still works when routed through OpenRouter, but you get no extra caching layer from the gateway itself.

For high-repetition workloads, this is a real gap. Teams using OpenRouter typically build their own cache layer in front of the OpenRouter call.

Portkey — simple + semantic cache modes

Portkey supports both modes. mode: "simple" for exact-match; mode: "semantic" for embedding-similarity above a configurable threshold. Per-user cache scoping via namespace. See the cache miss / mode confusion page for the common misconfigurations.

Semantic caching is Portkey's biggest differentiator vs LiteLLM. For customer-support workloads where users ask "similar but not identical" questions, semantic cache can push hit rates from 5-10% (simple) to 40-60% (semantic). At that hit rate, gateway-level caching often outweighs the Portkey subscription cost several times over.

Observability & cost attribution

You can't optimize what you can't measure. Gateway observability is table stakes in 2026.

LiteLLM — callback ecosystem

LiteLLM forwards events to any observability backend via callbacks: Langfuse, LangSmith, OpenTelemetry, Prometheus, Sentry, S3, DynamoDB, custom. See the callback failure page for the setup patterns and common gotchas (async batching delays, env var expansion failures, callback name typos).

Bring-your-own-observability is the pattern. LiteLLM doesn't ship a dashboard — you connect it to Langfuse for tracing, Prometheus for metrics, your BI tool for cost analytics. Flexible but requires assembly.

OpenRouter — activity dashboard, no traces

OpenRouter's Activity tab shows real-time usage, cost per model, cost per key. Good enough for basic accounting. No request/response tracing, no per-request cost attribution beyond what's aggregated in the dashboard. For deep observability, you'd export logs and pipe them elsewhere.

Portkey — hosted observability dashboard

Portkey's observability is the strongest of the three out of the box. Every request captured with full trace: request/response body (subject to privacy config), latency breakdown, cost calculation, cache status, guardrail results, retry attempts, metadata tags. Free tier includes 10,000 logs/month.

Filter traces by metadata tags (environment, team, feature, user_id) for cost attribution reports. For teams that need "what did the growth team spend on the onboarding flow last week?" answers, Portkey ships that out of the box. LiteLLM can do it but requires you to assemble the query pipeline yourself.

Governance — keys, budgets, guardrails

Governance is where gateways earn their keep in enterprise settings. Rate limits per team, budget caps per feature, content moderation per request — all three offer some form, with different depth.

Virtual keys and budgets

All three support virtual keys — sub-keys with independent rate limits, budgets, and model allowlists. See the specific patterns:

• LiteLLM virtual key max_budget — rate limits per RPM/TPM, budget caps per hour/day/month, budget fallbacks in v1.85+
• Portkey virtual keys — rate limits, usage limits, model allowlists, workspace-level caps
• OpenRouter BYOK — bring your own provider keys for 1M free routing requests/month; simpler than a full virtual key system

Guardrails

Portkey wins this category decisively with 50+ built-in checks (PII detection, content moderation, prompt injection, JSON schema validation, regex filters) plus integrations with Aporia, SydeLabs, and Pillar Security. Guardrails run as before-request-hooks and after-request-hooks, with sync mode (affects request outcome) or async mode (logs only). See the guardrails blocking legitimate content page for tuning patterns.

LiteLLM has basic guardrail support via callbacks — you can register a callback that inspects request content and raises an exception on policy violation. Less polished than Portkey; more assembly required.

OpenRouter has none natively. If you need guardrails at the routing layer, OpenRouter isn't the tool.

Enterprise features & compliance

Compliance certifications

• Portkey: SOC 2, GDPR, HIPAA available. Most mature enterprise story.
• LiteLLM Enterprise: SSO, audit logs, managed hosting available in the paid tier. OSS version doesn't carry vendor-issued compliance certs — you inherit whatever your infrastructure provides.
• OpenRouter: Enterprise plan exists but compliance certifications are less prominent. Typically not the pick for teams with strict compliance requirements.

SSO & RBAC

Portkey ships SAML SSO, SCIM provisioning, and role-based access control on Enterprise. LiteLLM Enterprise adds SSO. OpenRouter's enterprise SSO is available but less feature-rich than the other two.

Data residency

LiteLLM is the winner here by architecture — you host it wherever your compliance requires. EU-only? Deploy in Frankfurt. Air-gapped? Deploy in your VPC. No vendor decision to make.

Portkey primarily hosts in US with some enterprise EU options; self-hosted gateway lets you place the routing layer in your region. OpenRouter is US-hosted with no self-hosted option — data-residency-strict teams typically eliminate OpenRouter early.

Where each one falls down

Honest weaknesses — the parts marketing pages skip.

LiteLLM's weak spots

• Operational overhead is real. Redis, Postgres, load balancer, proxy instances — all yours to run and monitor. Budget one engineer-day per month at typical scale.
• YAML config gets unwieldy. A production config with 20+ models, per-model fallbacks, and virtual key policies is 200+ lines. Version-controlled, but hard to review.
• Fallback cascades can spiral. Default fallback configuration can trigger cost cascades when a rate-limited Sonnet request cascades to Opus. See the cost spiral page.
• Semantic caching not built-in. Redis-backed simple cache only in core OSS. You'd add embedding-based caching yourself.
• Callback debugging is opaque. The callback failure page documents the common silent failures — enable debug mode or you'll wonder why traces aren't landing.

OpenRouter's weak spots

• The 5.5% fee compounds. On $20K/mo AI spend, that's $1,100/mo — pays for LiteLLM infrastructure with change to spare. Real teams don't stay on OpenRouter forever if they scale.
• Free tier is production-hostile. 20 req/min hard cap on free-tier models, 50-1000 req/day daily limits. Not a production SLA. See the rate limits page.
• No caching layer. Provider-level caching still works, but no OpenRouter-level cache. High-repetition workloads leave money on the table.
• ~25-40ms gateway overhead. Fine for prototyping. Meaningful when you're targeting sub-second first-token latency.
• No self-hosting. Data residency compliance often eliminates OpenRouter early.
• Model slugs can deprecate silently. See the no endpoints found page — always use models fallback array in production.

Portkey's weak spots

• Subscription cost adds up. Developer plan (~$99/mo) plus Production plan (~$499/mo) plus Enterprise pricing on top of provider costs. Not the cheapest option below $5K/mo AI spend.
• Self-hosted observability is second-class. Self-hosted gateway is available, but the observability dashboard is hosted SaaS by default. See the traces missing page for the setup gotchas.
• Guardrails require Developer tier. Not available on the free tier. Plan the tier upgrade before designing the guardrail strategy.
• Config-by-ID adds a dashboard dependency. Managed configs are recommended but coupling your code to dashboard-managed config IDs means dashboard becomes a critical dependency. Inline configs work but lose the dashboard advantages.
• Semantic cache is powerful but easy to misuse. Wrong similarity threshold either kills hit rates (too strict) or serves near-duplicate content that isn't actually appropriate (too loose).

None of these are dealbreakers on their own. But if you're evaluating for a team, understand what you're signing up for.

Which to use for which team

The most productive teams often use multiple gateways at different layers. Here's the decision matrix by team profile:

The hybrid pattern many teams end up with: OpenRouter for exploration and non-critical paths, LiteLLM for production critical paths. Test new models on OpenRouter (fastest to try), route production traffic through self-hosted LiteLLM for cost and reliability. Portkey enters the picture when governance features (compliance, guardrails, RBAC) become requirements.

The verdict & further reading

The three products don't compete head-to-head for the same team. They serve overlapping but meaningfully different needs. Cost math and operational capacity determine which fits your team more than any feature comparison.

Concessions each side has to make:

• LiteLLM fans should acknowledge that ops overhead is a real cost, and that OpenRouter's zero-infrastructure onboarding is genuinely compelling for teams that can't dedicate DevOps time to a proxy. Also acknowledge that Portkey's observability and guardrails require significant assembly to replicate in LiteLLM.
• OpenRouter fans should acknowledge that the 5.5% fee compounds meaningfully at scale, and that the lack of caching, guardrails, and self-hosting is a real limitation for production workloads past a certain size.
• Portkey fans should acknowledge that subscription cost adds up, and that the value proposition is weak below ~$5K/mo AI spend where the observability and guardrails aren't yet mission-critical.

The one thing that always holds

Whichever gateway you pick, instrument spend per workload_tag from day one. All three make this easy. The observability chapter of the Cost Optimization Playbook covers the standard pattern. Gateway choice is a smaller cost lever than model selection, context management, and prompt caching — get the fundamentals right first, then optimize gateway choice.

If you're just starting: OpenRouter for the first 3-6 months. Prove out the workload. Instrument spend velocity. When monthly AI spend crosses ~$5K, revisit the choice with real usage data. Nine times out of ten, the "obviously right" gateway at day zero isn't the right gateway at scale — but you can't know until you have data.

Further reading

Deep dives on each gateway's error patterns:

• The Complete Guide to AI API Cost Optimization in 2026 — twelve cross-cutting cost levers by ROI
• The Complete Guide to Claude API Errors in 2026 — underlying provider these gateways route to
• The Complete Guide to OpenAI API Errors in 2026 — underlying provider these gateways route to
• The Complete Guide to Google Gemini API Errors in 2026 — underlying provider these gateways route to

Companion blog posts:

• GPT-5.6 vs Claude Sonnet 4.7 vs Gemini 3.5 Pro — the underlying models your gateway routes to
• Cursor vs Claude Code vs GitHub Copilot — the coding tools that sit above the API layer

All 15 gateway-tool error pages are indexed at /errors/. All 10 pillar guides at /guides/. And you'll find the tools we use for cost math and error triage at /tools/.