What is AI model routing?

It's the layer that decides which model — and often which host of that model — actually serves a given request. You write your application against one endpoint, and the router picks the model behind it at call time. The reason it exists is real: model prices, speed and availability change weekly, and nobody wants to redeploy code every time a cheaper option appears. The reason it's a problem is that the pick is a business decision. Which model handles a pricing question, a clinical summary or a contract clause has cost, latency, accuracy and data-residency consequences. In most stacks that decision is not written down anywhere. It's a vendor default.

Why did Stripe buy OpenRouter?

Bloomberg reported on 16 August 2026 that Stripe had finalized a deal to acquire OpenRouter for more than $7 billion, picked up the same day by Fortune, TechCrunch and SiliconANGLE. Neither company confirmed it — Stripe said it doesn't comment on rumors or speculation and OpenRouter declined to comment. The reported figure is more than five times the $1.3 billion valuation OpenRouter raised at in May 2026, about three months earlier. OpenRouter said in May that it serves 8 million developers across more than 400 models. The strategic read is that Stripe is buying the metering and switching point of model consumption — the place where you can see, per request, what ran and what it cost. That is a payments company's natural habitat, and it tells you which layer the market thinks is valuable.

Is AI model routing a compliance or security risk?

It's an unmanaged dependency, which is the precondition for both. Three specific exposures. First, jurisdiction: if the router can fail over to another host of the same model, the physical location processing your data can change per request unless you've pinned it. Second, evidence: when a regulator or a customer asks which system produced a given output, the answer has to come from your logs, and the model identifier is only there if you stored it. Third, change control: a model swap alters behaviour on the same input, but because no ticket was filed and no version was bumped, it won't appear in any change record you'd consult during an incident review. None of that makes gateways wrong to use. It makes them a thing to configure deliberately rather than accept as shipped.

Should we use an AI gateway or call the model providers directly?

Use the gateway. Rewriting integration code every time the market moves is a worse problem, and the abstraction is genuinely good engineering. The mistake isn't the gateway — it's treating its defaults as infrastructure config rather than as policy. Direct calls give you determinism and cost you agility; a gateway gives you agility and costs you determinism unless you pin it. The working version is a gateway with an explicit routing policy: named model per task class, a stated fallback order, a cost ceiling, and the served model identifier written to your own logs on every call.

What should an AI model routing policy actually specify?

Five things, and it fits on one page. One, the task classes you run and the named model for each — not a tier, a name. Two, the approved fallback order per class, and which classes are allowed no fallback at all because a substitution would be materially different. Three, the cost ceiling per class and what happens when it's hit: degrade, queue, or fail loudly. Four, the logging requirement — the served model identifier, provider and cost stored in your systems, not only in the vendor's dashboard. Five, the review trigger: who gets told when the mix shifts more than an agreed threshold, and how often the policy is revisited. If you can't produce that page, your routing policy is whatever your gateway shipped with.

Enterprise AI

AI model routing is a business rule nobody wrote down

AI model routing decides which model does your work. Stripe reportedly paid over $7B for that switch — and in most stacks a vendor default is setting the policy.

Alexey Yushkin August 17, 2026 8 min read

Somewhere in your stack, something chose which model answered a customer this morning. AI model routing is the layer that made the choice, and in most companies it isn’t a decision anyone made — it’s a default that came with the gateway. Stripe reportedly just paid more than $7 billion for the company that owns that switch for eight million developers, which is a good moment to ask who’s been setting the policy.

TL;DR: Model routing decides which model does your work, and it now changes weekly on its own. OpenRouter’s documented default picks a provider by weighted random draw on the inverse square of price, dropping anyone with an outage in the last 30 seconds; its auto router ranks models by what the wider community spent on that task type over a trailing seven days. Vercel’s gateway telemetry for July 2026 shows 81% of tokens ran on models that weren’t on the gateway six months earlier. That’s a dependency changing under production workloads with no ticket, no version bump, and — unless you log the served model — no record.

What the $7 billion is actually for

On 16 August 2026, Bloomberg reported that Stripe had finalized a deal to buy OpenRouter for more than $7 billion. Fortune, TechCrunch and SiliconANGLE all carried it that day. Neither company confirmed: Stripe said it doesn’t comment on rumors or speculation, and OpenRouter declined to comment. Treat the number as reported, not announced.

Reported or not, the shape of the deal is the interesting part. OpenRouter raised at a $1.3 billion valuation in May 2026 and said at the time that it served 8 million developers across more than 400 models. Roughly three months later the reported price is over five times that. What sits in between is not a model, not a chip, and not a dataset. It’s a switch, plus the meter attached to it.

A payments company buying the meter is not a surprise. Metering is what payments companies are for. The signal for everyone else is that the industry has now put a price on the layer that decides which model runs your work — a layer most of the companies using it have never configured.

The default is a weighted coin flip

This is documented, publicly, by the vendor. It’s worth reading rather than assuming.

