Best 7 Open Source AI Gateways in 2026

Originally published May 13, 2026. Updated Q2 2026.

Between March 3 and April 30, 2026 three of the seven incumbents in the open source AI gateway category shipped breaking events. Helicone was acquired by Mintlify, LiteLLM was compromised on PyPI by the TeamPCP threat actor exfiltrating AWS, GCP, and Azure credentials at install time, and Portkey was acquired by Palo Alto Networks.

This guide ranks the seven open source AI gateways production teams should actually consider in 2026, scored on license clarity verified against the upstream LICENSE file, acquisition independence, supply chain hygiene, and 16 capability dimensions a throughput chart can’t resolve.

TL;DR: The 7 Best Open Source AI Gateways for 2026

Future AGI Agent Command Center is the strongest single open source pick for production LLM workloads in 2026.

It ships an OpenAI compatible drop in, 100 plus providers, 18 plus built in guardrail scanners, exact plus semantic caching, per virtual key budgets, MCP plus A2A protocol support, and OpenTelemetry native cost metrics. One Apache 2.0 single Go binary you can self host with no pending acquisition.

License clarity verified against the upstream LICENSE file, acquisition independence, and supply chain hygiene now sit ahead of raw throughput as the 2026 procurement axes. Three of the seven incumbents shipped breaking events between March and April 2026.

The 7 Best Open Source AI Gateways in 2026

The seven open source AI gateways below cover every production shape teams ship in 2026: two Apache 2.0 Go binaries (Future AGI ACC, Bifrost), one MIT Python proxy (LiteLLM), one MIT gateway core plus dashboard (Portkey), one Apache 2.0 open core (Kong), one service mesh filter (Envoy AI Gateway), and one adapter pattern tool in maintenance (Helicone).

The eight superlatives read first, then the seven tool shortlist with the one line reason each made the cut.

Two clarifications keep this list honest. OpenRouter isn’t in the seven because it’s closed source: a managed SaaS proxy across 400 plus models on 60 plus providers, with a 5.5 percent platform fee on top of provider pass through pricing and no self hostable artifact.

LLMGateway.io isn’t in the seven because it ships under AGPLv3, a network clause copyleft license that requires any commercial product exposing it over a network to publish its own source under AGPLv3.

That single license fact is a procurement disqualifier for most enterprise buyers, regardless of the project’s feature set. Both projects are covered in the honorable mentions further down.

Helicone keeps the 6th slot because existing users need a structured migration plan, not because it’s the right greenfield procurement in 2026.

Every license cell above was verified by reading the LICENSE file in the canonical repository at publication time. Marketing copy that calls LiteLLM “Apache 2.0” or the hosted gateway “Apache 2.0” is wrong; both ship under MIT.

How Did We Score Open Source AI Gateways in 2026?

We used the Future AGI Production Gateway Scorecard, a seven dimension rubric we extended for 2026 with three open source specific overlays: license class verified against the upstream LICENSE file, acquisition status, and supply chain hygiene. Most gateway listicles in 2026 still score on raw throughput and stop there.

A 2026 procurement decision turns on three axes a throughput chart can’t resolve: which OSI approved license the source actually ships under, whether the project entered Q2 under a pending acquisition, and whether the project publishes Sigstore signed builds with an SBOM and a documented incident response posture.

The three open source overlays sit on top of these seven dimensions, and in 2026 they often outrank them.

We don’t publish a single composite score. The right priority depends on the buyer profile. The decision matrix further down maps buyer profiles to picks, which is the scoring that ships.

All throughput numbers cited here (about 29,000 req/s with P99 21 milliseconds and guardrails on for Future AGI Agent Command Center; 11 microsecond P50 at 5,000 RPS for Bifrost) are vendor published on their own harnesses on t3.xlarge hardware. An independent reproduction CSV across all seven tools is the planned 2026 deliverable.

Open Source Is Not Always the Same in AI Gateways in 2026

Open source AI gateways in 2026 fall into four license classes verified against the upstream LICENSE file, and treating them as interchangeable is the most common procurement mistake. The class decides what happens to your production stack on the day a vendor pivots, is acquired, or ships a malicious build.

The four classes are: Apache 2.0 OSI permissive (Future AGI Agent Command Center, Bifrost, Kong core, Envoy AI Gateway, Helicone), MIT OSI permissive (LiteLLM, Portkey gateway core), AGPLv3 OSI copyleft with network clause (LLMGateway.io), and not open source (OpenRouter).

Open core sits underneath: Kong’s AI Semantic Cache, AI Semantic Prompt Guard, AI Anthropic Advanced, AI RAG Injector, and AI Proxy Advanced plugins are gated by Kong Enterprise.

The operational consequences differ in three concrete ways. The fork option only exists under Apache 2.0 or MIT; AGPLv3 forks remain copyleft and inherit the network clause obligations, and OpenRouter can’t be forked at all because the source isn’t published.

Air gapped deployment is straightforward under Apache 2.0 and MIT, restricted in shape under AGPLv3 (the network clause still applies if the air gapped tenant exposes the gateway over a network, even an internal one), and unavailable under OpenRouter.

