AI Gateways — LiteLLM, Portkey, Kong AI Gateway, Bifrost
A gateway sits between your apps and your model providers and handles routing, fallback, retries, rate limits, secret references, observability, and guardrails behind one API. The 2026 market splits roughly by scale and posture. **LiteLLM** is MIT-licensed, covers 100+ providers, speaks the OpenAI API, and in Kong's benchmark breaks down around 2000 RPS (8 GB of memory, cascading failures), so it fits Python shops under 500 RPS and dev work. **Portkey** positions itself as a control plane with guardrails, PII redaction, jailbreak detection, and audit trails. It went Apache 2.0 in March 2026, adds 20-40 ms of latency, and charges $49/mo for the production tier. **Kong AI Gateway** builds on Kong Gateway. Kong's own benchmark on the same 12 CPUs has it 228% faster than Portkey and 859% faster than LiteLLM, at $100/model/month (5 models max on the Plus tier), so it suits teams already on Kong. **Bifrost** (Maxim AI) retries with configurable backoff and can fall back to Anthropic when OpenAI returns a 429. **Cloudflare and Vercel AI Gateways** are managed, need no ops, and keep to basic retry. Data residency usually decides self-hosted versus managed, and Portkey and Kong sit in the middle with open-source and optional managed offerings.
Learning Objectives
- Enumerate the seven core gateway features (routing, fallback, retries, rate limits, secrets, observability, guardrails).
- Map four 2026 gateways (LiteLLM, Portkey, Kong AI, Bifrost) to scale ceilings and use cases.
- Cite the Kong benchmark (228% vs Portkey, 859% vs LiteLLM) and explain why it matters for >500 RPS.
- Choose self-hosted vs managed given data residency and ops budget.
The Problem
Your product calls OpenAI, Anthropic, and a self-hosted Llama. Each has its own SDK, error model, rate limit, and auth scheme. You want failover (if OpenAI returns a 429, try Anthropic), one credential store, one place to watch traffic, and rate limits per tenant.
Building that in the app couples every service to every provider. A gateway pulls it into one process with one API, usually OpenAI-compatible, that fans out to the providers behind it.
The Concept
Core features
- Provider routing: OpenAI, Anthropic, Gemini, self-hosted, and others behind one API.
- Fallback: on a 429, a 5xx, or a quality failure, retry somewhere else.
- Retries: exponential backoff with a bounded number of attempts.
- Rate limits: per tenant, per key, per model.
- Secret references: pull credentials from a vault at runtime so the app code holds none.
- Observability: OTel with GenAI attributes (Phase 17 · 13) plus cost attribution.
- Guardrails: PII redaction, jailbreak detection, allowed-topic filters.
LiteLLM: MIT OSS, Python
- 100+ providers, OpenAI-compatible, router config, fallback, basic observability.
- Breaks down around 2000 RPS in Kong's benchmark, with an 8 GB memory footprint and cascading failures under sustained load.
- Best fit: a Python app under 500 RPS, dev and staging gateways, experimental routing.
- Cost: $0 for OSS, and the cloud version has a free tier.
Portkey: the control-plane pitch
- Apache 2.0 OSS as of March 2026. Guardrails, PII redaction, jailbreak detection, audit trails.
- 20-40 ms of latency overhead per request.
- $49/mo for the production tier, which adds retention and an SLA.
- Best fit: regulated industries that want guardrails and observability bundled.
Kong AI Gateway: the scale play
- Built on Kong Gateway, a mature API gateway product (Lua on OpenResty).
- Kong's own benchmark on a 12-CPU equivalent has it 228% faster than Portkey and 859% faster than LiteLLM. Read that as a vendor number, since Kong ran it.
- Pricing: $100/model/month, 5 models max on the Plus tier.
- Best fit: teams already on Kong, past 1000 RPS, willing to pay for a license.
Bifrost (Maxim AI)
- Automatic retries with configurable backoff.
- Falling back to Anthropic on an OpenAI 429 is the canonical recipe.
- A newer, commercial entrant.
Cloudflare AI Gateway and Vercel AI Gateway
- Managed, zero-ops, with basic retry and observability.
- Best fit: JavaScript apps served from the edge on Cloudflare or Vercel.
- Thinner than Kong or Portkey on guardrails and rate limits.
Self-hosted vs managed
Data residency forces the decision. Healthcare and finance default to self-hosting (LiteLLM, Portkey OSS, or Kong). Consumer products default to managed (Cloudflare AI Gateway) or a middle tier (Portkey managed). A hybrid works too: self-host for the regulated tenant and use managed for everyone else.
Latency budget
- LiteLLM: 5-15 ms overhead, typical.
- Portkey: 20-40 ms.
- Kong: 3-8 ms.
- Cloudflare and Vercel: 1-3 ms, thanks to the edge.
Gateway latency adds straight onto TTFT. For a TTFT P99 under 100 ms, pick Kong or Cloudflare. Under 500 ms, any of them fits.
Rate-limit semantics matter
A simple token bucket holds up at moderate scale. Multi-tenant traffic needs a sliding window, a burst allowance, and per-tenant tiering. LiteLLM ships a token bucket, Kong ships a sliding window, and Portkey ships tiered limits.
Gateway, observability, and routing compose
Phase 17 · 13 (observability), 16 (model routing), and 19 (gateways) describe one layer in production. Either pick a tool that covers all three or wire them together with care. Most 2026 deployments split the roles, pairing Helicone (observability) or Portkey (guardrails) with Kong (scale).
Numbers to remember
- LiteLLM: breaks at ~2000 RPS, 8 GB memory.
- Portkey: 20-40 ms overhead, Apache 2.0 since March 2026.
- Kong: 228% faster than Portkey, 859% faster than LiteLLM.
- Kong pricing: $100/model/month, 5 max on the Plus tier.
- Cloudflare and Vercel: 1-3 ms overhead at the edge.
Use It
code/main.py simulates gateway routing with fallback across 3 providers under 429/5xx injection. It reports latency, retry rate, and fallback hit rate.
Ship It
The output here is outputs/skill-gateway-picker.md. Give it your scale, ops posture, compliance needs, and latency budget, and it picks a gateway.
I'd run main.py first and read the table, then the three lines under it. The table shows 100.0% success for every gateway, which is what a 3-provider chain should give over 1000 requests with a fixed seed, so the numbers repeat from run to run. The three lines under it are printed text, not measured output. They give the closed-form success rate for one provider (97%), two in a chain (99.94%, the complement of 0.03 × 0.02), and three (99.997%), and you can check them by hand. The chain in the simulation is OpenAI, then Anthropic, then self-hosted.
My bet is that the latency column is the one worth staring at. Each gateway only adds a fixed overhead (2 ms for Cloudflare up to 30 ms for Portkey) on top of whatever the providers cost, and a failed call is charged at 30% of that provider's base latency. Fallback buys success rate and pays for it in mean latency, which is the trade the Latency budget section is about.
Keep the toy in proportion, though. The overhead numbers are the lesson's typical figures typed in as constants, so the simulator cannot tell you which gateway is faster. The TypeScript port is closer to a real gateway: it checks the API key, applies a per-tenant token bucket by tier, retries with backoff, and walks the fallback chain. If you care about the rate-limit question in the exercises, read that bucket before you pick an algorithm.
Exercises
- Run
code/main.py. Configure fallback from OpenAI→Anthropic→self-hosted. What's the expected hit rate at 5% provider error rate? - Your SLA is TTFT P99 < 200 ms on a 300 ms baseline. Which gateways stay within budget?
- A healthcare customer requires self-hosted + PII redaction + audit. Pick Portkey OSS or Kong.
- Compare LiteLLM vs Kong: at what RPS ceiling should a team migrate?
- Design a rate-limit policy for a multi-tenant SaaS: free tier, trial tier, paid tier. Token-bucket or sliding-window?
Key Terms
| Term | What people say | What it actually means |
|---|---|---|
| Gateway | "API broker" | Process sitting between apps and providers |
| LiteLLM | "the MIT one" | Python OSS, 100+ providers, breaks at 2K RPS |
| Portkey | "guardrails gateway" | Control plane + observability, Apache 2.0 |
| Kong AI Gateway | "the scale one" | Built on Kong Gateway, benchmark leader |
| Bifrost | "Maxim's gateway" | Retries + Anthropic fallback recipe |
| Cloudflare AI Gateway | "edge managed" | Edge-deployed managed gateway, zero-ops |
| PII redaction | "data scrub" | Regex + NER mask before sending to model |
| Jailbreak detection | "prompt injection guard" | Classifier on user input |
| Audit trail | "regulated log" | Immutable record of every LLM call |
| Token-bucket | "simple rate limit" | Refill-based rate limiter |
| Sliding-window | "precise rate limit" | Time-windowed rate limiter; better fairness |