For provider routing — where several hosts serve the same open model — OpenRouter’s documentation says the default is to load balance across providers, prioritizing price. Mechanically: first it deprioritizes providers that have seen significant outages in the last 30 seconds, then it selects among the remainder by weighted randomization on the inverse square of the price. The docs give the example directly — a provider at $1 per million tokens is nine times likelier to be chosen than one at $3. Fallbacks to the remaining providers are enabled by default.

Read that as an operator and it says something specific. The host that processed your request was chosen by a random draw, weighted by price, filtered on a thirty-second availability window. Not wrong. Genuinely sensible engineering for resilience. But it is a decision about where your data goes and what your run costs, and it is being made per request, by a rule your organization did not write.

The auto router goes further, and it’s the part I’d read aloud in a governance meeting. It classifies your prompt into roughly thirty task categories, then ranks candidate models by what the OpenRouter community actually spent on for that task type over a trailing seven-day window, applies your cost tier, and takes the top candidate. It re-ranks from scratch on every turn of a conversation.

So the model handling your clause review is selected, in part, by what strangers spent money on last week.

I want to be fair to the design. That heuristic is probably better than most teams’ manual choice, because it aggregates real production behaviour instead of benchmark marketing. The problem isn’t quality. It’s that a policy input nobody in your building controls is now upstream of an output somebody in your building has to defend.

The market underneath moves faster than your change log

Vercel publishes monthly telemetry from its own AI Gateway. The August 2026 index, published 11 August and covering July, is the closest thing to a public read on what production traffic actually does.

Measure (July 2026, Vercel AI Gateway)	Figure
Tokens running on models not on the gateway six months earlier	81%
Teams over 10M tokens in both months that changed ≥10% of their model mix	3 in 4
Same cohort that changed ≥25% of their mix	3 in 5
Median team’s change in cost per token	−2.9%
Teams that stayed within 5% of where they started	1 in 6
Average price per token, month over month	−13.6%
Anthropic’s share of gateway spend / of tokens	65.1% / 30%
Anthropic’s average token price vs every other lab	4.4×
Open-weight models’ share of tokens / of spend	36% / ~8.6%

The first row is the one that should stop you. Four fifths of a month’s production tokens ran on models that weren’t even available on that gateway half a year ago. And the churn isn’t a market-level average that individual teams are insulated from — three in five high-volume teams personally rewrote a quarter of their model mix inside a single month. Only one team in six landed within five percent of where they started on cost.

That is a rate of change we’d never tolerate in any other dependency. Nobody swaps a database engine on 25% of their queries in a month without a migration plan. Here it happens through a config value, or through no action at all.

A price cut is a routing change

Google shipped Gemini 3.7 Flash on 13 August 2026, three weeks after 3.6 Flash. On Google’s own numbers, FrontierCode 1.1 went from 34.4% to 43.6% and DeepSWE v1.1 from 49.0% to 65.3% — vendor-reported, worth the usual discount, but not small. Introductory pricing is $0.75 per million input tokens and $3.75 output.

The line to circle is the expiry: that introductory price runs through 31 December 2026, and on 1 January 2027 it becomes $1.50 and $7.50. Double.

If your routing has any cost-sensitivity in it — and every default does — then on that date the ranking inputs change while nobody touches your system. The model that was the obvious pick in December is the expensive pick in January. Your traffic may move on New Year’s Day because a promotional period ended in a pricing table you never read.

This is the same failure shape as an integration with no data contract: the system keeps working right up until an upstream party changes something they were always free to change, and you find out from the invoice or the output, not from a notice.

The question you can’t answer at 9am

Something goes wrong. An agent quotes the wrong price, summarizes a contract badly, misroutes a ticket. The first question in any competent incident review is the same one it’s always been: what changed?

Most teams cannot answer it for model choice. They have the prompt, the output, the timestamp and the user. They don’t have the model identifier, because it wasn’t in the schema when they built the log table — the model was a constant then.

The small, annoying detail: the answer is right there and gets thrown away. OpenRouter’s response includes a model field showing which model actually served the request. One string. It arrives on every call and most applications never persist it, because the logging was written against the request, not the response. So the one breadcrumb that would let you reconstruct the decision is generated, returned, and dropped on the floor.

Same problem as the meter nobody owns, one layer up. There, the bill arrives with no way to attribute it to a process. Here, the behaviour changes with no way to attribute it to a version.

The working version

None of this is an argument against gateways. Rewriting integration code every time the market moves is a worse problem, and the abstraction is good engineering. The argument is against inheriting a policy instead of writing one.

Write the page. One page.

Name the model per task class — a name, not a tier. Your general drafting can float; the thing that touches pricing, clinical text, or a contract obligation gets pinned, and pinned means pinned, including the provider. Then state the fallback order per class, and be willing to say that some classes get no fallback at all, because a silent substitution there is materially different work rather than the same work at a different price. Set the cost ceiling and say what happens when it’s hit — degrade, queue, or fail loudly, but decide, because the default is “spend it.”

