Token routing is becoming a Fintech business

Stripe spent over seven billion to acquire OpenRouter, but just the token routing alone is certainly not worth that price: the routing logic is replicable, cloud vendors can package it, and a 5.5% cut is likely unsustainable.

So what exactly did Stripe buy? It's not about "which model to send the request to"; what it bought is a "God's eye view" that can see the flow across models and vendors. Sandeep Patil, a partner at QED Venture, described it more accurately from a fintech perspective after the deal:

Being in the flow itself is not a moat; being able to see the flow and thus knowing better than others what the next step should be is.

The payment industry has spent twenty years validating this statement, and now token needs to walk the same path again.

Therefore, this article aims to discuss not technology, but finance: the system that has grown around the dollar for twenty years is now growing again on token—routing and procurement, data and distribution, success rates and risk control, standards and assembly, account credit and foreign exchange.

Transporting token is merely a flow business, while the greater value lies above the flow.

1. Routing: First Solve Fragmentation

Token routing exists because the AI token market is becoming fragmented and a many-to-many market.

Applications need to tune several models simultaneously, with models hosted by multiple vendors, prices constantly changing, and optimal solutions differing for various tasks. Open source chasing closed source, cutting-edge models pushing the frontier forward, this instability will not disappear in the short term. Being tied to a single vendor is becoming less cost-effective—no application wants to rebuild its tech stack every time the optimal model changes.

The old method in financial markets for handling fragmentation is to insert a layer of shared infrastructure in between: SWIFT among banks, card organizations between merchants and issuing banks, payment gateways abstracting away the underlying complex channels.

Token routing follows the same path.

Moreover, it is not just about traffic scheduling; each routing decision is a procurement decision: which model to use, which vendor to serve, what price to pay, and what quality counts as passing. After accumulating a billion transactions, the routing party has a ledger of model consumption.

But routing alone is not enough.

In simple scenarios, switching routing vendors might just mean changing a base URL. The routing logic is replicable, cloud vendors can package it into the infrastructure that enterprises are already buying, and competitors can also pass through model prices at cost. The production environment is far from that simple; compliance, data residency, caching, observability, SDKs, billing, and privacy all need to be addressed.

2. Distribution and Integration: Data Only Exists After Integration

Stripe's later strength does not lie in the channels. It has become the default option for developers. Traffic distribution itself is a moat.

This statement is often reversed: it is not that data exists and then gets integrated; it is because it is first integrated that data comes into existence.

On the token routing side, the most direct evidence is the model leaderboard from OpenRouter. Which models are seeing increased usage, which are declining, where coding tasks are migrating, how long users take to switch when prices change—this is currently the only publicly available cross-model, cross-vendor usage data in the industry.

Interestingly, this data is almost useless for routing itself. It won't make any single request run more accurately. But it makes OpenRouter the scoreboard for this market, and scoreboards have bargaining power.

Model vendors cannot produce this data: they can only see their own calls, which is equivalent to only seeing their own ledger. Cloud vendors can see the infrastructure but not the intent.

The only place that can see the full picture of cross-model behavior is at the routing layer.

Thus, a cycle forms: more traffic leads to better observation, better observation improves routing, and better routing brings more traffic.

This is much more interesting than taking five points off the token.

Seeing is just the output of this layer; it is not inherently valuable; what is valuable is what one dares to do and what one can withstand after seeing.

3. Intelligent Routing: From Price Comparison to Guarantee

The earliest routing in payments was mechanical, merely sending money to where it needed to go. Later developments became more valuable: automatic retries on failures, switching to the next vendor if one declines, repeatedly optimizing fields in reports, real-time risk control interception, and price comparison among several channels for the same amount of money. Different names, but doing the same thing—raising the success rate.

Token routing is undergoing the same evolution, but with greater difficulty and space.

The success of dollar payments is binary: either the money arrives or it does not.

Token is not: whether a task is completed or not, and how well it is done, is separated by a layer of judgment.

It is precisely this layer of ambiguity that makes raising the success rate on token much more valuable than in payments.

The most easily mistaken inference lies here—cheaper models are becoming more usable, so routing appears increasingly like a price comparison engine, sending each request to the cheapest model capable of doing the job. But "sending to the cheapest model" has been wrong from the start. An AI task is not a single inference. It is an agent planning, generating, validating, calling tools, retrying, and correcting errors. A cheap model failing twice is more expensive than a costly model succeeding once.

So what should be looked at is not the cost per token. It is the cost of each successfully completed task.

Inference costs, retry costs, tool calls, validation, manual guarantees, delays, and losses from failures—all added together and divided by the number of successful tasks. Once this calculation is clear, routing is no longer a price comparison engine.

But getting the calculation right is just the first step. The harder lesson from the payment industry is: whoever promises the success rate bears the cost of failure.

Gateways are willing to take on the hard work of optimizing authorizations because they charge based on success rates; when failures occur, customers seek them out, not the underlying channels. They absorb complexity and risk as part of their pricing model. Customers are willing to pay a premium for "this task can be accomplished," and the gateway collects that premium, at the cost of bearing the failures themselves.