Supply chain hygiene is a separate axis from license class. Apache 2.0 single binary gateways with Sigstore signed artifacts cleared the March 2026 LiteLLM PyPI bar trivially. Pip installed Apache 2.0 or MIT gateways need commit pinning, Sigstore signature verification, and a private mirror to clear the same bar.

The AGPLv3 callout matters even when the project is otherwise excellent. Any commercial product that exposes LLMGateway.io over a network must release its own source under AGPLv3. For most enterprise procurement teams this is a structural disqualifier, regardless of the project’s feature set or maintainer quality.

The Deepest Open Source AI Gateway Feature Matrix in 2026

Across the seven open source gateways below, Future AGI Agent Command Center leads on combined provider breadth, guardrail depth, MCP plus A2A coverage, observability, license clarity, acquisition independence, and supply chain hygiene structural posture.

Bifrost wins on published throughput. Portkey wins on managed dashboard polish if the Palo Alto integration risk is acceptable. LiteLLM wins on Python first ergonomics if you commit pin and verify Sigstore signatures.

The 17 dimension matrix below is the single thing most open source gateway listicles on the SERP are missing. Maxim caps at 5 to 6 columns, llmgateway.io’s table is 4, and none ship license clarity, acquisition status, and supply chain hygiene next to the feature list.

The shape of the matrix is the shape your procurement decision will be. Nobody wins every column. The four columns that matter most for open source in 2026 (license clarity, acquisition status, supply chain hygiene, MCP support) are where the field separates.

Future AGI Agent Command Center Leads Open Source AI Gateways in 2026

Future AGI Agent Command Center leads the 2026 list because it’s the Apache 2.0 gateway shipping OpenAI compat drop in, 100 plus providers, 18 plus guardrail scanners, MCP plus A2A, exact plus semantic caching, per virtual key budgets, and OTel native cost metrics. One Go binary, self hostable, no pending acquisition.

Every other open source gateway forces you to wire two or three of these layers together. Agent Command Center attaches them at the same network hop, under one Apache 2.0 license, in one artifact, with no install time code execution path.

Best for: Engineering teams already on OpenTelemetry that want OpenAI compat drop in, 18 plus built in guardrails, MCP plus A2A coverage, per virtual key budgets, and cost plus token metrics in their existing stack, without rewriting SDK code, accepting acquisition risk, or taking on a Python .pth install attack surface.

Key strengths:

• OpenAI compatible drop in: change base_url to https://gateway.futureagi.com/v1, keep existing SDK code unchanged.
• 100 plus providers (OpenAI, Anthropic, Gemini, Bedrock, Azure OpenAI, Cohere, Groq, Together, Fireworks, Mistral, DeepInfra, Perplexity, Cerebras, xAI, OpenRouter, Ollama, vLLM, LM Studio, TGI), per the Future AGI repository README.
• 18 plus built in guardrail scanners (PII, prompt injection, content moderation, secret detection, hallucination, topic restriction, language detection, data leakage prevention, blocklist, system prompt protection, tool permissions, input validation, MCP security, custom expression rules, webhook BYOG, Future AGI Evaluation) plus 15 third party adapters (Lakera Guard, Presidio, Llama Guard, AWS Bedrock Guardrails, Azure Content Safety, Pangea, Aporia, Enkrypt AI, HiddenLayer, DynamoAI, IBM AI, Zscaler, Crowdstrike, Lasso, GraySwan). The MCP Security scanner is directly relevant after CVE-2026-30623.
• 15 routing and reliability strategies combined (six primary routing: Round Robin, Weighted, Least Latency, Cost Optimized, Adaptive, Race; six reliability features: failover, retries, circuit breaking, model fallbacks, complexity based, provider lock; three load balancing modifiers). Documented at docs.futureagi.com/docs/command-center.
• Exact caching (in memory or Redis) and semantic caching (in memory, Qdrant, Pinecone) with per request override headers for force refresh, TTL, and namespace.
• Per key, per virtual key, per model, and per time window budgets; rate limits; shadow experiments; tag based tenant enforcement.
• Prometheus metrics on /-/metrics (cost, tokens, cache hits, cache misses, request counts by provider and status) plus OTLP trace export, feeding Grafana and evals through span_id, per docs.futureagi.com/docs/observe.
• MCP plus A2A protocol support inside the gateway, in the same Apache 2.0 binary; MCP Security shipped as one of the 18 plus scanners.
• Apache 2.0 single Go binary; Docker, Kubernetes, AWS, GCP, Azure, air gapped, or on prem. Air gappable single artifact, container digest pinnable.

Limitations:

• Full execution tracing for agents is currently an “In Progress” roadmap item on the public roadmap in the Future AGI GitHub repo and is rolling out alongside the existing gateway-side OpenTelemetry trace export.

Where most gateways stop at routing, Agent Command Center attaches per virtual key budgets, exact plus semantic caching, 18 plus built in guardrail scanners, MCP Security, and an OTel native cost meter at the same network hop, under one Apache 2.0 license, so a runaway agent loop hits the budget wall before the bill arrives.