Then log the served model identifier, provider and cost into your own systems on every call. Not the vendor’s dashboard. Yours, next to the output, in the same row, so a question about a decision is a query rather than a project. This is the cheapest item on the list and the one that pays every time something goes wrong.

And pick a threshold that triggers a human review — mix shifts more than some percentage in a month, someone gets told. Given that three in five high-volume teams moved a quarter of their mix in July, an unwatched threshold is not a theoretical risk.

That’s a page. It takes an afternoon. The reason it doesn’t exist in most companies isn’t difficulty — it’s that model choice arrived looking like a configuration setting, and configuration settings don’t get owners. Same story as shadow AI: not a policy failure, an inventory failure. You can’t govern a decision you haven’t noticed you’re making.

The operator read

The market just valued the switch at seven billion dollars. Inside most companies, the same switch is set to whatever came in the box.

A model swap changes the thing that produces your output. Treat it that way and a gateway is exactly what it should be: agility you control. Skip it, and you’ve handed a business rule to a weighted average of other people’s spending. That’s a fine way to pick a restaurant.

Ask your team which model answered a customer yesterday. If the room goes quiet, that’s the layer I work on.

FAQ

What is AI model routing?: It's the layer that decides which model — and often which host of that model — actually serves a given request. You write your application against one endpoint, and the router picks the model behind it at call time. The reason it exists is real: model prices, speed and availability change weekly, and nobody wants to redeploy code every time a cheaper option appears. The reason it's a problem is that the pick is a business decision. Which model handles a pricing question, a clinical summary or a contract clause has cost, latency, accuracy and data-residency consequences. In most stacks that decision is not written down anywhere. It's a vendor default.
How does an AI gateway decide which model runs my request?: It depends on the mode, and both defaults are worth reading. For provider routing — several hosts serving the same model — OpenRouter's documentation states that its default behavior is to load balance across providers prioritizing price: it first drops providers that have seen significant outages in the last 30 seconds, then picks among the rest by weighted randomization on the inverse square of price. At that weighting a provider at $1 per million tokens is nine times likelier to be picked than one at $3. Fallbacks to the remaining providers are on by default. For model routing across different models, OpenRouter's auto router classifies the prompt into roughly 30 task categories, then ranks candidate models by what the OpenRouter community actually spent on for that task type over a trailing seven-day window, applies your cost tier, and picks the top candidate. It re-ranks from scratch on every turn.
Why did Stripe buy OpenRouter?: Bloomberg reported on 16 August 2026 that Stripe had finalized a deal to acquire OpenRouter for more than $7 billion, picked up the same day by Fortune, TechCrunch and SiliconANGLE. Neither company confirmed it — Stripe said it doesn't comment on rumors or speculation and OpenRouter declined to comment. The reported figure is more than five times the $1.3 billion valuation OpenRouter raised at in May 2026, about three months earlier. OpenRouter said in May that it serves 8 million developers across more than 400 models. The strategic read is that Stripe is buying the metering and switching point of model consumption — the place where you can see, per request, what ran and what it cost. That is a payments company's natural habitat, and it tells you which layer the market thinks is valuable.
Is AI model routing a compliance or security risk?: It's an unmanaged dependency, which is the precondition for both. Three specific exposures. First, jurisdiction: if the router can fail over to another host of the same model, the physical location processing your data can change per request unless you've pinned it. Second, evidence: when a regulator or a customer asks which system produced a given output, the answer has to come from your logs, and the model identifier is only there if you stored it. Third, change control: a model swap alters behaviour on the same input, but because no ticket was filed and no version was bumped, it won't appear in any change record you'd consult during an incident review. None of that makes gateways wrong to use. It makes them a thing to configure deliberately rather than accept as shipped.
Should we use an AI gateway or call the model providers directly?: Use the gateway. Rewriting integration code every time the market moves is a worse problem, and the abstraction is genuinely good engineering. The mistake isn't the gateway — it's treating its defaults as infrastructure config rather than as policy. Direct calls give you determinism and cost you agility; a gateway gives you agility and costs you determinism unless you pin it. The working version is a gateway with an explicit routing policy: named model per task class, a stated fallback order, a cost ceiling, and the served model identifier written to your own logs on every call.
What should an AI model routing policy actually specify?: Five things, and it fits on one page. One, the task classes you run and the named model for each — not a tier, a name. Two, the approved fallback order per class, and which classes are allowed no fallback at all because a substitution would be materially different. Three, the cost ceiling per class and what happens when it's hit: degrade, queue, or fail loudly. Four, the logging requirement — the served model identifier, provider and cost stored in your systems, not only in the vendor's dashboard. Five, the review trigger: who gets told when the mix shifts more than an agreed threshold, and how often the policy is revisited. If you can't produce that page, your routing policy is whatever your gateway shipped with.