DEV Community

Ashraf
Ashraf

Posted on

Stripe Just Bought the Company That Sits Between You and Every AI Model. That Should Worry You.

The number that should stop you mid-scroll

Three months ago, OpenRouter closed a Series B at a $1.3B valuation. This week, Stripe agreed to buy it for north of $7 billion — some reports put it closer to $8B, mostly in stock. That's a 5.4x markup in 90 days.

Sit with that for a second. Not 90% up. Not doubled. Five-point-four times, in the time it takes a startup to onboard a new hire and get them through a performance review cycle.

If you build anything on top of LLMs, you've probably routed a request through OpenRouter without thinking twice about it. 400+ models, one API key, one bill. It became the default because it did one thing extremely well: it didn't care which model won. Route to Claude, GPT, Gemini, Llama, whatever — OpenRouter's incentive was purely "cheapest/fastest/best for this task," not "push our own model."

That neutrality is the entire product. And it's the first thing on the chopping block.

Why Stripe, and why now

This isn't Stripe dabbling in AI. It's the second move in a deliberate stack-building play. Late 2025, Stripe quietly acquired Metronome — usage-based billing infrastructure built specifically for AI companies. Now they've bought the routing layer that decides which model gets your query in the first place.

Put those two acquisitions next to each other and the strategy is obvious: Stripe wants to own the meter and the pipe. Every token that flows through OpenRouter, Stripe can now see, route, and — eventually — bill on its own terms. You already trust Stripe with your payments infrastructure. Now they want to be the infrastructure between you and the model itself.

From Stripe's blog post announcing the deal, the pitch is exactly what you'd expect from a company managing PR around a neutrality-eroding acquisition:

"OpenRouter will maintain its product, mission, name, and roadmap... routing decisions based on what's best for you, the user."

Sure. That's what every acquired company says on day one. Instagram was going to stay Instagram too.

The math nobody's saying out loud

OpenRouter's own numbers, straight from the announcement: 10+ trillion tokens processed daily, 400+ models, 10M+ developers and companies routing through it. That's not a startup anymore — that's critical infrastructure for a meaningful slice of the AI application layer, sitting inside a 90-person team that just got bought by a payments giant with every incentive to monetize the chokepoint.

Here's the part that should actually change how you architect things: OpenRouter's margin has always come from being the trusted middleman. Stripe's margin comes from being the trusted middleman on money. Merge those two roles and you get a company whose core competency is extracting rent from every transaction that passes through it — except now the transaction is "which AI model do you get to talk to."

Nobody's saying OpenRouter is about to start silently biasing routing toward models that kick back the best margin to Stripe. But nobody needed to say it about App Store rankings either, and here we are a decade later still litigating that exact question in federal court.

What developers on Hacker News are actually worried about

The HN thread on this (hundreds of comments within hours) converged fast on one question: does Stripe ownership compromise routing neutrality? Not "is this a good exit for the founders" — obviously it is — but whether the thing that made OpenRouter useful survives contact with a company whose entire business model is taking a cut.

That's the right question. It's also unanswerable right now, because the deal hasn't closed yet ("customary closing conditions," expected "in the coming weeks"), and no acquired company in history has ever pre-announced "yes, we're going to start degrading the product for margin." You find out eighteen months later when the pricing page changes and a blog post about "improving the developer experience" ships alongside a 20% take-rate increase.

What you should actually do about it

Don't panic-migrate today. Do this instead:

  1. Abstract your model routing layer now, if you haven't already. If your codebase calls openrouter.chat.completions.create() directly from fifteen different files, you've already made a mistake independent of this acquisition. Wrap it.
// Don't do this everywhere in your codebase
const res = await openrouter.chat.completions.create({
  model: "anthropic/claude-sonnet-5",
  messages,
});

// Do this instead — one seam, swappable later
class ModelRouter {
  constructor(provider) {
    this.provider = provider; // openrouter today, direct APIs or another gateway tomorrow
  }
  async complete(opts) {
    return this.provider.complete(opts);
  }
}
Enter fullscreen mode Exit fullscreen mode
  1. Track the routing behavior, not just the invoice. If you have volume, log which model actually served each request over the next two quarters. If you see systematic drift toward models that happen to correlate with Stripe's other business interests, that's your signal — and you'll have the receipts before the blog post explaining it away shows up.

  2. Know your exit. Direct provider APIs (Anthropic, OpenAI, Google) plus one alternative gateway (Together, Portkey, that kind of thing) should already be a config change away, not a rewrite. The value OpenRouter provided — one interface, many models — is a pattern you can replicate yourself in an afternoon. The trillion-token infrastructure is what you're actually paying for, and that's precisely the part a payments company now controls.

The uncomfortable truth

A 5.4x markup in three months doesn't happen because a company found a slightly better product-market fit. It happens because someone with deep pockets looked at a chokepoint and decided owning it was worth paying almost any price to get there first. Stripe didn't buy OpenRouter's engineering team. It bought the traffic.

Neutral infrastructure stays neutral right up until the acquisition closes. After that, it's a product line with a P&L, and P&Ls get optimized. Build accordingly.

Top comments (0)