The structural advantage matters most after the March 2026 LiteLLM PyPI compromise. The TeamPCP attack exploited Python install time code execution via __init__.py. A single static Go binary has no .pth install path and no install time code execution surface in the same shape.

The attack vector that compromised LiteLLM 1.82.7 and 1.82.8 simply doesn’t exist for a Go binary. This is a property of the language and packaging, not a polemic.

Use case fit: Strong for OpenTelemetry first teams, multi tenant SaaS, fintech with per customer budget enforcement, air gapped regulated environments, and platform teams wanting gateway plus evals plus tracing in one Apache 2.0 stack. Less optimal when a managed dashboard out of the box is required and the team has no Grafana footprint.

Pricing and deployment: Apache 2.0 single Go binary. Cloud endpoint at https://gateway.futureagi.com/v1 or self host (Docker, Kubernetes, air gapped). Quickstart at docs.futureagi.com/docs/command-center.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["FAGI_API_KEY"],
    base_url="https://gateway.futureagi.com/v1",
)

# Existing OpenAI SDK code unchanged from here.
response = client.chat.completions.create(
    model="anthropic/claude-3-5-sonnet",
    messages=[{"role": "user", "content": "Summarise this support ticket."}],
)

Verdict: The strongest single open source pick when the 2026 buying constraint is Apache 2.0 plus OpenAI compat plus 18 plus guardrails plus MCP plus A2A plus OTel native cost metrics in one Go binary, with no pending acquisition and no install time attack surface. Teams wanting a managed dashboard before infrastructure work should evaluate Portkey alongside.

LiteLLM After the March 2026 PyPI Compromise and the MCP STDIO CVE

LiteLLM is the Python first AI gateway that broke open the multi provider unified API category. It’s MIT licensed (verified against the LICENSE file in the BerriAI/litellm repository, not Apache 2.0 as some marketing copy claims), with 100 plus providers and the broadest open source community in the category.

After the March 24, 2026 PyPI supply chain compromise the answer is “yes, with commit pinning, Sigstore signature verification, and credential rotation,” not “yes, by default.”

Berri AI’s response to the incident has been textbook, and the project deserves the credit for it. The post incident recovery posture is the strongest in the category right now.

Best for: Python first teams already running a FastAPI or uvicorn surface that want the broadest provider list under MIT, that pin commit hashes, verify Sigstore signatures, and accept the post incident install path audit overhead.

Key strengths:

• Broadest provider coverage of any single project on this list (100 plus providers, the deepest community across the open source gateway category).
• MIT license verified against the LICENSE file; trivial to fork or audit. Clean release at v1.83.0 and later restores supply chain hygiene.
• Sigstore signed nightly builds starting from v1.83.0-nightly, verifiable via the Rekor transparency log; the strongest published supply chain hygiene posture in the category as of May 2026.
• Virtual keys with per key budgets and budget alerts; Python observability stack native via Prometheus and OpenTelemetry middleware.
• Active maintainer community; easy to extend with custom adapters via Python.

Limitations:

• March 2026 PyPI supply chain compromise (March 24, 2026). Versions 1.82.7 and 1.82.8 were published by the TeamPCP threat actor after a stolen Berri AI maintainer PyPI token. The malicious payload injected install time code via the package __init__.py and setup.py flow that exfiltrated AWS, GCP, and Azure credentials from install hosts (CI runners, dev laptops, container build hosts) by reading common credential paths. Both versions have been yanked. Clean fix release is v1.83.0. See the Datadog Security Labs writeup of the LiteLLM PyPI compromise.
• CVE-2026-30623 (April 15, 2026, MCP STDIO command injection). Part of the broader OX Security disclosure covering 14 related CVEs across the MCP ecosystem. Anthropic confirmed the STDIO transport behavior is by design and declined to modify the protocol, which made the LiteLLM fix at v1.83.7-stable (or nightlies from v1.83.6-nightly) a procurement signal rather than just an engineering patch. The post patch allowlist of commands is: npx, uvx, python, python3, node, docker, deno, gated by the PROXY_ADMIN role. See The Hacker News writeup of the Anthropic MCP design vulnerability.
• Python runtime: throughput tops out earlier than Go binary alternatives under GIL contention; teams at high concurrency run several proxy instances behind a load balancer.
• Semantic caching exists but is less mature than Portkey’s; tuning is more manual.

Berri AI’s post incident posture (worth crediting in procurement):

• Engaged Mandiant for incident response, per the public LiteLLM security advisory.
• Migrated to a hardened CI/CD v2 pipeline with token rotation, 2FA enforcement on PyPI release accounts, and provenance attestations.
• Started Sigstore and cosign signing of nightly and stable builds at v1.83.0-nightly, verifiable via the Rekor transparency log.
• Published a public post mortem on docs.litellm.ai.