Intelligent routing ultimately needs to connect to this as well. It is not about "sending requests to the cheapest model," but "can this task be accomplished?" Choosing a cheap model is merely a byproduct of the journey.

This is something only the routing layer can do. Moving the entire set of optimizations for prompts, context, parameters, and inference decoding to the gateway layer is something almost no one has productized—these tasks are currently scattered across the application layer, with each company writing their own version. But they are inherently the responsibilities of the gateway. Doing it well requires failure samples across models and task types, which a single application does not have the vision to achieve.

Risk control is another side of the same logic. It is one of the things that cannot be taken away by just changing a base URL, and it is the most critical type. Stripe claims that about one-sixth of AI companies on its network are related to multi-account arbitrage; Dax Raad, co-founder of OpenCode, said they once cleared 7,013 fraudulent accounts, estimating a loss of $400,000 per month. A single model vendor can only see its own losses, while the routing layer can see how the same group is opening accounts at multiple places. Radar grew out of this.

4. Positions Unreachable by the Model Layer

For the past three years, discussions about AI have revolved around which model will win. Routing makes this question less important.

As penetration deepens, coding will converge into one set of models, retrieval into another, customer service into another, and complex reasoning into yet another, while a single application often needs to cycle through them to complete a task. By then, the term "best model" will itself become invalid, as no single task type will have the final say.

More importantly, its inference: no model vendor can monopolize a complete task. Once a task crosses models, the layer of assembly automatically appears. It is not taken from anyone's hands. It is relinquished by the model layer.

This scene has played out in financial services. Banks used to be a whole, with deposits, loans, payments, and foreign exchange bundled under the same license. Over the past twenty years, they have been broken apart by fintech and then reassembled—while the license remains with the banks, the profits have gone to the layer of assembly.

Model weights are that license. Scarce and expensive, but once accessed by multiple parties simultaneously, it becomes just one of the components. In Sandeep's words:

At this point, model routing no longer resembles a pipeline but begins to look like fintech.

The components it assembles—measurement, billing, risk control, account periods, reconciliation—are inherently fintech components.

5. Left Hand Capital, Right Hand Receivables

Laying out these five layers and looking at Stripe's product catalog, one will find that it is rebuilding the same system on token that it built on the dollar:

(Could token be Stripe's new dollar?)

The left column is basically built up bit by bit by Stripe itself, while the right column—Bridge, Privy, Metronome, OpenRouter—are all acquisitions. The same company, the same shape, first built in-house, then entirely bought. When it was first built, the shape did not exist, and they had to figure it out themselves; the second time, the shape is already clear, and it is just a matter of who gets there first. What is acquired is not revenue. It is time.

By acquiring OpenRouter, Stripe can be said to have bought a measuring instrument. From the measuring instrument to the balance sheet is the span of the last box.

First, look at accounts. Today's token balance is not quite an account; it resembles a prepaid card: prepaid, non-transferable, non-cross-platform, tied to a single issuer. But OpenRouter's balance can be spent across over 400 models and dozens of vendors, already taking a step from a closed loop to an open loop.

Prepayment means the platform gets cash upfront, with funds remaining on the platform. Taking another step towards an open loop touches the defining line of prepaid payment tools. Should this float be earned? That is a question for the license to solve.

Next, look at credit. Not just prepayment, post-payment credit terms are also common. In the cases we encountered, credit rates ranged from 1.5% to 2% monthly, annualized at 20% to 27%, on par with credit cards. This is precisely the price that a market without credit history should have. The interest margin will first be compressed at the routing layer, as only that layer can see who is opening accounts repeatedly at multiple places, whose consumption curve is stable, and who runs away after taking advantage.

Finally, consider foreign exchange. With over 400 models, input, output, and caching are priced separately, prices are constantly changing, and each routing is a conversion. It looks like foreign exchange but lacks one thing: there is no base currency. Any model's token cannot serve as a benchmark. This is not a currency exchange market. It is a multilateral barter of 400 types of goods, disguised as a market by a unified API interface.

Holding onto idle funds while having accounts receivable. This is not the balance sheet of a developer's tool. It is the balance sheet of a payment company.

Tokens are being measured, dollars are being accounted for.

6. Who Quotes for Results and Pays for Certainty

Payments have taken twenty years to align these five layers. Tokens do not need those twenty years.

So today, the two hot questions about model routing are actually misdirected: one is whether model performance will converge to just price comparison, leading to profit margins approaching zero; the other is whether independent routing providers can accumulate proprietary data to outperform model vendors and cloud platforms with built-in routing.

The former questions life, while the latter questions assets.

But the real test standard is: when will a router dare to quote based on "completing a task" instead of taking a cut from tokens, and pay for certainty.

At that moment, it is no longer a router.

There is Platts for crude oil, and S&P for credit, but neither touches the things they measure—Platts does not produce oil, and S&P does not lend.

There is no such institution for intelligence yet, but the traffic already amounts to hundreds of trillions of transactions daily.

This article is an industry structural analysis for discussion purposes and does not constitute investment or legal advice under any jurisdiction. Regulatory qualifications are based on the latest statements from relevant regulatory agencies and case facts; some data comes from a single source, and discrepancies in definitions have been noted in the text. It is recommended to verify specific citations separately.