LLM Gateway Software: The Short Answer

LLM gateway software sits between your application and one or more model providers, giving you a single endpoint that handles routing, failover, caching, per-team budget enforcement and audit logging. The options enterprises shortlist in 2026 are LiteLLM as the open-source standard, Portkey for managed routing with guardrails attached, Kong AI Gateway for organisations already running Kong, Cloudflare AI Gateway for edge caching with near-zero setup, Helicone for cost visibility, and Vercel AI Gateway for teams on the Vercel AI SDK. Nearly all expose an OpenAI-compatible endpoint, so switching is a base URL change rather than a rewrite.

You need a gateway at the point where three things become true at once: you call more than one model provider, someone asks what a given team spent last month, and an auditor wants a record of what was sent to an external API. Before that, a gateway is overhead. After it, building the same controls into application code is the expensive path.

The category matured quickly. Static fallback, meaning try provider B when provider A errors, is now table stakes across every option. The differentiation moved to cost-weighted and quality-aware routing, governance depth, and hosting model.

LLM gateway software compared

Hosting model is the first filter. Data residency requirements eliminate managed edge gateways before any feature comparison begins.

GatewayHostingStrongest atBest fit
LiteLLMSelf-hosted, open sourceBroadest provider coverage, virtual key budgeting, Docker deploymentTeams running self-hosted models alongside cloud APIs
PortkeyManaged, limited self-hostDeclarative routing rules, semantic caching, guardrails and evaluation in the same layerProduction teams wanting routing and quality controls together
Kong AI GatewaySelf-hosted or managedSame operational model as existing Kong API managementEnterprises where Kong is already the API gateway standard
Cloudflare AI GatewayManaged edgeEdge caching with minimal setupTeams already on Cloudflare
HeliconeProxy, cloud or self-hostedMulti-provider cost visibility, one-line installCost tracking as the primary driver
Vercel AI GatewayManagedTightest fit with the Vercel AI SDKApplications already deployed on Vercel

Vendors: this comparison is reviewed and republished each quarter. If a detail about your product is wrong or out of date, send us the correction and we will fix it. If you build in this category and think your product belongs on the list, tell us about it here. We review submissions on merit and disclose any paid placement on the page.

Gateway-by-gateway breakdown

The six below cover most production shortlists. What separates them is less the feature matrix than who operates them and where they run.

LiteLLM

LiteLLM is the dominant open-source AI gateway and the default choice for teams running self-hosted models alongside cloud APIs. It supports a very wide provider set behind an OpenAI-compatible protocol, ships virtual key budgeting and a dashboard, and deploys via Docker. Because it is open source with no per-request markup, cost at scale is your infrastructure cost rather than a vendor's margin. The trade-off is that reliability is yours to engineer: there is no SLA behind it, and high-availability deployment, upgrades and monitoring are your team's work.

Portkey

Portkey's configuration model is its strongest production feature. Primary provider, fallback chain on error or latency threshold, semantic caching with embedding-based lookup and request transformation between provider schemas all become declarative gateway configuration rather than application-layer code. It also folds guardrails and built-in evaluators into the same layer, and evaluation results can feed routing decisions, which reduces the separate experiment infrastructure teams otherwise build for A/B tests across providers. Pricing is a free tier plus usage-based production tiers. The trade-off is that it runs primarily as managed SaaS with limited self-hosting, which rules it out for some residency requirements.

Kong AI Gateway

Kong AI Gateway extends Kong's established API management platform into AI traffic. For an enterprise already running Kong, that means the same operational model, the same observability pipeline and the same security controls, which is a genuine advantage no greenfield tool can match. Identity-provider-backed auth on every route is available, which matters when the security team requires it uniformly. The honest weakness is that Kong is heavy to operate without existing Kong infrastructure, and some enterprise controls including PII redaction and SSO sit behind a paid licence. For teams not already on Kong, LiteLLM is faster to stand up with lower operational overhead.

Cloudflare AI Gateway

Cloudflare AI Gateway is the near-zero-setup edge option, strongest on caching and best suited to teams already on Cloudflare. Setup is minimal and the edge footprint keeps latency low for geographically distributed users. Governance depth is thinner than Portkey, Kong or TrueFoundry, so it fits better where cost and latency are the drivers than where compliance is.

Helicone

Helicone leads on cost visibility and installs in one line, which makes it the fastest way to answer the question of where LLM spend is actually going. It can run self-hosted. Many teams adopt it as a gateway and cost layer while running a separate platform for quality tracing, since proxy-level visibility is coarser than SDK-level instrumentation.

Vercel AI Gateway

Vercel AI Gateway is the tightest fit for applications already built on the Vercel AI SDK, where routing and provider abstraction line up with the framework rather than sitting beside it. Outside that stack there is little reason to prefer it, which is a clean and honest boundary.

What a gateway actually buys you

Four capabilities justify the hop. Everything else is packaging.

Failover that is configuration, not code