Use case fit: Strong for Python first teams and ML platform teams already managing Python services. Less optimal when throughput exceeds 10,000 req/s, a managed runtime forbids commit pinned dependencies, or the procurement requirement is a single static binary with no install time attack surface in any shape.

Pricing and deployment: MIT licensed. Install with pip install 'litellm>=1.83.0' --require-hashes against a private mirror, or pull the container image with Sigstore signature verification. Verify any nightly or stable build through Rekor before promoting to production.

Verdict: Still the broadest provider coverage on the list with the strongest published post incident supply chain hygiene posture in the category. The two 2026 incidents shift it from “default pick” to “pin commits, verify Sigstore, audit installs, rotate any credential reachable from an affected host.”

Portkey After the Palo Alto Networks Acquisition

Portkey is the strongest pick when you want a managed cost dashboard plus a self hostable MIT gateway core, with the largest adapter library on the cost path among open core options.

It’s what most production teams reach for when “we need spend control next week” is the brief. The Palo Alto Networks acquisition now reshapes what “still open source” means for the next 12 months.

The gateway core in the Portkey-AI/gateway repository ships under MIT (verified against the LICENSE file, despite some marketing copy referring to “Apache 2.0”); the managed control plane is consolidating under Palo Alto’s enterprise stack.

Best for: Multi tenant SaaS or internal multi product platforms that need a fine grained per customer budget hierarchy plus a usable cost dashboard plus the largest provider adapter library, and that accept the Palo Alto Networks acquisition integration risk announced April 30, 2026 (Palo Alto Networks press release on the Portkey acquisition).

Key strengths:

• Exact plus semantic caching with TTL and similarity threshold tuning out of the box.
• Per key, per virtual key, per model, per time window budgets; the most fine grained native dashboard hierarchy on the list.
• Large adapter library (250 plus providers, including private OSS deployments).
• Usable native dashboard for cost attribution by tenant, feature, and route.
• MIT gateway core; teams self host the core and run the control plane in Portkey cloud (now under Palo Alto Networks).

Limitations:

• Palo Alto Networks closed the acquisition on April 30, 2026; the gateway roadmap is merging into Prisma AIRS, and standalone gateway status is pending through fiscal 2026. Non Palo Alto buyers face integration risk; existing Palo Alto buyers gain an accelerator.
• Conditional routing two segment key limitation. Portkey’s conditional routing conditions use a two segment key path (for example metadata.tier); nested JSON paths beyond two segments aren’t supported. Teams routing on deeply nested customer metadata work around this by flattening the metadata at the SDK layer.
• Observability is dashboard first; OpenTelemetry export exists but is less first class than the native dashboard.
• Supply chain hygiene posture isn’t publicly disclosed. No Sigstore signing on the release flow, no public SBOM, no external audit engagement on record as of May 2026; the Palo Alto integration may add audit cadence over time.
• Gateway core is MIT and self hostable; the closed managed control plane is the cost dashboard. Check whether the open source core covers your air gapped requirements before greenfield procurement.

Use case fit: Strong for multi tenant SaaS, fintech with per customer cost attribution, and platform teams that accept the acquisition risk and the two segment routing key limitation. Less optimal when cost data must flow into an existing OTel collector and Grafana stack, or when air gapped without the managed control plane is the requirement.

Pricing and deployment: MIT gateway core (self hosted), commercial cloud control plane under Palo Alto Networks. Install with docker run portkeyai/gateway or via the Helm chart.

Verdict: Most mature budget hierarchy plus managed dashboard in 2026, with acquisition risk priced in. The next 12 months will tell whether the standalone product survives the Prisma AIRS merger and whether the gateway core stays MIT under Palo Alto stewardship.

Kong AI Gateway for Existing Kong Deployments

Kong AI Gateway is the AI plugin layer on top of Kong Gateway, the most widely deployed open source API gateway in production. It’s the strongest pick when your team already runs Kong for north south API traffic and wants to extend the same governance surface to LLM egress.

The core ships Apache 2.0 from the Kong/kong repository; the deeper AI feature surface is gated by Kong Enterprise.

Best for: Platform and infrastructure teams already running Kong as the API gateway for REST, GraphQL, and gRPC traffic that want a single governance plane across both API and LLM workloads.

Key strengths:

• Apache 2.0 open source core; mature Docker, Kubernetes, AWS, GCP, Azure, and on prem deployment patterns.
• Multi LLM routing across OpenAI, Anthropic, Gemini, Bedrock, Azure AI, Databricks, Mistral, Hugging Face, and more via the ai-proxy plugin.
• Prompt and response transformation plugins for input output filtering at the gateway layer.
• MCP gateway support plus shared rate limiting and observability surface across the broader Kong ecosystem.
• Largest installed base of any API gateway; existing Kong operational skills carry over.
• Kong Enterprise build pipeline ships container digest pinning, SBOM, and a SOC 2 audit posture on Enterprise builds; OSS edition inherits a subset.

Limitations:

