Stripe agreed to acquire OpenRouter, the startup that routes API calls across more than 400 AI models for roughly eight million developers, for more than $7 billion. That number is not the interesting part. What is interesting is what it says about where model routing sits in the stack now. Two years ago, a model gateway was a weekend project: a thin proxy that let a team swap between two or three providers without rewriting call sites. Today it is a category a payments company will spend billions of dollars to own, because whoever sits between an application and the model market controls the metering, the routing, and increasingly the billing for one of the fastest-growing line items on a technology budget.
For teams already running AI features in production, this is the moment the question stops being theoretical. If your application calls a single provider's SDK directly from a dozen places in the codebase, you already have the problem a gateway solves, you just have not paid the bill for it yet. That bill comes due the first time a provider has an outage during a product launch, the first time a finance leader asks why the AI line item jumped 40% in a month with no matching usage increase, or the first time a better, cheaper model ships and migrating to it means touching every call site in the application. A model gateway is the architectural answer to all three problems at once, and the acquisition is a signal that the market has decided this is infrastructure, not a nice-to-have.
Strip away the marketing and a model gateway is a reverse proxy with opinions. It sits between your application and every model provider you use, and it does the translation, routing, and bookkeeping work that would otherwise be scattered across your codebase. Instead of your application code knowing that provider A wants a slightly different message format than provider B, or that provider C throttles you at a certain rate, the gateway absorbs that complexity and exposes one consistent interface to everything upstream of it.
Every team we talk to about this ends up choosing between three real options, and the right answer depends on how much of your traffic is AI-driven and how sensitive your data is. The first option is a hosted gateway such as OpenRouter, Portkey, or Martian, where you get provider breadth and routing intelligence on day one in exchange for every prompt and response passing through a third party's infrastructure. The second is a self-hosted open source gateway such as LiteLLM or Kong's AI Gateway, which gives you the same routing and metering patterns while keeping traffic inside your own network boundary, at the cost of running and patching another piece of infrastructure yourself. The third is the native routing layer offered by a cloud provider, such as cross-region inference on Bedrock or the gateway features inside Azure AI Foundry, which trades flexibility for tight integration with infrastructure you already operate.
The Stripe acquisition sharpens this decision rather than settling it. A hosted gateway that also happens to be owned by a billing and payments company means your model traffic and your AI spend data now live inside the same corporate entity, which is either a convenience or a concentration risk depending on your industry and your contracts. Teams handling regulated data, or anyone who has ever had to answer a data residency question from a customer's security team, should read that fact carefully before routing production traffic through any hosted gateway, regardless of who owns it.
Whichever option you choose, the patterns that actually earn their keep in production are consistent, and they map closely to lessons we have seen play out in cost and reliability work across client systems.
The part of this deal that deserves more scrutiny than it has gotten is what happens when the company routing your model traffic is the same company processing your payments. A gateway sees the content of every prompt and response that passes through it, which makes it one of the most sensitive aggregation points in a modern AI stack, arguably more sensitive than the database, because it sees the raw inputs and outputs before any application-level redaction happens. Folding that into a billing and payments platform raises legitimate questions about data handling boundaries, about whether routing decisions could ever be influenced by commercial arrangements with specific model providers, and about long-term pricing once a category consolidates around fewer, larger vendors.
None of that means avoid hosted gateways outright. It means the same governance rigour that applies to a payment processor or a cloud vendor now needs to apply to whichever company sits in front of your model calls. Read the data processing agreement. Confirm where prompts and responses are logged and for how long. Build your integration against an abstraction you control, so that if pricing or terms change after a future acquisition, migrating to a different gateway is a configuration change rather than a rewrite. The teams that will handle the next few years of consolidation in this space well are the ones who treated the gateway as infrastructure worth governing from the start, not as a convenience they bolted on.
The architecture question a model gateway answers was always going to matter once AI spend became a real line item, and a $7 billion acquisition just moved the timeline up for a lot of teams that were planning to deal with it later. Start by auditing how many places in your codebase call a model provider directly today, because that number is a reasonable proxy for how much pain a provider outage or a pricing change would cause you. If AI is a small, experimental part of your product, a hosted gateway will get you most of the benefit with the least engineering effort. If it is core to what you sell, the operational discipline of running your own routing layer, with cost attribution and fallback chains built in from day one, pays for itself the first time a provider has a bad week.
If you are weighing that build versus buy decision against a real budget and a real deadline, that assessment, including where a gateway fits your specific provider mix and compliance requirements, is exactly the kind of scoping work we do as part of our AI infrastructure consultancy. Start with an honest inventory of where your model calls live today, and let that inventory decide how much gateway you actually need.
Before we start, please share a few details so we can follow up with you.
End this conversation? Your chat will be emailed to us.