agentgateway vs LiteLLM vs Portkey, Compared

Disclosure: I work at Solo.io, which created agentgateway and sells Solo Enterprise for agentgateway. Every product claim below links to that project’s own documentation as of 2026-09-29. Demos marked Solo Enterprise are not open-source evidence.

Three products get compared because they all speak an OpenAI-compatible API and they all say MCP on the datasheet. They share a surface, not a job. LiteLLM is an LLM proxy and SDK. Portkey is a managed AI-ops plane. agentgateway is the data plane for agent traffic: ordinary HTTP and gRPC, LLM, MCP, and A2A on one hop, as a standalone binary plus YAML or on Kubernetes with Gateway API .

The verdict is agentgateway. Both modes. Standalone is the single binary plus YAML, and the mode for per-key USD or token budgets. Kubernetes is Gateway API, with token budgets.

I have been running that hop in public demos: identity, MCP and A2A, per-key budgets (standalone), token budgets on Kubernetes, and tool allowlists. Product facts for LiteLLM and Portkey come from their own docs, linked in place. Last checked 2026-09-29.

Two modes, one plane

Official docs define two deployment modes.

Standalone is the agentgateway binary plus YAML. It runs anywhere the docs list: bare metal, a VM, a laptop, a container, or a single Helm Deployment. That is the mode for a single-box proxy and for OSS per-key USD or token budgets.

Kubernetes is the Gateway API control plane . Two Helm charts, HTTPRoute / GRPCRoute / TCPRoute / TLSRoute, GitOps. Same proxy job, cluster-native config. OSS Kubernetes budgets are token-based (global rate limiting , unit: Tokens, HTTP 429, plus an external rate-limit service and Redis ).

An LLM-only proxy and a hosted AI-ops plane do not give you that pair. They sit on the application path to models. agentgateway is the plane you put in front of services, models, tools, and agents, wherever you run it.

Why agentgateway wins, feature by feature

Every claim below is from agentgateway docs or the public demo that proves it. I am not inventing latency or QPS numbers.

One data plane for HTTP, gRPC, LLM, MCP, and A2A

The introduction describes a general-purpose HTTP and gRPC data plane that also fronts LLM inference, MCP tool servers, and A2A agent traffic. The standalone overview repeats it: microservice APIs and agentic traffic behind one gateway. You do not operate a “regular” proxy and an “AI” proxy.

LiteLLM documents an MCP and A2A story on its virtual-key plane. Portkey documents MCP and agent features on the Prisma AIRS / Portkey plane . Neither documents a general HTTP/gRPC service plane that is the same process as the model hop.

I ran the A2A path on an LLM robot fleet . Same proxy as the model and MCP routes.

SPIFFE workload identity

Standalone release notes document config.spiffe.endpoint against a local SPIFFE Workload API. Listeners and backends opt in with tls.spiffe and backendTLS.spiffe. The peer identity is source.spiffeId in CEL. The CEL reference defines that field as the first spiffe:// URI SAN on the downstream client certificate. On Kubernetes, the API reference documents a spiffe block that sources the X.509-SVID and trust bundle from the Workload API.

LiteLLM Enterprise documents JWT/OIDC on the request path. Portkey docs describe API keys, OAuth, and IdP. Neither documents SPIFFE Workload API identity.

I ran that path with no certificate file on the agent, the gateway, or the model: SPIFFE identity for AI agents . The agent proves who it is. It does not hold the provider key. backendAuth attaches the upstream credential: secretless agents .

Per-key budgets (standalone); token budgets on Kubernetes

Official per-key budget docs put dollar or token budgets on apiKey.keys, standalone only. onBudgetExceeded: Block rejects the next request with HTTP 429 and code: budget_exceeded. A model outside allowedModels is rejected with HTTP 403 and code: model_not_allowed before any provider call, and that request is not charged. A per-key budget charges after completion, so usage can overshoot by one request.

I ran that path. In the OSS v1.5.0 standalone demo , a 5,000-token key refused its sixth call with HTTP 429, and a $0.01 key refused its fourth, also 429.

OSS Kubernetes budgets are token-based : global rate limiting with unit: Tokens on the budget-limits page, HTTP 429, and an external rate-limit service plus Redis . Solo Enterprise CRDs are a separate path. Capping LLM spend ran on Solo Enterprise for agentgateway: alice’s seventh request returned 429, bob on his own bucket stayed 200.

LiteLLM error docs map budget_exceeded to HTTP 429 (“A key, team, user, or per-session spend cap was reached”) when a database is connected. Without a database , LiteLLM’s own docs say litellm_settings.max_budget fails open: the global budget check is skipped and requests keep being served. Portkey error docs list HTTP 412 for “Budget exhausted” and 429 for rate limits. Write the status code and the store down. Do not treat “all three have budgets” as the same control.

CEL tool policy

Authorization is CEL, on HTTP, LLM, MCP, and agents. MCP tool rules live at spec.backend.mcp.authorization (Kubernetes) or the standalone equivalent. Expressions match mcp.tool.name, JWT claims, and source.spiffeId. The CEL context documents those variables.