• Open core: the deeper AI feature surface lives behind Kong Enterprise. Specifically AI Semantic Cache, AI Semantic Prompt Guard, AI Anthropic Advanced, AI RAG Injector, and AI Proxy Advanced are Enterprise gated. The pure Apache 2.0 core ships routing and transformations, not the full marketed surface.
• Lua plus Go plugin runtime adds operational complexity for teams that have never operated Kong.
• Plugin layered on the API gateway lineage; greenfield teams without Kong pay setup overhead a single binary gateway avoids.
• Built in guardrail depth on the OSS edition is thin compared to Future AGI Agent Command Center’s 18 plus scanners.

Use case fit: Strong for platform teams already running Kong and multi protocol gateways serving both API and LLM traffic. Less optimal for greenfield teams where a single binary alternative has a faster first week and where the Enterprise license dependency for semantic caching, advanced AI analytics, and the deeper compliance plugin set is a procurement constraint.

Pricing and deployment: Apache 2.0 open source core; Kong Enterprise for advanced AI features. Install with helm install kong/kong or via Docker Compose.

Verdict: Right pick if Kong is already the API gateway in your stack and you want the AI surface in the same control plane, with the open core caveat surfaced explicitly: semantic caching and the deeper compliance plugin set are Enterprise gated, not in the Apache 2.0 layer.

Envoy AI Gateway for Kubernetes Native Production

Envoy AI Gateway is the newest entrant on the list (v0.5 in May 2026), built on Envoy Proxy, the foundation of Istio and most service mesh deployments. The source ships Apache 2.0 from the envoyproxy/ai-gateway repository under the Envoy AI Gateway SIG.

It’s the right call when your team already runs Envoy or Istio and wants the LLM egress surface to live inside the same service mesh primitives.

Best for: Kubernetes shops already running Envoy or Istio that want LLM routing, rate limiting, and observability as a service mesh extension rather than a separate gateway.

Key strengths:

• Apache 2.0, built on Envoy Proxy, which already runs in most service mesh production deployments. Inherits Envoy’s SBOM, build provenance, and security audit lineage.
• OpenAI compatible API with multi provider routing across OpenAI, Anthropic, Bedrock, Vertex AI, and others.
• MCP gateway support with OAuth authentication and fine grained CEL based authorisation (v0.4 and v0.5).
• Single millisecond range overhead at the Envoy filter layer; integrates with Istio observability (Prometheus, OpenTelemetry).
• Kubernetes Gateway API native; fits the routing primitives Kubernetes shops already use.

Limitations:

• Early stage (v0.5 as of May 2026); provider list is narrower (approximately five plus) than Bifrost (23 plus) or LiteLLM (100 plus).
• No semantic caching, no virtual key hierarchy, no native budget management in the open source layer.
• No 18 plus scanner library at the gateway; guardrails rely on Envoy filter chains the team writes.
• Operational complexity assumes Kubernetes plus Istio fluency; greenfield bring up cost is high without it.

Use case fit: Strong for Kubernetes first platform teams and Istio service mesh deployments wanting LLM traffic under the same Gateway API primitives. Less optimal where semantic caching, deep budget hierarchies, or 18 plus guardrails in one binary are load bearing.

Pricing and deployment: Apache 2.0; install via Helm chart in a Kubernetes cluster with Envoy or Istio already present.

Verdict: Right pick when the stack is already Envoy plus Istio plus Kubernetes Gateway API. Not the pick when semantic caching, virtual key budgets, or 18 plus guardrails in one binary are the constraint. Strongest supply chain hygiene baseline by inheritance from the Envoy CNCF project.

Helicone in 2026: Migration Planning After the Mintlify Acquisition

Helicone is the observability first AI gateway that broke open the adapter pattern category, Apache 2.0, with a clean cost and trace dashboard and an SDK helper that sits in front of OpenAI calls. After the March 3, 2026 Mintlify acquisition the right framing is “plan a migration window,” not “default pick for greenfield.”

The Apache 2.0 source in the Helicone/helicone repository remains available; existing users keep the checkout, and the managed plane continues operating under Mintlify, with roadmap velocity slowed.

Best for: Teams already running Helicone in production that need a 2026 migration plan, plus engineering teams evaluating the adapter pattern style of gateway as one option in a wider shortlist.

Key strengths:

• Apache 2.0 adapter pattern; keep your existing OpenAI client and add Helicone telemetry without rewriting the request path.
• Sub millisecond logging overhead via Cloudflare Workers in the managed deployment.
• Strong cost dashboard, trace explorer, and prompt and completion comparison surface for debugging.
• Existing user community and integration ecosystem covering OpenAI, Anthropic, Bedrock, and others.
• Self hostable in Docker plus cloud managed offering.

Limitations:

• Acquired by Mintlify on March 3, 2026; maintenance posture. Helicone’s GitHub activity slowed post acquisition; the project is best characterised as maintenance mode plus roadmap pending. Mintlify CEO Han Wang positioned the combined entity as a documentation first platform.
• Adapter pattern rather than base_url swap; migration touches client code, not the gateway address alone.
• Guardrail depth is thin compared to Future AGI ACC, Bifrost, or Portkey; observability is the differentiator.
• No MCP support at the gateway layer.
• Supply chain hygiene posture isn’t publicly disclosed; the maintenance posture doesn’t include a new Sigstore or SBOM commitment.

