The LLM-gateway you pick in July 2026 is not the one you'd have picked in January, because four of the options moved under you. TensorZero shut down. Helicone was acquired by Mintlify and slid into maintenance mode. Palo Alto Networks announced its intent to acquire Portkey. And LiteLLM — the default everyone reaches for — shipped malware to PyPI. A market that looked settled six months ago is a different map now, and the thing that changed the math is a Go-based newcomer called Bifrost.
Here's the decision, starting with the news that forces it.
What actually happened in 2026#
- LiteLLM was compromised. In March 2026, versions 1.82.7 and 1.82.8 landed on PyPI carrying a malicious
.pthpayload: a credential harvester, a Kubernetes lateral-movement toolkit, and a persistent systemd backdoor. The project logged multiple security advisories across the year. LiteLLM isn't malicious software — butpip install litellmstopped being something you do without pinning and verifying. - Portkey got acquired. On April 30, 2026, Palo Alto Networks announced its intent to buy Portkey (~$140M per its 10-Q) to serve as the AI Gateway for its Prisma AIRS security platform. Portkey also open-sourced its gateway core (Apache-2.0) in March, so you can self-host the routing and guardrails regardless.
- The field thinned. TensorZero shut down; Helicone froze. Two options that were on shortlists in January are no longer live choices.
That churn is the reason the boring "which gateway" question got interesting.
The features already converged — so stop comparing them#
All three of the survivors do the same core things: an OpenAI-compatible API over many providers, automatic fallbacks and load balancing, semantic caching, budget and spend controls, and MCP support. If you build a feature-comparison spreadsheet, the columns come out nearly identical. That's the tell. When everyone ships the same feature list, the decision drops down a layer — to what the proxy is actually made of.
"Which gateway?" has quietly become "which language do you trust in your hot path, and which vendor is still standing?"
The real axis: Go vs Python in your hot path#
A gateway is a thin proxy that sits in front of every model call. Its overhead is a tax you pay on every request, so the runtime substrate matters more than any feature.
- LiteLLM is Python: interpreted, bounded by the GIL, heavier under concurrency. Wonderful for prototyping; it strains as a high-RPS hot-path proxy.
- Bifrost (maximhq/bifrost, Apache-2.0) is Go: compiled, goroutine concurrency, built to be a proxy and nothing else. On the same instance it reports ~9.5x higher throughput, ~54x lower P99 latency, and ~68% less memory than LiteLLM, with ~11µs of gateway overhead at 5,000 RPS. Its "50x faster than LiteLLM" headline is the per-request overhead figure; treat vendor benchmarks with the usual salt, but the architectural gap — compiled vs interpreted in the hot path — is real and not a tuning artifact.
- Portkey's core is also Go-based and now Apache-2.0, so it competes on the runtime axis too — with production-safety features as its differentiator.
Migrating is a base-URL swap#
Because all three are OpenAI-compatible, moving between them is a configuration change, not a rewrite. If you point an OpenAI client at LiteLLM today:
from openai import OpenAI
client = OpenAI(base_url="http://localhost:4000", api_key="sk-litellm")
then trialing Bifrost is the same client with a different base URL:
from openai import OpenAI
# Bifrost speaks the OpenAI API — same SDK, new endpoint
client = OpenAI(base_url="http://localhost:8080/v1", api_key="sk-bifrost")
That near-zero switching cost is what makes the runtime axis actionable: you can benchmark the same traffic through each proxy on your own box and read the latency and memory numbers yourself before committing.
The decision#
- Prototyping, maximum provider breadth → LiteLLM. Still the fastest way to reach 100+ providers. Pin exact versions, verify hashes, run it with least-privilege keys, and keep it off your most sensitive path after March.
- Production safety, compliance, guardrails → Portkey. PII redaction, jailbreak detection, and audit trails built into the gateway layer, on an Apache-2.0 self-hostable core. Factor in that the managed roadmap now points at Palo Alto's security platform.
- Critical-path, high-RPS, cost-sensitive infrastructure → Bifrost. When the gateway is on the hot path and throughput, tail latency, or memory are real constraints, a compiled Go proxy is the answer, and this is the one whose entire reason to exist is being fast.
The larger point is that gateways stopped being a feature race and became an infrastructure decision. The winner isn't the one with the longest feature list — every survivor has the same list. It's the one whose runtime you'd trust in your hot path and whose vendor you expect to still be there next quarter. In 2026, that question has a much shorter list of good answers than it did in January.