Provider outages are not hypothetical, and handling them in application code means every service implements its own retry logic slightly differently. Portkey's declarative configuration turns primary-provider and fallback-chain behaviour into gateway config, which is where it belongs. Failover on latency threshold, not just on error, is the version worth having.

Caching

Exact-match caching is straightforward. Semantic caching, where a near-identical question hits the cache rather than the model, is where the meaningful spend reduction sits, and it is also where correctness risk enters. Cache a support answer too aggressively and users get a stale response with confidence. Set the similarity threshold deliberately and measure it against real traffic.

Per-team budget enforcement

Virtual keys with spending caps are the single most requested feature once finance notices the bill. LiteLLM ships this in the open-source distribution, which is a large part of why it became the default self-hosted choice.

Governance and audit

Prompt and response masking, retention limits and RBAC are what make a gateway acceptable to a security review. Portkey, Kong and TrueFoundry lead on this dimension. Teams operating under strict controls should settle these requirements alongside their broader cloud and DevOps architecture rather than treating the gateway as an isolated component.

A gateway does not make your LLM application cheaper. It makes the cost visible enough that someone can act on it.

How to choose an LLM gateway

  1. Settle hosting first. Strict data residency, GDPR obligations or air-gapped environments point to LiteLLM, Portkey self-hosted or Kong. Everything managed drops out immediately.
  2. Match to the stack you already run. If Kong is your API gateway, Kong AI Gateway inherits the operational model, the observability pipeline and the security controls you have already built. Greenfield deployments without that commitment are usually better served elsewhere.
  3. Separate routing from failover. Static fallback is universal. Cost-weighted or quality-aware routing, which actively moves traffic to a cheaper or better model per request, is a genuine differentiator and a smaller field.
  4. Check governance before routing real traffic. Verify per-team budgets, virtual keys, masking and retention limits at evaluation time, not after the first audit finding.
  5. Decide whether the gateway is also your observability layer. It can be, but proxy-level traces are coarser than SDK-level ones. Most teams pair a gateway with a dedicated tracing platform.

An OpenAI-compatible endpoint is the portability guarantee. Because nearly every 2026 gateway exposes one, switching costs stay low as long as you avoid depending on any single vendor's proprietary extensions. Treat provider-specific features as a deliberate trade, not a default.

Where Xylity fits

Standing up a gateway is a week of work. Deciding routing policy, cache thresholds, budget hierarchy and masking rules for an organisation with several teams and a compliance function is considerably more, and it needs someone who has made those calls before and seen what breaks.

Xylity works as a consulting-led contingent talent partner, so this usually looks like adding a specialist to an existing platform team rather than running a parallel project. Curated specialists are typically ready to evaluate within 24 to 48 hours, with an average of 4.3 days to first curated profile, a 92% first-match acceptance rate, and coverage across 20+ technology domains and 22 industries. The common shapes are an AI architect for the policy design and a cloud professional for the deployment and networking side. Where the surrounding application needs building rather than staffing, that runs through LLM application development inside Xylity's AI consulting services.

Stack context matters. Teams routing to OpenAI models alongside self-hosted weights have a different gateway requirement from single-provider deployments, and organisations running inference on Kubernetes often want the gateway inside the cluster rather than at the edge.

Two adjacent pieces worth reading: LLM cost optimisation through token accounting, caching and routing for what to do with the spend data a gateway produces, and choosing between GPT, Claude and Llama for the routing decisions upstream of it.

What is an LLM gateway?

An LLM gateway is a proxy layer between your application and one or more model providers. It exposes a single endpoint, usually OpenAI-compatible, and adds multi-provider routing, automatic failover, caching, rate limiting, per-team budget enforcement and request logging. Adopting one normally requires changing a base URL rather than rewriting application code.

When do I actually need an LLM gateway?

When three things become true together: you call more than one model provider, someone needs per-team spending caps, and you need an audit trail of what was sent to an external API. A single-provider prototype does not need one. A multi-team production deployment will end up rebuilding these controls in application code without one.

Is an LLM gateway the same as an observability platform?

No, though they overlap. A gateway sits in the request path and controls traffic, capturing observability as a side effect at API-call granularity. A dedicated observability platform captures the application's own execution structure, including agent steps and retrieval calls. Most production teams run both and treat the gateway as a control plane rather than the source of truth for quality.

Does semantic caching risk returning wrong answers?

Yes, and the risk is real enough to configure deliberately. Semantic caching serves a stored response when a new request is close enough to a previous one, so an overly loose similarity threshold returns confidently stale answers. Set the threshold against real traffic, exclude anything time-sensitive or user-specific from caching, and monitor cache hits as a quality signal rather than only as a cost saving.

Key takeaway

Decide hosting before features, then match the gateway to the infrastructure your team already operates. Static failover is universal and should not drive the decision. The right LLM gateway software is the one whose governance model survives your security review with the least custom work.

Continue building your understanding with these related resources.

Need Specialists?

4.3-day deployment. 92% acceptance rate.

Start a Conversation →