Use case fit: Strong for existing Helicone users who need a structured migration plan over the next 12 months. Less optimal for greenfield procurement, where acquisition independence and guardrail depth weigh against it.

Pricing and deployment: Apache 2.0 open source core; cloud managed tier under Mintlify. Install with docker compose up against the Helicone repo.

Verdict: Plan a migration. Existing production users should pick a forward target (Future AGI Agent Command Center for OTel native cost telemetry plus 18 plus guardrails in one binary, or Bifrost for raw Go throughput) and schedule the migration during Q3 or Q4 2026.

Maxim Bifrost for Throughput and MCP Token Reduction

Maxim Bifrost is the Go native AI gateway from Maxim, Apache 2.0, with vendor published P50 of about 11 microseconds at 5,000 RPS on a t3.xlarge and a strong MCP Code Mode story for multi server agentic workflows.

It’s the gateway most often cited when raw throughput is the binding constraint, and Maxim has built a separate brand around MCP token reduction for Claude Code and similar multi MCP server workloads.

Best for: Go shops whose binding constraint is gateway throughput at high concurrency, plus teams running Claude Code or multi MCP server workflows at scale that want native MCP transport coverage (STDIO, HTTP, SSE) and token reduction for tool calls.

Key strengths:

• Vendor published 11 microsecond P50 at 5,000 RPS on Maxim’s benchmark harness, plus native MCP Code Mode that Maxim claims reduces token usage by 50 percent or more across multi server agentic workflows.
• Apache 2.0 single Go binary, zero configuration startup, drop in container or binary deployment from the Bifrost repository (approximately 4,900 stars as of Q2 2026).
• Hierarchical budgets at four levels (Customer, Team, Virtual Key, Provider) with configurable reset cycles.
• Dual layer caching (exact hash plus vector similarity), audit logs aligned to SOC 2 Type II, GDPR, HIPAA, and ISO 27001, and vault integrations across HashiCorp, AWS, GCP, and Azure.

Limitations:

• Bifrost ships approximately 23 providers and approximately 1,000 model identifiers, narrower than LiteLLM’s 100 plus or Future AGI Agent Command Center’s 100 plus.
• Built in guardrail surface is PII plus basic moderation; no 18 scanner library inside the binary. Teams needing deep guardrail depth wire a separate scanner stack.
• Supply chain hygiene posture isn’t publicly disclosed. No Sigstore signing on the release flow, no public SBOM, no external incident response engagement on record as of May 2026.
• Maxim self ranks Bifrost first across its own gateway listicles with no published Limitations subhead per tool, a trust signal worth weighing during procurement.

Use case fit: Strong for Go shops, high throughput inference paths, multi MCP server agentic workflows, and Claude Code at scale. Less optimal when guardrail depth, per tenant cost attribution, or supply chain hygiene as a published posture are load bearing.

Pricing and deployment: Apache 2.0; Docker, Kubernetes; commercial cloud tier via Maxim. Install with docker run maximhq/bifrost.

Verdict: Strong throughput numbers and real Go engineering credibility, but the “go faster” pitch isn’t the same as the “win procurement” pitch in 2026. Choose Bifrost when throughput at 5,000 RPS or higher is the primary axis or MCP token reduction is load bearing; choose elsewhere when guardrail depth and supply chain hygiene as a published posture are.

The 2026 Open Source Gateway Trust Cohort

Every open source AI gateway listicle on the SERP is treating the 2026 trust cohort as if it didn’t happen. It did, and it reshapes the procurement question for the next 12 months.

The five dated events below verified to Q2 2026 are the editorial spine of any honest 2026 open source gateway procurement. Maxim doesn’t ship this sidebar. We always do.

Event 1: Helicone joining Mintlify (March 3, 2026). Helicone founders Justin Torre, Cole Gottdank, Scott Nguyen, and Stefan Bokarev confirmed the acquisition; Mintlify CEO Han Wang positioned the combined entity as the “leading AI experience platform for builders.” Helicone’s GitHub activity slowed post acquisition; the project posture is maintenance plus roadmap pending. Existing users keep the Apache 2.0 checkout and the managed plane; net new procurement shouldn’t bet a 2026 roadmap on Helicone’s pre acquisition velocity.

Event 2: LiteLLM PyPI supply chain compromise, the TeamPCP attack (March 24, 2026). Malicious 1.82.7 and 1.82.8 builds were published from a stolen Berri AI maintainer PyPI token. The payload injected install time code via the package __init__.py and setup.py flow that exfiltrated AWS, GCP, and Azure credentials from install hosts (CI runners, dev laptops, container build hosts) by reading common credential paths. Clean fix release is v1.83.0. Berri AI engaged Mandiant for incident response, migrated to a hardened CI/CD v2 pipeline with 2FA enforcement on PyPI release accounts, and began Sigstore and cosign signing of nightly builds at v1.83.0-nightly, verifiable via the Rekor transparency log. See the Datadog Security Labs writeup of the LiteLLM PyPI compromise and the LiteLLM security advisory.

