Who Owns Your LLM Router in 2026? (Maintained Ownership Table)

Three of the routers and gateways developers relied on in 2025 changed owners in 2026. Stripe is acquiring OpenRouter for more than $7bn (Bloomberg, reported 16 August, announced 19 August), Palo Alto Networks completed its acquisition of Portkey on 29 May, and Mintlify acquired Helicone in March. If you are trying to work out what that means for the gateway you already depend on, the short version is: ownership sets the roadmap, and the roadmap decides whether your router is still built for the job you picked it for.

This page is a plain, sourced table of who owns what, and what each deal actually changed. I keep it current as the next deal lands, because in this market there is always a next deal.

Who owns your LLM router in 2026?

Sources for each deal are linked at the foot of this page. If you spot a change I have missed, the table is meant to be corrected.

Why ownership changes the product you are using

A gateway does what its owner needs it to do. That is not cynicism, it is how roadmaps get funded.

When a payments company buys the router, the router gets very good at metering and billing inference, because that is the business Stripe is in. OpenRouter was already the balance and the meter in front of the model catalogue, so this is a natural fit, and for access and failover it stays useful. What a payments owner has no reason to build is per-prompt quality verification, because that was never the product.

When a security company buys the gateway, the gateway gets very good at governance. Palo Alto Networks did not buy Portkey to help you shave 30 to 60% off your inference bill. It bought a control plane to inspect, govern and secure AI agents at enterprise scale, which is exactly what its own announcement describes. If you adopted Portkey as a cost-and-observability tool, you are now a smaller part of a bigger security story.

And when a gateway goes into maintenance mode, it optimises for nothing new. Helicone under Mintlify still gets security updates and bug fixes, which is honest and more than some acquired tools offer, but "no major new features" is a real signal if you are choosing where to build for the next two years.

The half none of these deals bought

Here is the thing worth noticing across all three. Not one of these acquisitions closed the gap that actually costs teams money: none of them proves the cheaper model the router picks is good enough on your prompts before it switches.

A router, whoever owns it, decides on price, latency, uptime or a general benchmark, before it has seen the answer. That is the design, and for reaching a cheaper model quickly it works. But it means the router never checks whether the cheaper model it just chose held up on your specific traffic. You save on the invoice and, on the prompts where the cheaper model quietly got worse, you ship a degraded product you never measured. I wrote about that failure mode in how to route between LLMs to save money, and it is the same gap whether the router is owned by Stripe, Palo Alto or nobody.

Proving it is a separate job from routing. You run the cheaper model against the model you use now, on your own prompts, judge the outputs blind against your baseline's own run-to-run consistency, and switch only the prompts that clear the bar, with an instant fallback the moment quality drifts. That is where the honest saving comes from, and it is the number I keep public: across 16,764 blind comparisons on real production prompts from 145 companies, run between 27 March and 3 August 2026, the cheaper model held or beat the more expensive model it replaced 85.5% of the time (77.5% matched, 8.0% beat it, 14.5% failed to hold and stayed on the original). You can browse the live ranking by model and task on the Parity Index.

So what should you actually do?

Keep your router for what it is good at. If you need the widest model menu behind one endpoint with pooled uptime, OpenRouter is still that, Stripe or not. If you need enterprise governance and you are already a Palo Alto shop, Portkey inside Prisma AIRS may fit. If you are on Helicone, plan for maintenance mode rather than a growing roadmap.

Then add the step none of them do. Before you trust any cheaper model in production, prove it holds on your own prompts. The router picks; the proof decides.

You can do the proof before you touch a line of code. Export a JSONL of past requests and run a cheaper model against your current one offline, so nothing in production moves until you have the evidence. If you want to see how much you are overspending on your AI API bill and which cheaper models actually hold on your own traffic, that is exactly what the proof report is for. It is deliberately not built for coding agents; it is for the high-volume production prompts where a proven switch is money you keep.

For the wider picture, see the survey of the best LLM routers and honest alternatives, and the migration-specific guides for OpenRouter, Portkey and Helicone. For the cost side, start with the LLM cost optimisation guide.

FAQ

The questions I get asked most about these deals are answered in the FAQ above: who owns OpenRouter now, who owns Portkey after the Palo Alto Networks acquisition, whether Helicone is still maintained, which routers are still independent, and whether ownership actually matters. The short answer to the last one is yes, because ownership sets the roadmap, and no owner on this list is building the proof step for you.