gateway vs litellm: a TypeScript routing layer against a Python proxy with spend tracking
Portkey's gateway is a small TypeScript service that puts retries, fallbacks, load balancing and output guardrails in front of provider calls. LiteLLM is a Python SDK plus a self-hosted proxy that normalises 100+ providers behind one OpenAI-compatible endpoint with virtual keys and cost tracking. They overlap, but the centre of gravity differs: gateway is a routing and guardrail layer, LiteLLM is a provider-abstraction and key-management service.
At a glance
| Project | Portkey-AI/gateway | BerriAI/litellm |
|---|---|---|
| Licence | MITPermissive: commercial use allowed | Custom licenceCustom licence: read the LICENSE file |
| Maintenance | Commits in the last six monthsLast push May 25, 2026 | Commits in the last six monthsLast push September 25, 2026 |
| Language | TypeScript | Python |
| GitHub stars | 13,022 | 59,624 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose gateway if you already call several providers directly, want retries, fallbacks, conditional routing and output guardrails in one small service, and are willing to pin the npm package rather than track main.
Choose litellm if provider sprawl is the bottleneck, you want one OpenAI-compatible endpoint with virtual keys, spend tracking, load balancing and logging, and you can run a Postgres-backed proxy alongside your application.
Two different centres of gravity
Portkey's AI Gateway is an MIT-licensed TypeScript service. Its README frames it as a fast, lightweight router: it advertises sub-millisecond latency and a 122kb footprint, and lists automatic retries, fallbacks, load balancing, conditional routing, guardrails and multi-modal support as the things you do with it. The routing config is the interesting part, since the behaviour you want lives in configuration rather than in application code. LiteLLM ships in two shapes. The Python SDK is imported directly, with completion calls that name the provider in the model string, for example openai/gpt-4o or anthropic/claude-sonnet-4-20250514. The proxy server is a separate deployment on port 4000 that speaks the OpenAI format and adds virtual keys, spend tracking, guardrails, load balancing and an admin dashboard. The README describes 8ms P95 latency at 1k RPS in its benchmarks. So gateway is a layer you put in front of calls you already make, while LiteLLM is a library you call and, optionally, a service your whole team routes through. That difference decides most of the rest.
Getting each one running
Gateway's quickstart is one command: npx @portkey-ai/gateway, which starts the service on localhost:8787 and a console on localhost:8787/public. The README lists deployment guides for Portkey Cloud, Docker, Node.js, Cloudflare Workers and Replit, and the client example passes the provider API key inline as an Authorization value. That inline key is the first operational question: our analysis of gateway says you should decide how provider keys reach the process in your environment before you commit, because the quickstart shows them in the request rather than in a secret store. LiteLLM's SDK path is a package install and an import; the proxy path is uv tool install 'litellm[proxy]' followed by litellm --model gpt-4o, after which an OpenAI client points at base_url http://0.0.0.0:4000. The proxy is the heavier install. Our analysis of litellm says it adds a Postgres dependency and a config file you would otherwise not maintain, and that you should check whether the database migrations in migrations/ apply cleanly against your Postgres version. If you only ever call one vendor from one service, that is weight you do not need. The README also shows A2A agent invocation through the proxy, where an agent is registered and then called through a path like /a2a/my-agent with a virtual key as the bearer token.
Operations, keys and scaling
This is where the two diverge most sharply. Gateway keeps state light: it is a routing and guardrail layer, and the README's emphasis is on latency and footprint rather than on multi-tenant control. It does not present virtual keys or spend tracking as part of the core story. LiteLLM's proxy does. Virtual keys, spend tracking, an admin dashboard and logging are listed as production features, and the proxy is designed to be a central service for a team or organisation. That difference matters when more than one team or application shares the endpoint. A shared proxy needs per-key budgets, a database for spend records and a migration path for schema changes; a per-service routing layer does not. The cost is operational: a Postgres instance to run, back up and upgrade, plus a config file and a release cadence to track. Our analysis of litellm says you should verify whether the pinned image tag main-stable matches your release cadence, since a moving stable tag and a slower internal upgrade cycle can drift apart. Gateway's scaling story is simpler because there is less to scale, but it also means key governance and cost attribution stay in your own systems.
Where each one falls short
Gateway's weakness is maintenance cadence. The last push to main was on 2026-05-25, and the newest release is v1.15.2 from 2026-01-12. The README points readers at a pre-release 2.0 branch where the core enterprise gateway is merging into open source. Our analysis of gateway says not to adopt it if you need a gateway that is being actively developed right now, and to pin the npm package rather than track main. That is a real constraint for teams that expect upstream fixes on demand. The second gap is provider coverage in practice: the README claims 1600+ models, but our analysis says to verify that the provider you need appears in the supported list before you commit. LiteLLM's weakness is the opposite shape. It is current, with the last push on 2026-09-25, but it carries more moving parts: a Python runtime, a Postgres database for the proxy, migrations and a config file. Its licence is also less clear than gateway's. Gateway is MIT. LiteLLM's repository is classified by GitHub as Other, a custom licence GitHub cannot classify; our analysis of litellm says pyproject.toml declares MIT while the README does not state a licence, so you should confirm which licence file the repository actually carries. For a legal review, that is the first thing to settle.
Licence and maintenance implications
Gateway's MIT licence is unambiguous, which makes it easy to embed in a commercial product or fork if upstream slows. The trade-off is that the project's own README now directs attention to a 2.0 pre-release branch, so the mainline you install today may not be where the next round of work lands. Our analysis of gateway frames the practical response as pinning the package and treating upgrades as deliberate events rather than routine pulls. LiteLLM's maintenance picture is more current, with releases through 2026 and a last push on 2026-09-25, but its licence classification is not. GitHub lists it as Other, and our analysis of litellm says pyproject.toml declares MIT while the README does not state a licence. Until that is resolved, teams with strict licence review should treat the proxy as needing legal sign-off before it becomes a shared dependency. The two also differ in what a fork would cost. Gateway is a TypeScript service with a narrow surface, so a fork is plausible. LiteLLM's proxy carries a database schema and migrations, so a fork means owning that schema too.
Choosing for concrete scenarios
If you have a single application calling OpenAI, Anthropic and Bedrock directly and you keep rewriting retry and fallback logic, gateway is the smaller change: one service in front, routing config for the failover order, and guardrails applied to outputs. If you are a platform team standing up one endpoint for several product teams, with per-team keys and a spend report at the end of the month, LiteLLM's proxy is the closer fit, because virtual keys and spend tracking are part of the product rather than something you build. If you want to call providers from inside Python without running another service, LiteLLM's SDK is the only one of the two that offers that shape; gateway expects an HTTP hop. If your constraint is a small footprint or a Cloudflare Workers deployment, gateway's README lists Workers as a target and the service is TypeScript, while LiteLLM's proxy expects a Python host and Postgres. If your constraint is upstream activity, LiteLLM is the safer bet today. The two are not mutually exclusive: a team could run LiteLLM's proxy as the shared endpoint and keep gateway's routing config in front of a specific service, though that doubles the hops and the configuration to maintain.
Bottom line
Pick gateway when the problem is retries, fallbacks and output guardrails in front of calls you already make, and you accept pinning the package while the 2.0 branch matures. Pick litellm when the problem is provider sprawl across teams and you want virtual keys and spend tracking in one OpenAI-compatible service, accepting a Postgres dependency and a licence question to resolve. Before either rollout, verify the provider you need is supported, that the deployment artefact you intend to run exists and is tagged the way you deploy it, and, for litellm, which licence file the repository actually carries.