Portkey vs LiteLLM: Which Gateway Fits Your Stack

Once a team has more than one model provider in production, the gateway question stops being theoretical. You need one place to route requests, one place to see cost and latency, and increasingly, one place to enforce rules about what a model is allowed to see or say before a request goes out. Portkey and LiteLLM both answer that need, but from different starting positions: Portkey is a hosted product with policy enforcement built in, LiteLLM is infrastructure you run and configure yourself. This post is about picking between them specifically, not a general gateway explainer.

What Portkey actually is

Portkey describes itself directly in its own gateway repository: "A blazing fast AI Gateway with integrated guardrails. Route to 1,600+ LLMs, 50+ AI Guardrails with 1 fast & friendly API" (Portkey AI Gateway on GitHub). That framing matters because it tells you what Portkey treats as core rather than bolted on: guardrails aren't an add-on module, they're in the product's own one-line description.

Portkey is hosted first, with the gateway component also available as open source software you can self-host if you want the routing logic without the managed layer. The hosted product adds a dashboard, request logging, and account management on top. It's SOC2, HIPAA, GDPR, and CCPA compliant according to Portkey's own gateway documentation, which matters if compliance requirements are part of why you're evaluating a gateway at all rather than calling providers directly.

What LiteLLM actually is, briefly

LiteLLM's own README puts it plainly: "LiteLLM is an open source AI Gateway that gives you a single, unified interface to call 100+ LLM providers, OpenAI, Anthropic, Gemini, Bedrock, Azure, and more, using the OpenAI format" (LiteLLM on GitHub). It's software you deploy and operate, free to run, with no markup on top of what providers charge. We've covered LiteLLM in real depth already, including the full self-host tradeoff and a decision framework for when self-hosting makes sense at all, in our LiteLLM vs OpenRouter comparison. This post assumes you've read that or already understand the self-host baseline, and focuses instead on what Portkey specifically adds on top of that baseline.

What Portkey specifically adds

This is the part worth spending time on, because "gateway" undersells the gap.

Guardrails. Portkey ships more than 50 configurable guardrails that can run before a request reaches a model or after a response comes back: PII detection and redaction, content moderation, jailbreak detection, and custom validation rules, all configured through the dashboard rather than written into application code. LiteLLM has some equivalent capability through its own guardrails hooks and callback system, but it's something you wire up and maintain yourself as part of your proxy configuration, not a pre-built catalogue you select from.

Virtual keys. Portkey's virtual keys let you issue scoped credentials per team, environment, or use case, so a given key can be capped on budget, restricted to specific models, or revoked independently without touching your actual provider API keys. This solves a real operational problem: without it, provider keys tend to spread across services and get shared more broadly than anyone intended.

Caching. Portkey supports both simple caching, exact-match request and response pairs, and semantic caching, where a request similar enough to a prior one in embedding space can be served from cache without hitting the model at all. That's a direct cost and latency lever that LiteLLM does not provide natively at the same depth; LiteLLM's caching integrations exist but are less central to its own positioning.

Self-host vs hosted, through the guardrails lens

The self-host versus hosted tradeoff isn't new, we cover the general shape of it in the LiteLLM piece, but it looks different when the reason you're comparing gateways is specifically "we need guardrails and caching built in" rather than "we need the widest model coverage."

If guardrails and caching are must-haves, building them into a self-hosted LiteLLM deployment is real engineering work: you're integrating a moderation API, writing PII detection logic or wiring in a third-party service, and building your own semantic cache layer, then maintaining all of it as models and threat patterns change. Portkey's pitch is that this work is already done and configurable through a UI, which is a genuine time-to-value advantage for a team that doesn't want guardrails engineering to become a dedicated workstream.

The cost of that convenience is the usual one: you're trusting Portkey's infrastructure with the requests and responses passing through its guardrail checks, and you're paying for a hosted product rather than free software. For a team with strict data residency requirements or an existing security review process built around self-hosted infrastructure, that tradeoff may not clear the bar even if the guardrails themselves are exactly what's needed.

Sourced from Portkey's AI Gateway repository and LiteLLM's repository, September 2026. Provider counts are each vendor's own published figures and use different counting methods, so treat them as rough scale indicators rather than an apples-to-apples number.

"A blazing fast AI Gateway with integrated guardrails. Route to 1,600+ LLMs, 50+ AI Guardrails with 1 fast & friendly API."

Portkey AI, gateway repository README

What is an llm gateway comparison actually supposed to tell you

Most gateway comparisons default to feature checklists that make every product look roughly equivalent, which isn't useful when you're trying to make an actual decision. The more useful question is which failure mode you're trying to prevent. If the fear is "a provider outage takes down our app," almost any gateway with fallback routing solves that, Portkey and LiteLLM both. If the fear is "a request leaks PII to a model provider" or "someone jailbreaks our support bot into saying something we can't defend," that's specifically a guardrails problem, and it's the axis where Portkey's built-in catalogue and LiteLLM's DIY approach genuinely diverge. Match the comparison to the actual risk you're managing rather than the length of either vendor's feature list. For the category explainer that lays out what a gateway is supposed to do in the first place, see our LLM gateway guide.

Where llm11 fits

llm11 solves an adjacent but different problem from both of these. It's a router: one endpoint that sends each request to the cheapest model in a pool capable of handling it, then runs a verification pass on the response, schema and groundedness checks always, heavier checks on requests that earn them, escalating to a stronger model once if a check fails. Portkey and LiteLLM both move your request to a model and, in Portkey's case, screen it against guardrail rules on the way in or out. Neither one judges whether the answer that came back was actually correct once it clears those rules; that's a fundamentally different check than "does this response contain PII" or "does this look like a jailbreak attempt." If a request needs both, guardrail screening and answer verification, they're complementary layers rather than substitutes for each other. Our own gateway page covers how the routing and verification pass work end to end if that's the gap you're trying to close, and the wider comparison hub lines up several adjacent products, gateways, routers, and eval platforms, at once.

Next step

If guardrails, virtual keys, and caching are the specific reasons you're evaluating a gateway rather than model breadth alone, trial Portkey's dashboard against a real workload before committing to build the equivalent yourself in LiteLLM. If you're already committed to self-hosting for infrastructure or compliance reasons, start from the deeper LiteLLM comparison and budget the guardrails and caching work as its own line item rather than assuming it's free just because the proxy itself is.

Frequently asked questions

Does Portkey require using its hosted platform, or can I self-host it?

The core AI Gateway component is open source and can be self-hosted, so you can run the routing and guardrails logic on your own infrastructure. The dashboard, managed logging, and account layer are part of the hosted product, so a fully self-hosted deployment gives you the gateway mechanics without that managed layer.

Can LiteLLM do guardrails and caching at all?

Yes, through its hooks, callbacks, and caching integrations, but these are configuration you write and maintain yourself rather than a built-in catalogue you select from a dashboard. Whether that gap matters depends entirely on how much guardrails engineering your team is prepared to own.

Is Portkey more expensive than LiteLLM?

LiteLLM the software is free; you pay only for the infrastructure you run it on and your own engineering time. Portkey is a paid hosted product on top of that same provider billing, so the real comparison isn't the invoice, it's whether the guardrails, virtual keys, and caching Portkey provides out of the box are worth more to your team than the engineering hours needed to build equivalents around LiteLLM.

Which one supports more model providers?

Portkey's own materials cite over 1,600 models, while LiteLLM's cite over 100 providers; these are different units (models versus providers) counted by each vendor differently, so they aren't directly comparable numbers. Check both vendors' current provider lists against the specific models your application actually needs rather than comparing headline counts.