Which AI model is best? Stripe just bet 7 billion dollars that it doesn't matter

Which AI model is best is the wrong question, and one of the biggest AI acquisitions of the year just made that expensive to ignore. Stripe agreed to buy OpenRouter for more than 7 billion dollars. OpenRouter's core function is to let you switch which model does your work, without redoing the work. That is a 7 billion dollar bet that the model is the part you throw away.

So the thing worth owning is not the model. It's the written-down version of how the work gets done.

Why did Stripe pay more than 7 billion dollars for OpenRouter?

Stripe agreed to acquire OpenRouter for more than 7 billion dollars, a price reported by Bloomberg on 16 August 2026. OpenRouter is an AI gateway. It helps customers select different models for different tasks, depending on their needs and budget, gives access to more than 400 of them, and claims 8 million users. It also handles the billing and the credits behind that, which is presumably what a payments company was looking at.

Still. One switch, 400 ovens behind it.

Disclosure before we go further: we're customers. Every AI call in our own build goes through OpenRouter, we set it up with teams in the bootcamps, and it's in the advice we give clients. So we're not neutral about this deal. We're also not surprised by it.

So here is how we read it. Nobody pays 7 billion dollars for a switch if they think one model is about to win. You pay it because you think the models will end up roughly equivalent, and because whoever is ahead this month keeps changing. That is our inference, not Stripe's statement; Stripe declined to comment on the reports. Meanwhile most of the internet is still arguing about which model is best.

What does an oven have to do with your AI stack?

Your model is the oven. Your playbook is the recipe. If the oven breaks you buy a new one and make the bread again; the recipe was the valuable part the whole time.

Say you have a good recipe for banana bread. The oven is just an oven. Swap it and you lose nothing, because everything that makes the bread good is written down somewhere outside the appliance.

AI works the same way. When AI does something well for you, it feels like the model did it. It didn't. You decided what good looked like. You fixed it eleven times. You told it what to never say, which numbers need a second set of eyes, and how your team actually talks. That's not the model. That's a process. The model just ran it.

That's the whole idea behind own the playbook, rent the tech. You own the recipe. You rent the oven.

What does model agnostic AI look like in practice?

It looks like a routing rule you wrote once and a model name you change without touching anything else. In our own stack every workflow names the job first and the model second, and the model is always followed by the word "today".

Here is the actual rule we run, and the one we set up with teams in the bootcamp.

Candidate data goes to an EU-hosted model. Names, job titles, current employers, LinkedIn profiles: if it identifies a person, it stays in the EU. That's Mistral, in Paris, today. Vacancy text with no personal data in it goes to a fast cheap model, Gemini Flash today. Reasoning work with no candidate data in the prompt goes to the strongest model available, Claude today.

Count the "today"s. Three models, three rules, and not one of the rules mentions a vendor.

The rule is "candidate data stays in the EU". The model is this quarter's implementation of that rule. When a better EU-hosted model ships, we change one string in one file and nothing else in the workflow moves. When something overtakes Claude on reasoning, same thing: one string.

That is the entire difference between a playbook and a habit. The rule is the part that has to hold up when someone asks how candidate data is handled in your process. The model name is not what they're asking about, and it never was.

If models keep getting better, why did the switch get more valuable?

Because the value moved. In May 2026 OpenRouter raised a 113 million dollar Series B at a reported 1.3 billion dollar valuation. Under three months later, the agreed price was more than five times that.

Models didn't get worse in those three months. Every release since made them better or cheaper or both. What went up in value was not the models. It was the freedom to stop caring which one you use.

Read that as a market signal about your own stack. Every hour you spend picking the perfect model is an hour spent optimising the part that depreciates fastest.

What is an AI playbook?

An AI playbook is the written-down version of how a piece of work gets done: the steps, the standard, the exclusions and the checks, in language a human can follow without you in the room. It is a standard operating procedure that happens to be executed by a model.

Here is the split that matters.

Layer	What it is	Who owns it	What happens when it changes
The model	GPT, Claude, Gemini, whatever is ahead this month	Rented. Never yours.	Price rises, it gets deprecated, a better one launches. You swap it.
The tool	Custom GPT, agent, ATS module, automation	Rented, usually per seat	Vendor changes the roadmap, or the seat count, or the plan
The playbook	The steps, the standard, the exclusions, the checks	Yours, if you wrote it down	Nothing. You paste it into the next oven.

Most teams have all three. Only the third one is an asset, and it's the one nobody writes down.

What happens when the playbook only lives inside the tool?

It leaves when the tool leaves. And the first time anyone reads it back, nobody can explain half of it.

Here is the pattern we keep running into. A team spends eight months teaching a custom GPT to do real work: client updates, case studies, whatever it is. By month eight it's genuinely good. It knows the tone. It knows what's off limits. It knows the three things legal always flags.

But none of it is written down. It lives inside the tool, in the tool's memory, and in one person's chat history.

Then something changes, because something always changes. The model gets deprecated, or the person quits, or the price goes up. So somebody opens those instructions for the first time in a year and finds forty rules nobody remembers writing. Nobody can explain half of them. Nobody knows which ones are holding it together and which ones somebody typed in once when they were annoyed.

That's not a recipe. That's a really good cook who left.

"But Claude is just better at this"

Fair, and we hear it constantly. Here's the honest answer: if your bread only comes out right in one oven, the problem usually isn't the oven. Your recipe is missing steps, and the oven has been covering for you.

Good recipes travel. We call it the smart intern check.

Could a sharp person who has never done this job follow your written steps and get it right?

If yes, a good model can too. If no, you never had a process. You had a favourite tool and a lot of hope.

This is not an argument that all models are identical. They're not, and we route reasoning work to Claude for exactly that reason. It's an argument that model preference should stay a preference and never become a dependency. A preference costs you nothing; you write it down as a default and move on. A dependency costs you the whole workflow the day the vendor changes something.

How do you write your AI playbook down?

Start with one workflow that already works, and write it as if the model is leaving next week. Four passes is usually enough.

1. Name the output. What does finished look like, exactly? Length, format, tone, what it must never contain. If you can't describe the finished thing, the model has been guessing and getting lucky.
2. Write the steps, not the prompt. A prompt is one implementation. The steps are the thing. "Pull the last three interactions, check them against the brief, flag anything the client hasn't approved" survives any model. "Act as an expert recruiter" survives nothing.
3. List the exclusions. Every rule in that custom GPT exists because something went wrong once. Write down what went wrong next to the rule. A rule without its reason is the rule nobody dares delete.
4. Name the checks. Which numbers get a second set of eyes. Which claims need a human. Which outputs never go out unread. This is also the part you will want on paper the day somebody asks how a hiring decision was supported, and that question never depends on which model you used.

Then run the smart intern check on it. Then run it on a different model. If the output holds, you own something.

What this means if you run recruitment operations

If you run operations, AI has probably made your job harder rather than easier. Everyone on the team is using it. Nobody is using it the same way. None of it is written down. And you're the one who has to make it all coordinate.

That's not a model problem and no model release will fix it. It's a setup problem. AI is not your problem; your setup is. Adding a better oven to an undocumented kitchen just gets you inconsistent bread faster.

The work is unglamorous and it is the only part that compounds: pick the workflows that matter, write the recipes down, then decide which oven runs them this quarter.

If you want a second pair of eyes on which of your workflows are actually documented and which ones are one resignation away from disappearing, book a 20 minute call. No pitch, just diagnosis. If you'd rather see the whole sequence first, that's on the services page, and the hands-on version is the AI Recruitment Engineer Bootcamp.