What to do when the middle layer of your AI stack gets bought

You did the sensible thing. Instead of opening accounts with four model providers, storing four keys, reconciling four invoices and writing your own failover when one of them has a bad afternoon, you pointed your app at a single endpoint and let something in the middle decide which model actually answers. One key, one bill, one place to change the model name. For a solo operator or a two-person team, that is not laziness. It is the correct trade.

Then the thing in the middle gets bought, or repriced, or adds a fee, or quietly changes which provider serves your requests by default, and you discover you never asked what you would do about it. This guide is about that layer specifically: routers, aggregators and gateways that sit between your code and the model. It is not about picking a model, and it is not for you if your AI use is a chat subscription with no API keys behind it, or if your employer’s contract already fixes which provider you may call. It is for the case where a meaningful share of your production traffic goes through an intermediary you do not own.

The middle layer is a convenience, not a contract

Start by being precise about what you bought. A router gives you one API surface over many models, one billing relationship, and automatic failover when a provider stalls. What it does not give you is a guarantee that any particular model, price or provider stays where it is. You are renting an abstraction, and abstractions are cheap to rent and expensive to assume.

The clearest recent illustration is OpenRouter. On 19 August 2026 Stripe announced it had agreed to acquire it, describing a service that “helps businesses route and optimize token usage across 400+ models from more than 80 providers” and already used “by the likes of NVIDIA, Zoom, and Lovable” [1]. Stripe’s framing is that the two companies together “will be able to help companies manage both sides of profitability in the AI era: maximizing revenue and efficacy while minimizing costs” [1]. Alex Atallah, OpenRouter’s cofounder and chief executive, is quoted saying that “Stripe has spent over a decade building trusted, neutral infrastructure for businesses, and OpenRouter was built on the same philosophy”, and that “intelligence will be multi-model: no single model will be optimal for every task, and developers need a neutral layer to orchestrate and manage them all” [1].

Read what is there and also what is not. The announcement makes no statement about whether pricing, the API surface or the provider mix continue unchanged [1]. That is normal for an acquisition announcement and it is not evidence of bad intent. It is simply the shape of the risk: the people who set the roadmap changed, and the document telling you so is a press release, not an SLA. Nothing breaks on the day. The question is what you do in the two to four quarters afterwards, when incentives, not intentions, decide the roadmap.

The switching cost is the one number you can actually measure

The good news is that the industry converged on one wire format, and that convergence is what makes your exit cheap. OpenRouter describes itself as “a drop-in replacement for OpenAI” and implements “the OpenAI API specification for /completions and /chat/completions endpoints” [2]. The major labs point the other way too. Anthropic documents using the OpenAI SDK against base_url="https://api.anthropic.com/v1/" with a Claude key and a model string such as claude-opus-5 [6]. Google documents the same trick at https://generativelanguage.googleapis.com/v1beta/openai/, where the only changes are the key, the base URL and the model name [7].

So in the happy case, moving off a router is three lines. In the real case, it is three lines plus the features you did not notice you were using. Anthropic is blunt about the limits of its compatibility layer: “This compatibility layer is primarily intended to test and compare model capabilities, and is not considered a long-term or production-ready solution for most use cases” [6]. Through that path the strict parameter for function calling is ignored, prompt caching is not supported, and thinking output is not returned [6]. Google says “support for the OpenAI libraries is still in beta while we extend feature support”, notes that reasoning cannot be turned off for Gemini 2.5 Pro or the 3-series models, and requires extra_body for Gemini-specific features such as cached content, thinking configuration and safety settings [7].

The practical reading is that the OpenAI shape gets you a working request on day one and the native SDK gets you the features you built on. Both are worth knowing. Your switching cost is not “can I get a response from another provider”, which is almost always yes within an hour. It is “which of prompt caching, structured outputs, tool schemas, batching and reasoning controls am I relying on, and does the destination expose them the same way”.

The fees you pay the middle layer are not the token prices

Routers usually do not mark up inference. OpenRouter states plainly that “we pass through the pricing of the underlying providers without any markup, so you pay the same rate as you would directly with the provider” [2]. That sentence is true and it is also not the whole bill.

The money shows up around the tokens. Buying credits with a card carries a 5.5% fee with a $0.80 minimum, and 5% for crypto [2]. OpenRouter reserves the right to expire unused credits one year after purchase, refunds on unused credits may be requested within 24 hours of the transaction, and cryptocurrency payments are never refundable [2]. If you bring your own provider keys so that inference bills to your own account, the router still charges “5% of what the same model/provider would cost normally on OpenRouter”, deducted from your credits [5], with a monthly allowance before that fee kicks in of $25,000 on pay-as-you-go and $200,000 on the enterprise tier [2].

