Portkey vs LiteLLM vs OpenRouter for LLM routing
Portkey, LiteLLM, and OpenRouter all sit between an application and model providers, but they are not the same product shape. Portkey combines an open-source gateway with managed controls. LiteLLM is an OpenAI-compatible gateway and proxy that teams can run themselves. OpenRouter is a hosted unified API with provider routing and per-model metadata. The decision starts with ownership, control, and catalog access, not a feature-count leaderboard.
TL;DR verdict
Choose Portkey when managed gateway controls and support requirements drive the decision. Choose LiteLLM when a self-operated OpenAI-compatible proxy is the priority. Choose OpenRouter when a hosted catalog and routing API is the desired abstraction. Validate provider behavior, logging, failure handling, and cost accounting with your own traffic before standardizing.
Key takeaways
- Portkey's current plan page distinguishes recorded-log allowances from request overage wording; keep those units separate.
- LiteLLM capacity is deployment-defined when you run the proxy yourself.
- OpenRouter documents limits that vary by model, provider, credits, and account rather than one universal quota.
- Repository stars are available for Portkey and LiteLLM. OpenRouter is a hosted service with no comparable repository counter in this comparison.
At-a-glance comparison matrix
| Option | Product shape | Best fit | Commercial or operating model |
|---|---|---|---|
| Portkey | Open-source gateway plus managed controls | Teams evaluating managed operations and support | Recorded-log plan allowances and separately worded overages |
| LiteLLM | OpenAI-compatible gateway/proxy | Teams that want self-hosted routing control | Deployment-defined capacity |
| OpenRouter | Hosted unified model/provider routing API | Teams that want hosted catalog access | Provider inference pricing plus documented credit-purchase fee |
Evidence-backed comparison
Pricing and operating model
Portkey currently lists Developer as Free Forever with 10k recorded logs per month. The page says exceeding that limit does not affect requests; only logs beyond the limit are not recorded. Production is $49/month with 100k recorded logs per month, while the same page displays “+$9 overages per additional 100k requests.” Preserve that recorded-log allowance versus request-overage distinction instead of normalizing both to requests. OpenRouter says it passes through provider inference prices without markup and charges a 5.5% credit-purchase fee with an $0.80 minimum for card payments. LiteLLM's open-source repository does not provide a normalized managed-plan grid comparable to those pages. These terms come from the Portkey pricing page and OpenRouter FAQ accessed 2026-08-25; check the current pages before estimating cost.
Plans, quotas, and limits
Portkey's current plan table distinguishes 10k and 100k recorded-log allowances per month, not request allowances. It says exceeding the Developer recorded-log limit does not affect requests; only logs beyond the limit are not recorded. Its Production row separately displays “+$9 overages per additional 100k requests,” so preserve the page's recorded-log/request distinction and exact overage wording. OpenRouter documents free-model daily limits and separate paid/BYOK behavior; limits vary by model, provider, credits, and account. A self-hosted LiteLLM proxy has deployment-defined capacity rather than one vendor-imposed universal request quota.
Adoption signals
At access time GitHub reported Portkey gateway 12,821 stars/1,267 forks and LiteLLM 57,242/10,886. OpenRouter is a hosted service without a comparable repository counter in this comparison. Do not place service popularity and repository stars in one numeric ranking.
Versions and releases
Current GitHub release records identify Portkey gateway v1.15.2 and LiteLLM v1.98.0. OpenRouter's hosted API exposes a current model catalog rather than a product release version; at access time the models endpoint returned 419 entries. Treat catalog size and software version as different fields, and verify both against current records before deployment.
Runtime and integration fit
Portkey documents an open-source gateway and managed service; LiteLLM documents an OpenAI-compatible gateway/proxy; OpenRouter documents a unified API with provider routing. Limit provider, model, framework, data-residency, and observability integration claims to exact current documentation rather than fixed 100+/200+ counts or universal compatibility.
Documented capabilities
Current docs describe Portkey as an open-source gateway plus managed controls, LiteLLM as an OpenAI-compatible gateway/proxy, and OpenRouter as a hosted unified model/provider routing API with per-model pricing metadata. They do not establish prompt management, guardrails, semantic caching, data residency, or custom deployment equivalence across all three.
How to use popularity signals
A useful fit framework separates managed controls and support requirements, self-hosted proxy control, and hosted catalog access. Repository counters are dated context for Portkey and LiteLLM only; they do not rank OpenRouter or prove product quality.
Source availability and current status
All cited official GitHub, documentation, pricing, FAQ, limits, and model-catalog endpoints were reachable on 2026-08-25. This is an access-time source check only, not an uptime, residency, reliability, or provider-status guarantee. Check current hosted-service status, limits, prices, and catalog entries for a production decision.
Decision framework
First decide whether the gateway must run in your infrastructure or can be a hosted routing service. Then test the exact models and providers you need for streaming, tool calls, structured output, fallback behavior, error mapping, and request compatibility. Treat logging, redaction, retention, data residency, cost attribution, and support as separate requirements. Compare Portkey's managed controls, LiteLLM's self-operated proxy, and OpenRouter's hosted catalog only after those requirements are explicit.
Migration notes
Put the gateway behind one application-owned adapter before changing providers. Replay a redacted evaluation set through the candidate, then compare error mapping, streaming, tool calls, structured outputs, retries, logging, and billing records. Preserve a rollback path to the current provider endpoint. Do not assume that OpenAI-compatible means identical behavior for every model or response field.
Methodology
This comparison uses Portkey and LiteLLM documentation, GitHub repository and release records, Portkey pricing, and OpenRouter's FAQ, limits reference, and model catalog. All were accessed 2026-08-25. Recorded logs, requests, model catalog entries, provider prices, and credit-purchase fees remain separate because they measure different things. No controlled cross-product benchmark was run, so latency, uptime, and savings claims would require named models and providers, regions, cache state, concurrency, versions, repetitions, and raw output. Recheck current prices, limits, releases, catalog entries, and service status before choosing or deploying a gateway.
Source notes
- LiteLLM documentation — accessed 2026-08-25
- LiteLLM GitHub release record — accessed 2026-08-25
- LiteLLM GitHub repository metadata — accessed 2026-08-25
- OpenRouter pricing and fees FAQ — accessed 2026-08-25
- OpenRouter API limits reference — accessed 2026-08-25
- OpenRouter model catalog — accessed 2026-08-25
- Portkey documentation — accessed 2026-08-25
- Portkey pricing — accessed 2026-08-25
- Portkey GitHub release record — accessed 2026-08-25
- Portkey GitHub repository metadata — accessed 2026-08-25
Source-backed FAQ
Are the three gateways feature-equivalent?
No. The cited documentation describes different product shapes and does not establish parity for caching, guardrails, residency, observability, or deployment options.
Can repository stars rank OpenRouter against Portkey and LiteLLM?
No. OpenRouter is represented here as a hosted service without a comparable repository counter, so one numeric ranking would mix unlike measures.
What should an LLM gateway pilot measure?
Measure request compatibility, failure behavior, streaming, provider routing, logs, cost attribution, and rollback time on your own models and regions.