Who owns your AI gateway? The 2026 acquisitions

Why ownership is an architecture question

A gateway sits in the request path of every model call an application makes. It holds credentials, sees prompts or at least their metadata, keeps the request history your finance and on-call teams read, and often holds the routing and budget policy that decides what a request is allowed to do. That makes it the kind of dependency where a change of owner is worth a deliberate look, the way a change of owner at your database host or payment processor would be.

The look is not a judgment. Companies acquire products because they are good and fit a larger plan; open-source projects change foundation or name to find a longer-term home. Several of the changes below came with explicit commitments that nothing changes for current users, and there is no reason to doubt them. What changes is who sets the terms from now on: pricing, roadmap, which subprocessors handle your data, which contract you sign at renewal. Those are things you would rather plan for than discover.

This piece does two things. It dates the 2026 ownership changes in the LLM gateway and observability category, each from the acquirer's or vendor's own page. Then it turns that into a checklist you can run against any gateway, including the one you build yourself.

The 2026 timeline, from primary sources

Langfuse → ClickHouse (2026-01-16). ClickHouse announced it had acquired Langfuse, the open-source LLM observability, evaluation and prompt-management platform. The announcement says the core stays under its MIT license, self-hosting continues, Langfuse Cloud keeps running as a standalone service, and for existing deployments "nothing changes"¹. Langfuse is an observability product rather than a proxy, so it is not in the request path; what moved is the home of your traces and evaluation data.

Helicone → Mintlify (2026-03-03). Helicone announced it was joining Mintlify. Its post says the services "will remain live for the foreseeable future in maintenance mode", with security updates, new model support and bug and performance fixes continuing to ship, and the founders offer help to anyone migrating². On 2026-10-13 Helicone's pricing page still showed a "Start for free" button; it does not say whether new sign-ups are accepted³. Maintenance mode is an honest, clearly stated position. It is also a signal to check whether the features you will need next year are on a roadmap that is still being built.

Portkey → Palo Alto Networks (closed 2026-05-29). Palo Alto Networks announced it had closed the acquisition of Portkey and would establish it as the core AI gateway for Prisma AIRS, its AI security platform⁴. Portkey's own pricing page now carries the banner "Portkey is now PRISMA AIRS AI Gateway", with its upgrade and contact links pointing to Palo Alto Networks⁵. For a Portkey customer the practical questions are the ordinary ones: which entity your next contract is with, and whether your plan and terms carry over.

TensorZero repository archived (2026-06-12). GitHub shows the tensorzero/tensorzero repository as archived by its owner on 12 June 2026, read-only⁶. The README carries no shutdown notice, and this article does not repeat the reasons reported elsewhere. An archived open-source project keeps working exactly as the version you run; it stops receiving fixes, including security fixes and support for new provider APIs.

OpenRouter → Stripe (agreed 2026-08-19). Stripe announced that it "has agreed to acquire" OpenRouter⁷. OpenRouter's post the same day says the deal is "subject to customary closing conditions", that the companies "expect to close in the coming weeks", and that OpenRouter "will continue to operate as it is: same mission, same name, same product, same roadmap"⁸. As of 2026-10-13 neither company had published a completion notice. Press reports that describe the deal as completed cite unnamed sources, not either company, so this article treats it as announced and not confirmed closed.

Envoy AI Gateway → Agent Router (2026-09-10). The Envoy AI Gateway project announced on 9 September that it would join the Agentic AI Foundation as Agent Router on 10 September. The post is specific about what does not change: the CRDs and API group, the aigw CLI and the namespace stay as they are, the license stays Apache 2.0, the maintainers are the same, and old repository and documentation links redirect⁹. This is a rename and a new governance home, not an acquisition, and it is a good model of how to announce one.

What an ownership change can and cannot change

It helps to separate what an acquirer can change from what it cannot.

An acquirer cannot change the code you already run, the data you already exported, or the provider contracts you hold in your own name. It can change, at the next renewal or with notice: pricing and packaging, which plans exist, which features are prioritized, which subprocessors process your data, which legal entity you contract with, and in the end whether the product continues on its own or folds into a larger one.

Most of those changes are slow and announced. The risk is not that an acquired gateway stops working overnight; it is that a decision you would want to make on your own schedule (renegotiating terms, moving off, adding a second path) ends up being made on someone else's. The way to keep that decision yours is to know in advance what moving would take.

A portability checklist for any gateway

Run these questions against whatever sits in your request path: a hosted gateway, an open-source proxy you operate, or the routing layer your platform team wrote. They are also the right questions for a gateway that has not changed hands, because the answers decide how much any future change costs you.

Whose accounts and contracts serve the traffic

This is the question that matters most. Some gateways hold the upstream provider accounts themselves and sell you access to models; others route through accounts and contracts you hold with each provider. In the first model, your rates, your rate limits and your capacity commitments belong to the gateway's account. If the gateway's owner, pricing or provider relationships change, all of that changes with it, and moving off means opening provider accounts, negotiating terms and getting quota from scratch.

In the second model, the provider bills you, your negotiated rates and committed-use agreements stay where they are, and the gateway is software in front of them. Moving off is a client change, not a procurement project. Ask the vendor directly, and confirm it on the invoice: which company's name is on the provider's bill for your tokens?

Where credentials live, and how to rotate them