None of that is unreasonable for the work being done. It is worth writing down as a percentage of your annual model spend, because that percentage is the honest price of the convenience, and it is the number that moves when ownership changes. A payments company owning a token router has an obvious, legible interest in the payment side of the flow, and the payment side is exactly where these fees live.

Default routing decides more than you think

The other thing you delegated is which provider serves a given request. OpenRouter’s default strategy is to “Prioritize providers that have not seen significant outages in the last 30 seconds” and then, among stable candidates, to “look at the lowest-cost candidates and select one weighted by inverse square of the price” [4]. Fallbacks are on by default via allow_fallbacks, and setting order makes the router try your named providers one at a time instead [4].

That default is sensible and it is also a policy decision made on your behalf every request. It matters most for data handling. OpenRouter says “we do zero logging of your prompts/completions, even if an error occurs, unless you opt-in to logging them”, and it offers a 1% discount to those who do opt in [2]. Separately, if you opt out of training in account settings, “OpenRouter will not route to providers that train”, with distinct toggles for paid and free models, and you “can restrict individual requests to only use providers with a certain data policy” [3]. Those are real controls. They are also settings, which means they are things a future owner can redesign, and things a new engineer on your team can flip without understanding what they turn off.

Notice periods are the real service level

Ask who is contractually obliged to tell you before something under you moves. The model labs publish this. Anthropic commits to “at least 60 days’ notice before model retirement for publicly released models” and publishes tentative retirement dates per model, with claude-haiku-4-5-20251001 listed as not sooner than 15 October 2026 and claude-opus-5 as not sooner than 24 July 2027 [8]. That is a schedule you can plan against.

An intermediary inherits none of that automatically on your behalf. It can pass a deprecation through, absorb it by silently mapping an alias to a successor, or remove a route because a provider relationship ended. Whichever it does, you learn about it through a changelog you are not reading, or through a support ticket about output that got subtly worse. The fix is not to distrust the router. It is to subscribe to the deprecation pages of the two or three labs whose models you actually depend on, and to log the exact model and provider that served each request so that “it changed on 14 March” is a query rather than a memory.

Run the swap once, on a day you choose

An exit plan you have never executed is a belief, not a plan. Spend an afternoon making it a fact. Hold a direct API key with at least one provider you depend on, funded and tested, even if it serves 1% of traffic. Put the base URL, key and model string in configuration rather than in code, so switching is an environment change and not a deploy. Keep your prompts, evaluations and tool schemas in your own repository, because those are the assets with real switching cost, and they are the ones people leave inside a vendor’s console. Then send real production traffic direct for an hour and see what breaks. Usually it is one of the four things the compatibility notes warned about: caching, tool-call strictness, reasoning controls or structured output [6][7].

Do it while nothing is wrong. The point of the drill is not that you expect the router to fail you. It is that a tested fallback converts every future announcement, price change and acquisition from an emergency into a decision you make on a Tuesday with a spreadsheet.

What a change of ownership does and does not change

It does not change your latency, your prices or your model catalogue this quarter. The people who tell you otherwise are selling migration services. What it does change is the answer to “who decides”, and that answer propagates on a slow clock: which providers get preferential terms, which features get built, where fees land, and how aggressively the free and cheap tiers are defended when they stop being a growth line and start being a cost line.

The durable lesson is not about any one deal. It is that every layer of this stack tends toward consolidation, because routing is genuinely valuable and neutrality is genuinely hard to fund. Whenever a service you depend on is bought by a larger company with an adjacent business, you get a free reminder to check whether your dependency is reversible. Take the reminder and skip the panic.

What still goes wrong

The exit drill tests the request path, not the economics. If you move off a router to direct provider accounts, you take back the work the router was doing: separate invoices, separate rate limits, your own retry and failover logic, and a real chance that your first outage is handled worse than the router handled it. Plenty of small teams should stay exactly where they are and simply know the cost of leaving. Knowing is most of the value.

The second failure is subtler. Portability at the API layer does not give you portability of behaviour. A prompt tuned against one model through one router’s defaults will not produce identical output when pointed at another provider, even at the same nominal model, and the compatibility layers themselves warn that some controls are absent or in beta [6][7]. Without a small evaluation set you can run on demand, you will not notice the drift until a customer does.

Finally, the fee and policy numbers in this guide are from vendor documentation fetched on 4 September 2026 [1][2][3][4][5][6][7][8]. Fees, allowances, default routing behaviour and data toggles are exactly the sort of thing that changes after an acquisition, which is the entire point. Check the current pages before you make a decision that depends on a specific percentage.