Guillaume Lebedel · · 5 min 
AI Gateway Valuation: Why Stripe Paid $7B+ for OpenRouter
Table of Contents
Stripe has agreed to buy OpenRouter, an AI gateway that routes requests across models it does not own, for more than $7 billion, Bloomberg reported on 16 August. Three months earlier, in late May, OpenRouter raised $113 million at a $1.3 billion valuation. Stripe told TechCrunch that it “does not comment on rumors or speculation,” so this is a report of an agreed deal rather than a closed one.
Whatever the final number, an AI gateway is now worth several billion dollars, and OpenRouter trains nothing. It sits in front of models that other companies trained and does two jobs, neither of which requires a model.
What an AI gateway actually does: metering and model routing
Strip the marketing off any gateway, OpenRouter, Vercel, Cloudflare, or LiteLLM in open source, and two functions are left.
It meters. Every token, from every provider, counted against one prepaid balance, with per-key and per-team spend caps. One API key instead of a dozen provider accounts and a dozen invoices.
It switches. When a provider errors, rate-limits, or degrades, the request goes to a different provider and the caller never finds out.
The second job does more work than most architecture diagrams admit. Vercel published seven months of its own gateway traffic across more than 200,000 teams, October 2025 to April 2026, in its AI Gateway production index. Roughly 3.5% of requests complete only after a fallback to another provider. Measured in tokens the rescue rate is 5.1%, and in dollars 4.9%. That is vendor-published first-party data, so weigh it accordingly, but the direction is clear enough: one request in thirty would have failed without the switch. That share would plausibly run higher for agent traffic than for chat, since an agent chains ten or twenty model calls into a single task and any one of them failing kills the whole run. No one appears to have published the data split that way yet, so treat that extrapolation as reasonable rather than confirmed.
Why AI gateway valuations sit on the request path
OpenRouter’s valuation history tracks traffic, not capability.
At the May round, TechCrunch reported OpenRouter processing around 25 trillion tokens a week, up five times from about 5 trillion six months earlier, with more than 400 models and 8 million users. OpenRouter’s own homepage, checked on 17 August, now advertises 500+ models across 80+ providers, 200T+ monthly tokens and 10M+ users.
Those numbers describe volume crossing a chokepoint rather than intelligence. A buyer paying for that is buying the meter and the switch, plus the traffic already flowing through both.
This is the same trade Salesforce made in June, covered in our analysis of the Salesforce Fin acquisition: the price was for the connections and the customers already attached to them, not for the model. Model capability keeps getting cheaper and more similar between labs, while the position in front of the request does not.
For a CIO or Head of IT signing off on agent architecture, the practical read is that your model choice is becoming the least durable decision in the stack. We have argued the cost version of this before, that a cheaper model does not produce a cheaper agent, because what an agent actually spends tokens on is schemas and payloads rather than the licence. The valuation story is the same point from the other end. The money follows the request path.
The same two jobs, applied to agent architecture
Models are not the only thing an agent calls. A real workflow reads a candidate record in your ATS, writes a note to Salesforce, updates a field in Workday, and opens a ticket in ServiceNow.
Ask the meter-and-switch questions about that layer instead of the token layer:
- Who counts how many Workday writes your agents made last month, and per agent?
- What happens when the Salesforce API returns a 503 halfway through a chain?
- Which agent, specifically, updated that record, and under which scopes?
At most companies the answer to all three is a hand-rolled service some team wrote in a sprint, or nothing at all. Model routing became something you buy, while routing into systems of record mostly did not.
StackOne builds the action-layer version of this, so weigh the next paragraph accordingly. StackOne puts 450+ connectors and 28,000+ actions behind a search step, so an agent finds the one action it needs at call time rather than loading a catalogue into context first. That matters for the same reason gateway metering matters: tool catalogues cost real tokens before an agent does any work, and a search step keeps context flat however many systems sit behind it. Each call carries the scopes of the agent that made it, and the audit trail names that agent per action instead of a shared service account. Shared service accounts are exactly what made the Fedora rogue-agent incident unanswerable after the fact.
What to write down before your next agent architecture review
Take the two functions and apply them twice, once to tokens and once to actions. Four boxes:
| Layer | Meter | Switch |
|---|---|---|
| Tokens | Who counts spend, per team? | What happens when a provider degrades? |
| Actions | Who counts writes, per agent? | What happens when a system of record errors? |
If your top row names a vendor and your bottom row names an internal service with no clear owner, that asymmetry is your next incident, and it will surface about three weeks after go-live when someone in IT asks which agent wrote a record and the log says svc-automation.
Fill the boxes in before you pick your next model, which is the part you can swap in an afternoon anyway.
Stripe’s reported $7 billion says the market has already priced the token half. The action half is still mostly a build decision inside your own org, which means it is still yours to get right.
If you want to see how the action layer handles discovery, scoping and per-action audit, StackOne’s Search & Execute and audit trail docs are open to read without a sales call in the way.