Every conversation about AI dependency I sit in is about where the data lives and who the supplier is. It is rarely about the question that matters most in practice: how much work is it to switch?
That is an architectural question, and the answer is usually scattered through a codebase. If model calls sit in forty places in your system, switching is a renovation. Put one pass-through in between, and it is a setting.
This is part three of a series that started with what survives when a component disappears. Part two was about liability when your agent says something untrue. This part is about the one piece of tooling in the whole run that you can build in an afternoon.
A price tag that gives something away
On 16 August 2026 it was reported that Stripe is acquiring OpenRouter for more than 7 billion dollars. OpenRouter is a pass-through: a single access point with hundreds of models behind it, so a developer can pick whichever model fits the task best or comes cheapest.
What makes the number interesting is the ratio. According to the reporting, OpenRouter raised money three months earlier at a valuation of around 1.3 billion dollars. More than five times that, inside a quarter.
The speakers in the webinar that set off this series mentioned it in passing, as evidence that gateways are becoming a real layer in the stack. That is the right conclusion, just not the only one. A payments company is buying the place model traffic passes through. That is the same move as owning the till rather than the shop.
What a gateway actually does
The comparison they used clarified it for me. When you build a web shop, you do not write code that talks to the card networks directly. You put a party in between to handle it. An AI gateway is the same idea, for model traffic.
Four things fall into place with it.
Switching becomes a setting. If price, terms or geopolitics change, you point traffic at another model, or at something you host yourself. Your product does not change with it.
You can see what is happening. All traffic passes one point, so you know which teams consume what. Without a gateway that is a sum of invoices after the fact.
You can steer on cost. Heavy tasks to a large model, routine work to a small or cheaper one, and you can move that around without touching code.
Controls live in one place. Redaction, logging, limits: all in the pass-through instead of scattered forty times over.
The first one is why this belongs in a series about sovereignty. In part one I called sovereignty a dial rather than a switch. A gateway is the component that lets the dial actually turn. Without it, sovereignty is an opinion; with it, it is a five-minute action.
I do not have that switch
This site has no gateway. My text work runs straight through Anthropic, my image work runs locally on my own laptop, and there is nothing in between that reroutes anything.
For images that does not matter, because there is no supplier to move away from. For text it is exactly the weak spot part one turned up: my output is portable, my way of working is not.
And still I am not building one. A gateway costs maintenance, and the payoff is in switching between models you actually switch between. I do not switch. For one person with one workflow, the pass-through is a middle layer solving something I do not have. The moment I ran several models side by side, or built something other people leaned on, that answer changes.
That is not a recommendation to skip it. It is an example of how the third question from part one plays out when you answer it honestly: sometimes the answer is that the risk exists and you accept it, with reasons.
The caveat
A gateway does not remove dependency, it relocates it. You depend less on one model provider and more on whoever runs the pass-through. That is a gain as long as that party is cheap to replace. For a pass-through that was just bought by a payments company for 7 billion dollars, that is an assumption worth saying out loud rather than holding silently.
Switchability is not equivalence. You can point traffic at another model, but your prompts, your agreements about output and your whole sense of what good looks like were built on the model you had. Flipping the switch is technically trivial and editorially not. People who say they can switch within a day usually mean the call works within a day.
And there is a temptation buried in the measurability. Once all traffic passes one point, the cheapest route is visible and so is the most expensive. That is useful for a budget, and it turns every substantive choice into a cost you either defend or drop. “Which model fits here best” and “which model is cheapest here” start to look like the same question, and they are not.
What I am doing
I keep the spot open without building the layer. Concretely: my calls sit in scripts rather than scattered through the site, my articles are markdown in git rather than living inside a service, and the instructions I work with are ordinary text files I can carry to any model.
That is the cheap half of switchability. The expensive half, working out how a different model behaves, stays where it is, and I cannot organise it away.
For the work I deal with during the day my advice differs from what I do for myself. As soon as there are several teams, several models, or an application that citizens or customers rely on, the pass-through is the cheapest insurance available.
Frequently asked questions
Is a gateway the same thing as an API proxy?
Technically it looks similar, and the difference is what you put in it. A proxy passes traffic along. A gateway decides where traffic goes, tracks consumption, applies redaction or limits, and turns model choice into a setting rather than code.
Do you need an external service for this?
No. For a single team a thin layer of your own is often enough: one place in your code that all calls pass through. External services get interesting once you want per-task routing, per-team billing or failover between providers.
Does this make me independent of American providers?
Only if you also put a non-American alternative behind it and use it occasionally. A gateway with nothing but American models behind it does not change your dependency, it only makes it visible and switchable.
Why would a payments company buy this?
They have not explained it, and I am not going to guess. What you can establish is what was bought: the point where model traffic and settlement meet.
Sources
- Stripe’s acquisition of OpenRouter for over 7 billion dollars, reported 16 August 2026, accessed 20 August 2026 — techcrunch.com
- OpenRouter valuation and background, accessed 20 August 2026 — techstartups.com
- Webinar “Sovereign AI in the enterprise: from data residency to operational control”, Freeday, 20 August 2026 — linkedin.com/events
Checked on 20 August 2026. The acquisition and the figure of more than 7 billion dollars appear in several independent reports from 16 and 17 August. The earlier valuation of around 1.3 billion dollars and the ratio of more than five times come from that reporting rather than from a statement by the companies; at the time of writing I have seen no confirmation from Stripe or OpenRouter naming those numbers. The comparison with payment providers and the four benefits of a gateway come from the webinar, which I read through the caption file supplied with it; that file carries machine errors in personal and company names, so no direct quotes appear here. Why Stripe is making this acquisition has not been explained by the company, so no explanation for it appears above. I also could not verify how many organisations actually run a gateway: no figure was given and I found no reliable source for one.