Guide
Who still owns your LLM gateway?
Short answer
Evaluate LLM gateway continuity through current ownership evidence, contractual exit rights and a rehearsed recovery path. An acquisition announcement is not proof of closure or product shutdown. An open licence and a self-hosting option can help preserve a version, but continuity also needs build artifacts, dependencies, configuration, expertise and working model access.
A continuity worksheet you can rehearse
| Dependency | Evidence or exercise |
|---|---|
| Software | Licence for the exact version, source, signed artifacts and dependency mirrors. |
| Service state | Export routing rules, budgets, keys, usage records and required datasets. |
| Model access | Independent provider credentials, quotas, contracts and model IDs. |
| Operations | Named maintainer, restore test, patching plan and recovery-time target. |
| Commercial exit | Notice period, assignment, export/deletion terms and remaining credit balance. |
Transaction sources reviewed September 16, 2026: Mintlify’s March 3 Helicone announcement; Palo Alto Networks’ May 29 Portkey completion; Stripe’s August 19 agreement to acquire OpenRouter. A publication describing an announcement is evidence of that announcement, not a continuously updated deal-status register.
Who owns the 31
Ownership is recorded as one field with the acquirer’s legal name, one with the date, and one recording whether that date is when the deal was announced or when it closed. Nothing in this section is a prediction. It is a record of who currently sets the roadmap for each gatewayGateway: A single endpoint you send all your AI requests to, which then forwards them to whichever model you asked for. One integration instead of one per vendor., which is a different and more answerable question than whether a company will still exist next year.
- 3 Changed hands
- An acquirer is recorded. 1 deal has closed and 2 are announced but not yet completed.
- 16 Independent
- Still a standalone company with its own roadmap. The largest group, and the one where the licence you adopted under is the thing that decides your options later.
- 9 Foundation or large cloud vendor
- 5 governed by a software foundation and 4 shipped as one line of a large cloud vendor’s platform. Neither shape removes risk; both change who it sits with.
The catalogue records 3 acquisition events. The dated primary sources in the worksheet above distinguish an announcement from a completion. Those sources establish the reported event; they do not establish the buyer’s motives, future roadmap or financial strength. Read the current contract and product notices before making a continuity decision.
Keep the two bases apart when you plan. 2 of the 3 recorded deals are announced rather than closed, which records the basis of the cited date, not proof that the deal remains pending today. An announced deal is a reason to read your renewal date and your data-export terms before the deal completes, while you still have the attention of the people you originally bought from.
The asymmetry that decides your options
Crossing the licence against the deployment model splits the catalogue into three groups with genuinely different answers to “what do I do if this product stops suiting me”. The split is not about which vendor is stronger. It is about which technical and contractual dependencies a continuity plan must address.
- Fork and freeze — 13
- An open licence and a self-hostedSelf-hosted: You operate the software on your infrastructure and own its uptime, patching and upgrades. Model hosting, telemetry and control planes may still involve third parties; commercial editions can have licence fees. path. If the roadmap moves somewhere you do not want to go, you may be able to pin a usable version, subject to its licence, dependencies and maintenance requirements. It is not free — you now own the patching — but it is available without a negotiation, Verify that path with a restore exercise. 9 of them also keep configuration in files you can carry elsewhere.
- Run it yourself, under a commercial agreement — 4
- Open-core and proprietary products with a documented self-host path. The binary runs in your network, but remote control-plane or licence services may still be dependencies. The right to keep running it comes from the contract rather than the licence. The question to ask before signing is what happens to your installation if the agreement is not renewed by whoever owns it then.
- Managed only — 14
- The largest group. There is nothing to fork and nothing to freeze, so continuity is an integration question: how quickly could you point your traffic somewhere else, and how much of your spend history, routing policy and key management would you lose in the move. That is answerable, and it is answerable in advance.
1 managed-only products carry an open licence, so the fork option exists for some of them even without a vendor-supported self-host path. That is worth stating plainly because it is easy to assume an open repository implies a fallback. The fallback comes from the licence and the self-host path together, and 13 of 31 products have both. Of those, 2 also document air-gapped operation. That claim still needs an offline deployment test for the selected edition and its dependencies: Bifrost and LiteLLM.
Licence, ownership and last release, for all 31
Sorted by name rather than ranked, because there is no order that would be honest here. Read across a row: the licence and deployment columns identify potential fallback options to validate, the ownership column tells you who currently sets the direction, and the release date tells you the cadence you would be pinning against.
A blank licence or release cell reads as not published rather than as no; silence from a vendor is a finding, and it is not the same as a documented answer. The ownership column is the exception: none recorded there means we found no acquisition, not that the vendor declined to say.
The signals worth reading, and the ones that are not signals
Four fields get used as proxies for whether a vendor will still be around. Two of them carry information, one carries less than people think, and one is not a signal at all. All four counts below are measured against the catalogue with latest recorded data change on 26 September 2026, not against the day you are reading this.
- Release recency — 23 shipped within 90 days
- 25 of 31 products publish a date for their most recent release. 23 of those fall within 90 days of the verification date above, which is a market shipping at a steady cadence rather than a market in trouble. 2 are older, which is a question about cadence rather than a conclusion — a mature component that has stopped changing weekly is behaving normally. 6 publish no release date at all, which is common for a hosted service that ships continuously and has no version to tag.
- A published changelog — 18
- The cheapest signal to check and the one you can keep checking after you have adopted. 18 of 31 publish a changelog you can subscribe to or read on a schedule; the remaining 13 give you nothing to watch between releases. Put the ones that do publish into a reader and you have a standing answer to this whole question for the price of five minutes.
- Founding year — published for 16
- 15 of 31 products do not publish one. That is a disclosure gap and a fair question for a sales call, not a finding about the company. Where it is published, an early year is a strength rather than a risk: 5 of the 16 published years predate 2020, and the earliest is 2009, held by Cloudflare AI Gateway and Kong AI Gateway. Companies that old have survived several technology cycles and rarely depend on this product alone.
- Star counts — published for 14, structurally absent for 17
- Every product with a star count carries a licence other than proprietary, and 13 of the 17 blanks are proprietary products with no public repository to have stars in. The blank is a fact about the distribution model, not about adoption or health. Comparing a star count against a product that has none is comparing a number with a category error, and it is the most common way this question gets answered badly.
What to do with all four: check the changelog before you adopt and after, ask for the founding year and the ownership position in writing if they are not published, and ignore the star count entirely when the comparison crosses a licence boundary. Then spend the time you saved on the thing that actually determines your options, which is whether you could run a copy at all.
Where you stand
You have a continuity plan if
- You have verified the licence and restored a working build with its dependencies.
- Your routing, budget and key configuration lives in files you hold.
- You hold the upstream provider keys, so the models answer to you.
- You have named the product you would move to, before needing it.
You are more exposed if
- The product is managed only, so there is no copy to fall back to.
- Your spend history and usage data exist only in the vendor dashboard.
- Prompts, policies or evaluation sets are stored solely on their side.
- Nobody on the team has read the notice period in the contract.
Reduce the exposure by
- Keeping configuration as code — 15 products support it.
- Exporting usage and spend on a schedule rather than on an incident.
- Asking for data-export and assignment terms in writing at renewal.
- Subscribing to the changelogs of the 18 that publish one.
Common questions
Does an acquisition mean the product is going away?
No. An announcement does not establish future product availability, support or investment. Review published commitments and your contract rather than inferring the buyer’s motives. What changes is who sets the roadmap and who the product is now built to serve. That is worth knowing before your renewal, not after, and it is a reason to check the terms rather than a reason to migrate.
How do I tell an announced deal from a closed one?
The catalogue records the basis of each acquisition date as either announced or closed. An announcement date does not establish a closing date, so it can still be abandoned or reshaped by a regulator, and the existing contract usually still governs your account. A closed deal has already transferred control. Both are recorded with the vendor page the date was read from, so you can check the current position yourself.
Is an old founding year a risk?
Founding year alone does not establish financial health or product continuity. Revenue, support commitments and operational capacity require separate evidence. The founding years in this catalogue span a wide range, and the oldest entries belong to infrastructure companies for whom the gateway is one line in a broader platform.
What does a blank founding year or star count mean?
Two different things. A blank founding year is a disclosure gap: the company exists and simply has not published the date in a place we could cite, so it is a question for a sales call rather than a finding. A blank star count is structural, because a proprietary product has no public repository to have stars in the first place. Neither is evidence of anything about the product.
What is the practical continuity plan for a managed-only gateway?
Keep the integration replaceable rather than keeping a copy of the software, because there is no copy to keep. In practice that means holding your own provider keys where the product supports it, exporting usage and spend data on a schedule, keeping routing and budget rules in a file you own rather than only in the vendor dashboard, and knowing which alternative you would move to before you need it. None of that assumes the vendor is at risk; it is the same work you would do for any dependency in the request path.