Stripe, OpenRouter and the Limits of Token Arbitrage

On August 19, Stripe confirmed it is acquiring OpenRouter. Bloomberg put the price above $7 billion, the New York Times at roughly $7.5 billion and Axios at more than $8 billion in cash and stock. OpenRouter had closed a $113 million Series B in May at a $1.3 billion valuation, so the company is worth five to six times more than it was three months ago.

Sacra puts OpenRouter at roughly $140 million annualized as of July 2026, up from about $50 million at the end of 2025. Nobody underwrites $7 billion against that P&L, which means Stripe was not buying a $140 million software business. It was buying a position in the token economy, and that position is worth understanding before enterprise buyers read the deal as proof that the LLM router is now a settled, well-funded layer of the AI stack.

The economics of aggregation

OpenRouter routes across 400+ models from 80+ providers and was processing on the order of 100 trillion tokens a month as of May 2026, a run rate past a quadrillion tokens a year. a16z used the corpus for an empirical study of 100 trillion tokens because there is nowhere else to observe inference demand at that resolution. A meaningful share of global inference now passes through one set of routing tables.

The published revenue model is a take rate. OpenRouter states that it does not mark up provider token rates, and its fees are 5.5% on credit purchases plus 5% on BYOK traffic past a free monthly allowance. Taken at face value, that is a percentage of payment flow, which is already a Stripe business.

The buy side is the part nobody publishes. At a quadrillion tokens a year you are less a customer of the model providers than a distribution channel for them. You occupy the top commitment tier at every one of those 80 providers, you carry enough aggregate volume to negotiate against each of them individually and you control the routing table that decides which of them receives the traffic. Any gap between what an aggregator pays and the list price it bills against is margin that appears in no published fee schedule.

Whether a given OpenRouter provider contract actually carries a rate below list is between OpenRouter and that provider, and I have no visibility into those terms. The point is structural rather than accusatory. Aggregation creates the position where a spread can exist and volume is what holds it open. Stripe understands that business as well as anyone, because interchange works the same way: sit between two parties who both need you, aggregate enough flow that neither can route around you and earn on the difference plus a few basis points on top.

Patrick Collison framed it directly in the announcement: "Tokens are the central currency for companies building with AI, and it's clear that the real-world economic potential will depend on making good use of scarce compute resources." Treating tokens as a scarce currency to be brokered is a market-making thesis, and it is a sound one.

What the model requires to work

Aggregation economics depend on three conditions holding at once.

The first is a price-sensitive buyer. They are spending their own money on inference, margin per call determines whether the product works and shaving 30% off token cost changes the shape of the business.

The second is provider fungibility. If two models both produce an acceptable answer, routing to whichever is cheaper or faster in the moment carries no consequence beyond the price.

The third is an absence of buyer leverage. A five-person team shipping an AI product cannot negotiate a volume rate with Anthropic or OpenAI, so buying through a channel that can is strictly better than buying direct.

All three hold for consumer AI apps, coding agents and fast-growing startups. That market is large, it is growing faster than the enterprise and OpenRouter serves millions of developers inside it. Stripe already sells to those companies, so the deal is coherent on its own terms. The conditions look very different at a bank.

BYOK removes the buy-side advantage

An enterprise running Bring Your Own Key has already done the buy-side work. It holds a negotiated commitment with Anthropic or OpenAI, or the model spend draws down against an existing AWS Enterprise Discount Program, Azure Enterprise Agreement or Google Cloud commit. Procurement negotiated that rate, legal papered it and finance is already drawing against it.

Route that traffic through an aggregator and there is no spread left to earn, because the enterprise is buying the tokens rather than the aggregator. What remains is a percentage charged on top of a contract the enterprise negotiated itself.

OpenRouter's pricing reflects this honestly. On credit-funded traffic the fee is a take rate on money moving through the platform. On BYOK traffic it has to be stated and charged separately, at 5% of what the same call would have cost on-platform past the free allowance. BYOK is the case where the spread disappears, so the fee surfaces as an explicit line item. A percentage of your own negotiated spend is a difficult thing to justify for a routing decision you have already constrained.

Bedrock, Vertex and Azure AI Foundry are a different purchase

When an enterprise routes Claude through Amazon Bedrock instead of calling Anthropic directly, it is not shopping for a better token price. Bedrock frequently costs the same or more. The enterprise is buying three other things.

The first is a data boundary. AWS states that Bedrock does not store your input and output data, does not share it with the third-party model provider and does not use it to train foundation models, with each provider's weights running in a Model Deployment Account operated by the Bedrock service team that the provider cannot reach into. Google makes a comparable commitment for Vertex AI under its Cloud AI/ML Privacy Commitment, and Microsoft is explicit that Azure AI Foundry prompts and completions are not used to train its models, OpenAI's models or anyone else's.