Event 3: Anthropic MCP STDIO RCE class, CVE-2026-30623 plus 14 related identifiers (April 15, 2026). OX Security disclosed CVE-2026-30623 (LiteLLM MCP STDIO command injection) alongside 14 related CVEs across the MCP ecosystem (Agent Zero, Upsonic, Fay, Langchain-Chatchat, Windsurf, Bisheng, Jaaz, DocsGPT, GPT Researcher, MCP Inspector, LibreChat, WeKnora, Cursor, Flowise). Anthropic confirmed the STDIO transport behavior is by design and declined to modify the protocol, which made the LiteLLM patch at v1.83.7-stable a procurement signal rather than just an engineering bug fix. The post patch command allowlist is: npx, uvx, python, python3, node, docker, deno, gated by PROXY_ADMIN. See The Hacker News writeup of the Anthropic MCP design vulnerability.

Event 4: Higress CNCF Sandbox acceptance (March 25, 2026). Higress, the Alibaba originated AI plus API gateway based on Envoy and Istio, joined the CNCF Sandbox program. Apache 2.0 licensed with an AI routing module on top of the Envoy core, now in CNCF community governance. Cite as the eighth gateway to watch for 2027 procurement; not yet displacing one of the seven in the main list, but a credible signal that the CNCF AI gateway category is taking shape.

Event 5: Portkey acquired by Palo Alto Networks (April 30, 2026). Palo Alto Networks closed the acquisition; Portkey continues operating, the gateway core remains MIT and self hostable, the managed control plane is consolidating under Palo Alto’s enterprise stack with Prisma AIRS integration roadmap pending. Existing Portkey customers keep the gateway core and the cloud control plane through the transition; net new procurement should evaluate whether Palo Alto’s eventual repackaging matches the buyer’s existing security tooling.

The practical takeaway: license clarity verified against the LICENSE file, acquisition independence, supply chain hygiene, and OpenTelemetry native cost telemetry are now first class procurement axes alongside the older feature comparison.

A cheap gateway you have to migrate off in six months isn’t cheap. A gateway with a published Sigstore signing posture and a Mandiant engagement after an incident is a stronger procurement signal than a gateway with no published incident response posture and no known incident.

Supply Chain Hygiene Scorecard for Open Source AI Gateways in 2026

Supply chain hygiene is the eighth scorecard dimension in 2026, and the single column missing from every existing open source AI gateway listicle on the SERP. It’s the column buyers care about after March 24, 2026.

Three observations follow from this matrix. First, LiteLLM’s post incident posture is the strongest published supply chain hygiene story in the category right now. The combination of Sigstore signing from v1.83.0-nightly, the CI/CD v2 pipeline, the Mandiant engagement, and a public post mortem is the textbook recovery posture.

Second, the structural advantage of a single static Go binary is that the install time attack surface that caused the March 2026 LiteLLM PyPI compromise doesn’t exist in the same shape. There’s no __init__.py execution path at install time, no .pth file injection vector, no setup.py hook.

Container digest pinning plus a future Sigstore signature complete the posture, and the structural property is the foundation underneath both.

Third, the Bifrost, Portkey, and Helicone rows in the matrix above all read “not publicly disclosed.” That doesn’t mean the projects are compromised. It means the procurement requirement to verify a Sigstore signature, audit an SBOM, or read a documented incident response posture isn’t met by a public artifact today.

Buyers can wait for it, or they can move to a gateway that ships the artifact now.

Honorable Mentions: Apache APISIX, Higress, LLMGateway.io, OpenRouter

Three honorable mentions sit just outside the main seven, and one closed source incumbent gets a clarification mention because buyers land here looking for it.

Apache APISIX (github.com/apache/apisix, Apache 2.0, ASF top level project). The right answer when ASF governance is a procurement requirement. APISIX ships ai-proxy, ai-rate-limiting, ai-prompt-decorator, and ai-prompt-guard plugins on top of the API gateway lineage.

Community owned, not vendor controlled, with ASF security policy and build provenance baked in. Cite as an honorable mention; greenfield AI procurement at most teams will reach for a purpose built AI gateway first.

Higress (github.com/alibaba/higress, Apache 2.0, CNCF Sandbox March 25, 2026). Alibaba originated, Envoy and Istio based, AI plugin set plus traditional API gateway in one product, now in CNCF community governance. The eighth gateway to watch for 2027 procurement. Cite the CNCF Sandbox acceptance date and the architecture; don’t yet displace one of the seven in the main list.

LLMGateway.io (github.com/theopenco/llmgateway, AGPLv3). Cite as a procurement disqualifier for most enterprise buyers, explicitly because of the license rather than because the project lacks features. Any commercial product that exposes LLMGateway.io over a network must release its own source under AGPLv3.

The network clause matters in air gapped tenants, multi tenant SaaS, and any product that ships LLMGateway.io as part of a closed source stack. Cite the license explicitly; don’t bury it.