Find out where your provider keys are stored, how they are encrypted, who at the vendor can reach them, and whether you can rotate them without downtime. The cleanest exit property is that you can revoke a key in the provider's console and the gateway's copy stops working at once. That is only possible when the key was minted in your own provider account. Also check the gateway's own keys, the ones your applications send: can they be rotated with an overlap window, and can they be scoped so a leak is contained?

Whether the API is a public format

If your applications speak a public request format, usually the OpenAI-compatible Chat Completions shape, then moving to another gateway or straight to a provider is mostly a base URL and a key. If they depend on gateway-specific request fields, headers or SDKs, list them; each one is a code change on exit. That is not a reason to avoid useful features, only to know which ones you use and to keep them at the edges of your code rather than in its middle.

Data export: logs, usage and cost

Request history, token and unit counts, and cost estimates are the evidence for chargeback, audits and incident reviews. Check that you can export them in bulk, in a documented format, without a support ticket, and inside the retention window your plan gives you. History you did not export before a migration is history you do not have after it. If the gateway can push traces to your own collector over OpenTelemetry, that is a continuous export that keeps working whoever owns the gateway.

What happens to traffic if the gateway is down

A hosted gateway in the request path is a dependency with its own availability. Read its status page history, find out whether there is a published SLA and what it covers, and decide what your client does when the gateway does not answer. The usual answer is a break-glass path: a configuration flag that points the same SDK at the provider directly, using a key from your own account. It only works if you hold provider accounts, and only if you have tried it.

What the contract says on a change of control

Read three documents: the master agreement, the data processing agreement and the subprocessor list. In the master agreement, look for the assignment and change-of-control clauses (whether the vendor can assign your contract to an acquirer, and whether you get notice or a right to terminate), the termination-for-convenience terms, and what happens to your data on termination. In the DPA, look at how subprocessor changes are notified and whether you can object. An acquisition often adds the acquirer's infrastructure and affiliates as subprocessors; that is normal, and your DPA should tell you how you hear about it.

Run the exit before you need it

None of the checklist matters if the exit has never been exercised. A short drill, once a quarter, turns a theoretical plan into a known one.

Export on a schedule you control, not on the day you decide to move. Keep the provider-direct path in the client behind a flag and send a small share of non-critical traffic through it occasionally, so it does not rot. Keep routes, budgets and allowlists in version control or infrastructure-as-code where the gateway supports it, and as a written record where it does not. Rotate a provider key and watch the gateway's copy fail, so you know the revocation path works.

Portability in INFRO: accounts, keys and exports

INFRO is a gateway too, and the checklist applies to it in the same way. Like any company it could change owners; the useful question is what you would have to move if it did. Here are the answers, with the endpoints and documents you can check them against.

Accounts and contracts stay yours. You connect provider accounts you already hold: OpenAI, Anthropic, Google, Azure OpenAI, AWS Bedrock and the other kinds in the providers docs. Your provider bills you directly for what your requests cost, at whatever rates you have negotiated. INFRO charges a software subscription and takes 0% of model spend; nothing INFRO sells is priced per token. The provider is named on every request record, because it is your own account that served it.

Credentials. A provider key is encrypted when saved, scoped to your organization and never shown again; applications send INFRO gateway keys instead. Because the provider key was minted in your provider account, revoking it there cuts INFRO off from that account at once. If you delete an INFRO organization, the docs say your provider accounts are not touched and tell you to revoke the credentials you connected with each provider.

A public API shape. Text requests go to POST /v1/chat/completions in the request shape the OpenAI SDKs already send, including streaming and tool calling. Pointing an OpenAI SDK back at a provider's OpenAI-compatible endpoint is a base URL and key change; INFRO-specific request metadata such as feature or workflow tags is optional.

Exports. Request records are available from GET /v1/requests, and as CSV from GET /v1/requests/export (up to 50,000 rows per file). Usage aggregates come from GET /v1/usage, as JSON or with format=csv, and GET /v1/usage/focus returns a FOCUS v1.4 Cost and Usage dataset as JSON or CSV. All of these work inside your plan's queryable history: 7 days on Developer, 14 on Startup, 30 on Team, 90 on Business. There are no scheduled or emailed exports, so the export schedule is yours to run. On Team, Business and Enterprise, OpenTelemetry pushes metadata spans (request ID, model, route, timing, token counts, estimated cost) to your own collector over OTLP/HTTP; delivery is best effort, and the docs say not to use it as your only accounting record.

Routing policy. Routes are named configuration over your own connections (ordered or weighted targets, if-rules and failure rules), so the knowledge of what serves which workload lives in a place you can read, export through the management API and recreate elsewhere.

When the subscription ends. An organization with no active plan is locked: the gateway answers 402 subscription_required and the console closes, except for billing, organization settings and revoking keys. The docs state that nothing is deleted. Your provider accounts never stopped being yours, so your applications can call the providers directly in the meantime.

What INFRO does not remove is the dependency itself. It sits in the request path, so a client without a provider-direct path depends on INFRO being up, as it would on any hosted gateway. Keep the break-glass flag described above whichever gateway you use.

Where to go from here

If you are choosing a gateway now, the build-versus-buy guide covers the operating cost of each path. If you are already on one and the timeline above touched it, the vendor lock-in guide goes deeper on abstraction boundaries, and the OpenRouter alternatives review compares the hosted options by how they handle accounts, keys and fees. In every case, start with the first checklist question: whose name is on the provider's invoice.