The second is inherited paperwork. The DPA is signed, the BAA is in place, the sub-processor list has cleared third-party risk and the region is locked. Adding a model through a cloud provider that has already been vetted is a configuration change, while adding a new direct provider is a two-quarter procurement cycle.

The third is network topology. Traffic to a VPC endpoint stays on the cloud provider's backbone and never crosses the public internet, and for many regulated workloads that single property determines the architecture.

The details underneath those commitments are the kind a price-optimizing router will never model. Azure OpenAI applies a 30-day abuse-monitoring retention window to prompts and completions by default, and removing it requires an approved Modified Abuse Monitoring exception available only under an Enterprise Agreement or Microsoft Customer Agreement, not on pay-as-you-go. Two endpoints serving the identical model can therefore behave differently on retention based on paperwork the router has never seen. A price-and-latency routing table has no field for that.

The two markets are running different optimizations. One minimizes cost per acceptable answer across a public menu of providers. The other selects the endpoint that sits inside a compliance perimeter and treats cost as a secondary concern. A router built for the first problem has little to contribute to the second.

Routing is a data-governance decision

A price-optimizing router selects the provider per request, by design. Inside an enterprise, that makes a cost function the thing deciding where regulated data goes at runtime.

A DPO has to be able to name the sub-processor that handled a given prompt. An auditor has to be able to demonstrate that regulated data stayed in-region. An incident responder, on the day a provider discloses a breach, has to produce the set of prompts that touched that provider during the exposure window. "Whichever endpoint was cheapest at 14:32 UTC" answers none of those questions.

Dynamic price-driven provider selection and a defensible data-processing record are in tension, and the way to resolve it is to make policy the constraint and let price optimize inside it rather than the other way around.

What the Service Edge does instead

Ferentin runs a Service Edge for AI traffic, designed around the boundary rather than the spread.

Provider selection is policy, expressed in compliance terms. Every provider and model is cataloged in the LLM Registry with its training policy and data residency information attached, so a routing rule can require that PII-bearing traffic reach only in-region VPC-hosted endpoints. Price optimization happens inside the set of endpoints policy already allows.

Retention is a control you hold. Zero Data Retention is available on every plan at no extra charge. Elect it and Ferentin persists no prompts, completions, tool inputs or tool outputs, leaving nothing in our systems to breach or subpoena. Leave payload storage on for compliance and debugging and it runs with your plan's retention window, encrypted under tenant-specific keys. ZDR governs Ferentin's systems rather than the provider's, so we publish each provider's retention terms in the registry and routing policy can account for both.

Network isolation is a deployment option. A Private Service Edge runs inside your own VPC or cloud account, so AI traffic stays within your network boundary and payloads never reach Ferentin's cloud. It applies to the control layer the same reasoning that sent you to Bedrock for the model. The full framework is in Edge LLM Routing vs Cloud Gateway.

BYOK is the native case. Your provider keys, your negotiated commitment, your contract. Credentials are envelope-encrypted under tenant-specific keys, which is precisely the control whose absence made the LiteLLM supply chain incident as damaging as it was. Nothing is skimmed off spend you negotiated yourself, because we are not in the spread business.

Every request carries an identity. Human identity comes from your IdP through SSO and workload identity covers headless agents, with no shared API keys and no anonymous traffic. Access is revoked at offboarding, and the audit receipt records who accessed what, when and whether it was allowed.

Tool calls are governed alongside tokens. Token routing is the smaller half of the problem. The larger half is what the agent does with the answer: which MCP servers it can reach, which tools inside them and with whose permissions. The CISO Reference for Agentic AI covers how those controls fit together.

Where this leaves enterprise buyers

Stripe's thesis is right for the market it serves. Tokens are becoming a metered commodity, the meter is worth owning and Stripe is the natural owner of any meter with money flowing through it. At a quadrillion tokens a year, whoever holds the routing table holds real economic leverage, and $7 billion is a rational price for that leverage even against $140 million of current revenue.

It changes nothing at your perimeter. An arbitrage layer optimizes the price of a call it is not permitted to inspect. A trust layer decides whether the call should happen at all, to which endpoint, under whose identity, with what leaving your boundary and what record surviving afterward. Those are different products, and the second one is still your responsibility.

If your AI traffic runs through BYOK or through Bedrock, Vertex or Azure AI Foundry, provider selection is already a security decision. Book a demo and we will show you what it looks like when it is enforced as one.