The price sits on the gateway
TechCrunch, following a Bloomberg report on Sunday, says Stripe has finalised a deal to buy OpenRouter for more than 7 billion dollars, and that Stripe would not comment on rumours or speculation. OpenRouter routes requests to more than 400 models through a single interface, says it has 8 million users, and was valued at 1.3 billion dollars in a May round that raised 113 million dollars. Nothing here is a closed transaction yet; it is a report about one, and the price is the part worth holding on to.[1]
Two days ago in this column I argued that the August price cuts stopped at the middle of each line-up, so the substitution they open up stays bounded, and that the number deciding it for a team is cost per completed task rather than the advertised token price. A router such as OpenRouter is where that bounded substitution actually happens: it holds the switch a team throws once a mid-tier model turns out to finish its own tasks for less. Putting a price on the switch does not close the question I left open; it changes whose hand is on it.[1], [3]
Which layer takes over the dependency?
Map the request. A team that integrates four vendors directly carries four authentication schemes, four rate-limit regimes and four billing lines; a router collapses that into one interface, and the four vendors behind it become interchangeable parts. That is a real gain, and it is the gain OpenRouter sells: 400 models, one access point. The cost shows up on the other side of the same interface. One operator now sees which model a request went to, decides the fallback order when a vendor fails, and prices the traffic. Interchangeability among models is paid for with concentration at the single point the traffic passes through.[1]
The same 24 hours supplied the concrete case. BleepingComputer reported that Anthropic began investigating sign-in failures at 21:58 UTC on Sunday; Anthropic's status page lists claude.ai, platform.claude.com, the Claude API, Claude Code and Claude Cowork among the affected components, and the incident was resolved at 22:34 UTC. Thirty-six minutes is short, and a team routing through a gateway could have moved that traffic elsewhere without touching code. The inference I draw is that the value of a router rises with exactly this kind of event, and that the same event marks the place a router cannot cover; when the failing component is the gateway itself, there is no second gateway configured behind it. Another reading is fair: most teams may never have exercised a failover here at all, and the router's real appeal may be billing and model choice rather than availability. The available evidence does not separate the two.[2], [1]
What should a builder watch?
There is a signal that separates the two outcomes, and it needs nobody's forecast. If the deal closes and OpenRouter keeps publishing an unchanged model list and per-model pricing while a documented path off the gateway stays open, switching cost has not moved and the escape hatch survives its new owner. If instead routing rules, model availability or pricing start to depend on Stripe's billing relationship, the layer a builder adopted in order to avoid dependence has become the dependence. I would put the useful review point at the end of the first quarter after any close, because pricing pages rather than press statements are what show the change.[1]