Portkey Alternative: What AI Teams Are Evaluating After the PANW Acquisition

On April 30, 2026, Palo Alto Networks announced its intent to acquire Portkey — folding the AI gateway and LLMOps platform into Prisma AIRS (AI Runtime Security). The deal is expected to close by July 31.

For thousands of engineering and FinOps teams that had been evaluating Portkey as their AI gateway layer, the acquisition changed the procurement calculus overnight. Portkey isn't being killed — but it's being absorbed into a $300K+ enterprise security suite sold by enterprise security AEs to CISOs. If your primary concern is cutting LLM costs and you don't have a seven-figure Palo Alto relationship, you're no longer the target customer.

This post breaks down what changed, what the alternatives actually are, and the questions that should drive the evaluation.

What the acquisition actually changed

The product isn't going away. Portkey was processing 500 billion tokens per day and 125 million requests per day at acquisition — PANW is not acquiring it to shut it down. But the product's distribution model is transforming:

• Before: Engineering teams could trial Portkey for free (10K recorded logs/month), upgrade to $49/month for production, and scale from there. Credit card purchase, 5-minute setup.
• After: Portkey becomes a component of Prisma AIRS — PANW's AI security platform sold through enterprise AEs, multi-year contracts, and CISO-level procurement. The "$49/month" tier will eventually have a strategic successor; the pathway is enterprise bundling.

This isn't hypothetical. It's the classic enterprise acquisition pattern: buy the developer-loved product, absorb it into the enterprise suite, migrate it up-market. Portkey's existing customers will be served, but the roadmap will increasingly serve PANW's security-first enterprise priorities, not the FinOps-first cost optimization use case.

The three categories that emerged from one

"AI gateway" meant something vague through 2024. The Portkey acquisition forced a useful distinction. There are now at least three distinct categories, each with its own primary buyer and its own vendor set:

The fatal mistake most teams make: they evaluate all three categories simultaneously, compare feature lists, and pick the one with the most checkboxes. The right framework is the opposite — decide which category you are, then compare within that lane.

If your gateway is purchased by your security team and has to pass a CISO review, security-first is your category. If your primary signal is "why did this call fail and how do I replay it?", observability-first is your category. If your primary signal is "we're spending $800K/year on LLM calls and need to cut it by 40%," economics-first is your category.

Most companies buying Portkey before the acquisition were in the observability lane — attracted by the rich log UI, traces, and prompt management. After the PANW deal, that use case lands squarely in the gap: too security-focused for pure observability, too observability-focused for pure FinOps.

The Portkey pricing model — and why it gets expensive at scale

Before evaluating alternatives, it's worth being clear on what Portkey actually charges for — because its pricing model is unusual in the AI gateway space.

Portkey bills based on "recorded logs" — not requests routed, not tokens processed, not API calls. A recorded log is one LLM request captured in their observability system. The gateway keeps routing even after you exhaust your log quota, but you lose visibility into calls beyond the limit — which defeats the purpose of an observability platform.

The math at scale: a mid-size AI application at 1M requests/month is $49 + (9 × 9) = ~$130/month today. At 5M requests/month: $49 + (9 × 49) = ~$490/month. At 10M requests/month, you're in enterprise pricing territory. These numbers sound manageable — until you account for the fact that you're also paying full LLM provider costs on top, and Portkey's log-based pricing doesn't give you the one thing that would offset those costs: cost optimization.

Portkey shows you what you're spending. It doesn't automatically route calls to reduce what you're spending. That's the gap.

The LiteLLM option — and why two CVEs in six weeks changed the calculus

The most common alternative to Portkey on the engineering side is LiteLLM — an open-source Python proxy that supports 100+ LLM providers, runs on your own infrastructure, and costs nothing per request. For teams that want full control and don't want per-log billing, it's the obvious choice on paper.

But 2026 handed LiteLLM two significant incidents that changed the calculation for production use:

• CVE-2026-42208 (February 2026): A server-side request forgery (SSRF) vulnerability that allowed unauthenticated attackers to make requests from the LiteLLM server to internal network resources. Exploitable without credentials. Required immediate patching across all self-hosted deployments.
• March 2026 supply-chain compromise: A malicious package was briefly published to PyPI mimicking a LiteLLM dependency. Affected teams running automated dependency updates before the package was pulled.

Neither incident is fatal to LiteLLM as a project. Both incidents reframe the "free self-hosted proxy" calculation. The true cost of self-hosted LiteLLM is not zero — it's the engineering burden of patching, monitoring CVEs, validating dependency supply chains, and running a Python web service in production. We covered the architectural reasons for this gap in detail. For teams that have already gone through one incident response cycle, that cost is no longer theoretical.

The evaluation framework: five questions to ask any AI gateway

Before committing to any AI gateway in 2026 — Portkey alternative or otherwise — these are the questions that separate the options:

1. Does it reduce your bill or just show you your bill? Observability tells you what you spent. Cost optimization changes what you'll spend next. These are different products. Most gateways only do the former.
2. What is the failure mode? If the gateway goes down, does it fail open (traffic routes directly to providers) or fail closed (traffic stops)? For production AI applications, this is a five-nines question.
3. Does routing have economic intelligence? Round-robin and latency-based routing have been table stakes since 2024. Quality-Value assessment — routing to the cheapest model that will produce an acceptable output for this specific request type — is a different capability that most "routing" vendors don't actually have.
4. Who owns the buying motion in 18 months? Portkey's acquisition is instructive: a product purchased on a credit card by an engineer today may require CISO sign-off and an enterprise contract in 18 months. Build your gateway strategy around where the product is going, not where it is now.
5. What is the architecture? Python web apps have different failure modes, security surfaces, and performance profiles than Go binaries. For a layer that sits in the critical path of every AI call, the architecture is not an implementation detail.

Where the economics-first buyer lands

The clearest gap the PANW acquisition exposed: there is no large incumbent in the economics-first AI gateway lane. Security-first now has Palo Alto. Observability-first has Helicone, LangSmith, and others. The economics-first lane — routing to the cheapest capable model, compressing tokens before they leave the wire, maximizing provider-native caching, enforcing real budget limits — is the white space.

The economics-first feature set looks different from what Portkey was primarily selling:

• Least-cost routing with quality assessment: Not round-robin. Not latency-first. Routing that evaluates model quality against request complexity and sends calls to the cheapest model that will produce an acceptable output.
• Token compression: Reducing prompt token count before the request leaves your network — 30–40% fewer input tokens without degrading output quality. This is upstream of the provider bill, not reported after it.
• Cache intelligence: Maximizing provider-native caching (Anthropic prompt caching, etc.) so stable system prompts and context blocks aren't billed twice. Separate from semantic caching — this is a different, more structural savings.
• Hard budget controls: Not soft alerts. Token-budget caps per session, per user, per team, per feature — with circuit breakers that enforce them before spend occurs.
• Governance reporting: Board-ready cost attribution by model, team, feature, and provider — the kind of breakdown a CFO needs for FY27 planning, not just a developer dashboard.

Portkey had some of these as features. After the PANW acquisition, the product's strategic direction will be Prisma AIRS, not cost optimization. That's not a criticism — it's a category choice, and it's the right one for PANW. It just creates a clear gap for teams whose primary question isn't "are my AI calls secure?" but "are my AI calls as cheap as they could be?"

The acquisition validated the category. It clarified the lanes. If you're looking for a Portkey alternative because cost optimization is your primary driver, that's the lane Trimio is built for.