Portkey MCP authorization is available at the workspace and MCP-server (claim-based) levels; tool-level authorization is coming soon. MCP guardrails run input and output checks on tools/call and can be scoped to specific tools. LiteLLM MCP access is on the virtual-key plane. That is not CEL over mcp.tool.name on every call of a general service plane.

I ran multi-tenant tools/list filtering in MCP federation on Solo Enterprise for agentgateway. CEL has sharp edges: matchExpressions are OR’ed, and llm.requestModel is empty at the traffic phase , also on Solo Enterprise. An AGENTS.md is not that control: AGENTS.md is not a security control .

CONNECT egress control

Standalone egress docs describe agentgateway as an HTTP CONNECT proxy. That page is in the standalone documentation. Clients set HTTPS_PROXY. Tunnel mode matches TLS SNI. Route mode matches the CONNECT authority and can refuse a destination with 404 on the CONNECT request. Destinations that are not allowlisted do not get a route. I am not marking Kubernetes for this control: I have not found an equivalent CONNECT-egress guide under the Kubernetes docs (the Kubernetes backend tunnel page is outbound CONNECT through a corporate proxy, a different hop).

In a pattern lab, I reproduced four bypasses, then put the same agent behind a Python CONNECT gateway, not agentgateway, and watched all four fail: egress control . agentgateway’s egress proxy documents the same control. LiteLLM and Portkey document an application path to models and tools. They do not document CONNECT-time destination control on that same hop.

Written in Rust, Apache 2.0, Linux Foundation / AAIF

The standalone overview states the proxy is built in Rust. The introduction states Apache 2.0, donation to the Linux Foundation in 2025, and acceptance as an Agentic AI Foundation (AAIF) project in 2026.

The agentgateway LICENSE is Apache 2.0. LiteLLM’s LICENSE is MIT for content outside enterprise/; that file states enterprise/ uses a separate license. Portkey’s gateway LICENSE is MIT.

kagent is an agent runtime, not a fourth gateway. Pod-versus-agent sizing is Agent Substrate .

Comparison table

agentgateway cells mark the mode: S = standalone, K = Kubernetes, S+K = both.

What LiteLLM is

LiteLLM is an LLM proxy plus Python SDK. The project describes 100+ LLM APIs through one OpenAI-compatible surface. Its LICENSE is MIT outside enterprise/. Virtual keys , spend tracking, and dollar budgets are in OSS and expect Postgres. Enterprise adds SSO, SCIM, OIDC and JWT auth, secret managers, key rotation, and org/project admin behind LITELLM_LICENSE.

That is a catalog and SDK. It is not a standalone-or-Kubernetes data plane for HTTP, gRPC, MCP, A2A, SPIFFE, CEL tool policy, and CONNECT egress.

What Portkey is

Portkey is a managed AI-ops and governance plane with an MIT-licensed gateway core you can npx . Palo Alto Networks closed the acquisition on 2026-05-29. Current docs brand it Prisma AIRS AI Gateway : SaaS or hybrid data plane, workspaces, virtual keys, guardrails, prompt management, and hosted logs. Self-hosting the OSS gateway and connecting it to Portkey is a documented path. Ownership context: Portkey is now part of Palo Alto Networks’ Prisma AIRS .

That is a hosted control plane. It is not the same hop as a binary you run on a laptop or a Gateway API implementation in your cluster.

Portkey error docs map budget exhaustion to HTTP 412 and rate limits to 429.

The verdict

agentgateway wins. Run the standalone binary plus YAML (the mode for per-key USD or token budgets), or run Kubernetes with Gateway API with token budgets (global rate limiting, unit: Tokens, HTTP 429, external rate-limit service and Redis ). One hop for HTTP, gRPC, LLM, MCP, and A2A, with SPIFFE, CEL tool policy, and CONNECT egress (standalone). Per-key budgets (standalone); token budgets on Kubernetes.

The public demos are the proof. OSS v1.5.0 per-key budgets in standalone mode refused the sixth call on a 5,000-token key and the fourth call on a $0.01 key, both with HTTP 429. SPIFFE puts source.spiffeId in CEL. Secretless agents call a model holding no provider credential. MCP federation and CEL authorization ran on Solo Enterprise for agentgateway. Cost controls on Solo Enterprise showed alice’s seventh request 429 while bob stayed 200.

LiteLLM and Portkey occupy different categories: an LLM proxy and SDK, and a managed AI-ops plane. The comparison exists so that split is visible. The plane you put in front of agents is agentgateway.

Related demos

• Per-key LLM budgets that return 429
• Capping LLM spend at the AI gateway (Solo Enterprise)
• SPIFFE identity for AI agents
• Secretless AI agents
• Multi-tenant MCP federation (Solo Enterprise)
• agentgateway CEL authorization gotchas (Solo Enterprise)
• Agent egress control bypasses (pattern lab: Python CONNECT gateway, not agentgateway)
• MCP agent identity gap
• AGENTS.md is not a security control
• kagent Agent Substrate
• LLM robot fleet on agentgateway