OpenRouter (closed source, managed SaaS). Routes across 400 plus models on 60 plus providers with a 5.5 percent platform fee on top of provider pass through pricing. Often confused with open source AI gateways because the SDK ergonomics resemble a drop in proxy.

Not in the seven because the source isn’t published. Buyers who land here looking for OpenRouter coverage should also read the sibling listicle on multi model routing.

The pattern across the four mentions: license class, governance, and acquisition status decide which gateway belongs in the main seven and which belongs in the honorable mentions. Feature parity is necessary but not sufficient.

Open Source AI Gateway Picks by Buyer Profile in 2026

The buyer profile drives the pick more than the feature matrix does. OpenTelemetry first engineering teams pick Future AGI Agent Command Center; multi tenant SaaS teams that want a managed dashboard pick Portkey (with the Palo Alto integration timeline acknowledged); Python first ML platform teams pick LiteLLM with commit pinning plus Sigstore verification.

Kong shops pick Kong AI Gateway. Kubernetes plus Istio shops pick Envoy AI Gateway. Helicone users plan a 2026 migration. Go shops or Claude Code at scale pick Bifrost. Acquisition averse buyers pick Future AGI Agent Command Center, Kong AI Gateway, Envoy AI Gateway, or Bifrost. AGPLv3 averse buyers avoid LLMGateway.io.

The structural decisions stack: choose the license class first, then the acquisition risk tolerance, then the supply chain hygiene posture, then the feature matrix. A gateway that wins the feature matrix and loses the license class question isn’t the right pick in 2026.

Which Open Source AI Gateway Should You Pick in 2026?

Open source AI gateways in 2026 are no longer a license box on the side of the procurement form. They’re a stack of decisions: license class verified against the upstream LICENSE file, acquisition status, supply chain hygiene posture, guardrail depth, OpenTelemetry native observability, and cost governance, all evaluated together at the same network hop.

Of the seven gateways above, Future AGI Agent Command Center is the strongest pick when the constraint is Apache 2.0 plus OpenAI compat plus 18 plus guardrails plus MCP plus A2A plus per key budgets plus OTel native cost metrics in one Go binary. No pending acquisition, no install time attack surface in the shape that caused the March 2026 LiteLLM PyPI compromise.

Independent reproduction of the published throughput numbers (about 29,000 req/s, P99 21 milliseconds with guardrails on, on t3.xlarge) is the open 2026 deliverable, planned alongside a Sigstore signing posture on nightly builds and a published SBOM. The structural advantage today is the single static Go binary; the published artifacts are the next step.

LiteLLM is the right call when Python first plus MIT plus the broadest provider list outweighs the commit pinning, Sigstore verification, and credential rotation overhead the two 2026 incidents introduced. Credit Berri AI for the Mandiant engagement, the CI/CD v2 pipeline, and the Sigstore signing from v1.83.0-nightly; the post incident posture is the strongest published in the category.

Portkey is the right call when a managed cost dashboard with a fine grained budget hierarchy is the brief and the Palo Alto integration timeline is acceptable. The MIT gateway core remains self hostable; the closed managed control plane is consolidating under Palo Alto.

Maxim Bifrost is the right call when published per request overhead at 5,000 RPS or native MCP Code Mode is the binding constraint, and when the supply chain hygiene posture not being publicly disclosed yet is acceptable.

For deeper reads on the patterns referenced above:

• Future AGI’s evaluation platform for the continuous LLM evaluation surface the gateway plugs into via span_id.
• Future AGI’s guardrails documentation for the 18 plus scanner library that ships in the same Apache 2.0 binary.
• Future AGI’s observability documentation for the OpenTelemetry native trace tree the gateway exports into.

External references for the trust cohort and standards cited above:

• Datadog Security Labs writeup of the LiteLLM PyPI compromise.
• LiteLLM security advisory.
• Palo Alto Networks press release on the Portkey acquisition.
• The Hacker News writeup of the Anthropic MCP design vulnerability.
• OpenTelemetry GenAI semantic conventions.
• Model Context Protocol specification.
• OWASP LLM Top 10.
• LiteLLM repository (LICENSE verification).
• Portkey gateway repository (LICENSE verification).
• Bifrost repository.
• Kong repository.
• Envoy AI Gateway repository (LICENSE verification).

Try Agent Command Center at futureagi.com/platform/monitor/command-center: OpenAI compat drop in, 18 plus guardrails, per key budgets, MCP plus A2A, OTel native cost metrics, one Apache 2.0 Go binary, no install time attack surface.

Related reading

• Best 5 AI Gateways for Compliance Audit Trails in 2026, the compliance and audit-trail comparison
• Best 5 AI Gateways for LLM Cost Optimization in 2026, the five-layer cost stack and the 2026 trust cohort
• Best 5 AI Gateways for LLM Observability and Tracing in 2026, the OpenTelemetry-native observability ranking
• What is an AI Gateway? Governance, Routing, and Observability in 2026, the architectural primer for the category