Submit
Icon for LiteLLM ProxyIcon for Portkey Gateway

LiteLLM Proxy vs Portkey Gateway

Competes withCurated

LiteLLM and Portkey Gateway are the two most widely used general-purpose LLM gateways in the 2026 OSS landscape. Both route traffic across mainstream LLM providers via an OpenAI-compatible API, issue virtual keys with budget and rate limits, capture cost data, and expose MCP-aware endpoints for agent traffic. They differ in runtime stack, operational model, and the scope of features gated behind each project's commercial tier.

Core difference

LiteLLM is a Python SDK and proxy from BerriAI built on FastAPI and Postgres. Portkey is a Node.js and Go gateway from Portkey AI that can run stateless or Postgres-backed. The two projects also take different approaches to their commercial tiers: LiteLLM Enterprise covers SSO, JWT-to-virtual-key mapping, and audit log retention; Portkey Cloud is primarily a hosted offering with the gateway itself available as an MIT open-source codebase.

Feature comparison

CapabilityLiteLLMPortkey Gateway
RuntimePythonNode.js / Go
Provider integrations100+ native1,600+ endpoint variants
Virtual keys with hard budgetsOSSOSS
Admin UI SSOEnterpriseOSS
JWT-to-vkey mappingEnterpriseOSS
Audit log retentionEnterpriseOSS
MCP gatewayOSS (v1.78+)OSS (Gateway 2.0)
Guardrails frameworkBasic in OSS50+ built-in in OSS
DatabasePostgres requiredPostgres optional
Admin UIIncludedIncluded

When each fits

LiteLLM has the wider native provider catalog and a Python ecosystem that integrates cleanly with Python-first ML codebases. Portkey has a richer guardrails framework in OSS and a lighter state requirement for stateless deployments. Teams standardized on Python operational patterns, or that plan to use LiteLLM Enterprise for SSO, tend toward LiteLLM; teams on Node.js infrastructure, or that need OSS SSO without paying for an enterprise tier, tend toward Portkey.

Can they coexist?

Most teams standardize on one gateway. Running both complicates cost accounting since each tool tracks spend independently, and virtual keys do not portably cross between them.