Stripe spent more than $7 billion to buy OpenRouter, but this analysis argues that token routing by itself would not justify that price. Routing logic can be copied. Cloud vendors can bundle it into infrastructure companies already buy. Even a 5.5% cut is unlikely to remain durable on its own.
So what did Stripe actually buy? Not simply the ability to decide which model gets a request, the article says, but a vantage point over transaction flows across models and providers. QED Venture partner Sandeep Patil described the idea after the deal in fintech terms: being inside the flow is not the moat; seeing the flow, and knowing what to do next because of that view, is.
The piece argues that payments spent two decades proving that point, and token markets are starting to follow the same path. Its focus is not technology in the narrow sense, but finance: the same layers that grew around the dollar over twenty years are beginning to form around tokens — routing and procurement, data and distribution, success rates and risk controls, standards and assembly, accounts, credit and exchange. Moving tokens is only a flow business. The bigger value sits above the flow.
Routing exists because the market has fragmented
Token routing, in this telling, is a response to a fragmented, many-to-many AI token market. Applications often need to tune across several models. Those models are hosted by multiple providers. Prices move constantly, and the best option depends on the task. Open-source models are closing in on closed-source offerings, while frontier models keep moving the frontier again. The article argues that this instability is not going away soon.
That makes it increasingly costly to lock an application into one provider. As the piece puts it, no application wants to rebuild its stack every time the best model changes.
Finance has dealt with fragmentation before by inserting shared infrastructure in the middle: SWIFT between banks, card networks between merchants and issuers, payment gateways that abstract the complexity of underlying rails. Token routing is following the same pattern, the article says.
It is also more than traffic steering. Every routing decision is a procurement decision: which model handles the job, which provider serves it, what price is paid, and what quality threshold counts as acceptable. After billions of requests, a router ends up holding a ledger of model consumption.
But routing alone is not enough. In simple use cases, switching routers may be little more than changing a base URL. Routing logic is reproducible. Cloud vendors can bundle it, and rivals can pass through model pricing at cost. Production environments are harder: compliance, data residency, caching, observability, SDKs, billing and privacy all become part of the switching burden.
Distribution and integration come before data
The article uses Stripe’s own history as a comparison. Stripe’s later strength did not come from the payment rail itself. It came from becoming the default choice for developers. Distribution is a moat.
That relationship is often stated backwards, the author writes. It is not that data leads to integration. A company gets integrated first, and only then does the data appear.
On the token routing side, the clearest example is OpenRouter’s model leaderboard. Which models are gaining usage, which are losing it, where coding workloads are moving, and how long users take to switch after a price change — the article describes this as the only public dataset in the industry that shows usage across both models and providers.
That information is not especially useful for a single request. It does not make one prompt run better on the spot. But it turns OpenRouter into the market’s scoreboard, and a scoreboard has bargaining power.
Model providers cannot produce this view because they only see their own calls — one ledger, not the whole market. Cloud vendors can see infrastructure but not user intent. The only layer that can observe behavior across models is the routing layer.
That creates a loop: more traffic produces better observation, better observation improves routing, and better routing brings in more traffic. The article argues that this is more interesting than taking five points on token volume.
Even then, seeing the data is only an output of the position. It is not worth much on its own. Value depends on what a router is willing to do once it has that visibility, and what it is willing to absorb.
Smart routing shifts the focus from price to task completion
Early payment routing was mechanical. It sent money where it needed to go. The higher-value features came later: automatic retries after failures, switching to another provider after a decline, repeated message-field tuning, real-time fraud controls, and price comparisons across rails. Different labels, one goal — lift the success rate.
The article says token routing is moving through the same evolution, only with more difficulty and more upside. Dollar payments are binary: the payment arrives or it does not. Token-based AI work is not. Whether a task was completed, and whether it was completed well, requires another layer of judgment.
That ambiguity is exactly why higher success rates may be worth more in token markets than in payments.
The piece flags a common mistake here. As cheaper models improve, routing can start to look like a price-comparison engine that sends each request to the least expensive model that can do the work. But the article says that framing is wrong from the start. An AI task is not one inference. It is an agent process with planning, generation, verification, tool use, retries and error correction. If a cheaper model fails twice, it may cost more than a more expensive model that works once.
The right metric, then, is not cost per token. It is cost per successfully completed task. The article lists inference cost, retry cost, tool-use cost, verification, manual fallback, latency loss and failure loss. Add them up and divide by the number of successful tasks, and routing stops looking like a pricing engine.
Even that is only the beginning. Payments offer a harder lesson: whoever promises the success rate also absorbs the failure cost. Gateways took on work like authorization optimization because they could charge against success, and when something failed, the customer called the gateway rather than the underlying rail. Complexity and risk were built into the fee model. Customers paid a premium for certainty. The gateway earned that premium and carried the downside when things broke.
The article argues that smart routing in AI eventually points to the same place. The business is not sending requests to the cheapest model. The business is making sure the job gets done. Choosing a cheaper model is only a byproduct on the way there.
That is also why the routing layer is in the best position to productize optimization work that is still scattered across applications. Prompting, context management, parameters and speculative decoding are still largely implemented separately by each app. The author argues that these tasks belong at the gateway layer, and doing them well requires failure data across models and task types — something a single application does not have.
Risk control sits at the routing layer too
The article treats fraud and risk control as another capability that cannot be taken away by changing a base URL.
Stripe has said that roughly one-sixth of registrations by AI companies on its network involve multi-account arbitrage. OpenCode co-founder Dax Raad, as cited in the piece, said the company removed 7,013 fraudulent accounts in one cleanup and estimated that it was losing $400,000 a month.
A single model provider sees only its own losses. The routing layer can see the same actors opening accounts across several providers. The article compares that position to the way Stripe Radar emerged in payments.
The assembly layer exists because no single model owns the whole task
For the past three years, much of AI discussion has revolved around which model will win. Routing makes that question less important, the article argues.
As adoption deepens, coding may converge around one set of models, retrieval around another, customer service around another, and complex reasoning around yet another. One application may need to call them in sequence to finish a single job. At that point, the phrase “best model” starts to break down because no one task type defines the entire workload.
The more important implication is that no model provider can monopolize a complete task. Once tasks are inherently split across models, an assembly layer appears on its own. It is not taking share from the model layer. The model layer leaves that position open.
The article draws a parallel with financial services. Banks once bundled deposits, lending, payments and foreign exchange under one license. Over the past twenty years, fintech firms unbundled those pieces and then reassembled them. The license stayed at the bank. The profit moved to the assembly layer.
In the author’s comparison, model weights are like that license — scarce and expensive. But once several providers offer access to them, they become components. Citing Sandeep, the piece says that at this stage model routing stops looking like plumbing and starts looking like fintech. Metering, billing, risk controls, payment terms and reconciliation are fintech components.
From a meter to a balance sheet
The article then lays out five layers and compares them with Stripe’s product catalog. Its conclusion is that Stripe is rebuilding, around tokens, much the same structure it once built around dollars.
The left side of that structure was largely built internally by Stripe over time. The right side — Bridge, Privy, Metronome and OpenRouter — was bought. Same company, same shape. The first time, Stripe had to build because the shape was not obvious yet. The second time, the shape is already visible, and the race is about occupying the position first. In that sense, the acquisition bought time, not revenue.
Within that framework, the purchase of OpenRouter can be read as the purchase of a meter. The jump from that meter to a balance sheet is the final leap.
Start with accounts. The article says token balances today still look more like stored-value cards than full accounts: prepaid, non-transferable, not portable across platforms, and tied to a single issuer. But OpenRouter balances can already be spent across more than 400 models and dozens of providers, which moves them a step away from a closed loop.
Prepayment means the platform receives cash first and holds the float. Move one step further toward an open loop, the author writes, and the product begins to approach the definition of a stored-value payment instrument. Whether the platform wants to earn that float is ultimately a licensing question.
Then there is credit. The article says prepaid usage is only one part of the market; postpaid credit terms are also common. In examples the author says they have encountered, credit pricing falls between 1.5% and 2% a month, or about 20% to 27% annualized, roughly in line with credit cards. The piece frames that as the expected price of a market that still lacks mature credit infrastructure.
Spread compression, it argues, would first happen at the routing layer because only that layer can see who is opening repeated accounts across providers, whose usage curve is stable, and who simply arbitrages promotions and leaves. The article points to Stripe Capital as an earlier analogue.
Finally, there is exchange. OpenRouter spans more than 400 models, with separate prices for input, output and cache, and those prices move constantly. In that sense, every routing decision looks like a conversion. It resembles foreign exchange, the author says, but one thing is missing: there is no base currency. No model token can serve as the standard unit. So this is not really an FX market. It is a multilateral barter market for 400 goods, disguised as a single market by a unified API.
That leaves a business holding float on one side and accounts receivable on the other. The article says that is no longer the balance sheet of a developer-tools company. It looks like the balance sheet of a payments company. Tokens do the metering. Dollars do the accounting.
The real test is pricing by outcome
Payments took twenty years to build these five layers. Tokens may not need twenty years to get there.
That is why, in the author’s view, two of the hottest questions around model routing are slightly off target. One asks whether model performance will converge until routing is reduced to price comparison, pushing margins toward zero. The other asks whether independent routers can gather enough proprietary data to beat model vendors and cloud platforms that build routing in-house.
The first question is about survival. The second is about inventory. But the better test, the article argues, is this: when will a router dare to charge for completing a task, rather than take a cut by token, and put a price on certainty?
At that point, it stops being just a router.
The piece ends with a comparison. Oil has Platts. Credit has S&P. Neither touches the thing it measures: Platts does not produce oil, and S&P does not make loans. AI does not yet have an equivalent institution, the author writes, even though traffic has already reached 10 trillion requests a day.
The article closes with a disclaimer that it is an industry-structure analysis for discussion only and does not constitute investment or legal advice in any jurisdiction. Regulatory characterization, it says, depends on the latest statements by relevant authorities and the facts of specific cases. It also notes that some figures come from a single source and should be verified separately before citation.