The routing rule is a spending decision.

Picture a month's invoice for AI inference, the kind a finance team starts receiving once a company has wired language models into its products. It names a workload, support summaries. It lists two models from two providers, the millions of tokens each one processed, a line for retries after timeouts, a platform fee and a total. The arithmetic checks out. The invoice is invented for this dispatch, and so is every number on it. What it cannot tell you, because no invoice is built to, is why most of those requests went to one model rather than the other.

That answer lives in a different document: the rule that decided where each request would go. A week after a payments company agreed to buy the best-known keeper of such rules, the two documents are worth pulling apart. Access to many models is a menu, the set of suppliers a buyer could use through one interface. Authority to allocate spending is the hand that picks from the menu, request by request, and so decides where the money goes. A gateway can widen the first while quietly taking on some of the second.

My argument is that a buyer weighing a gateway should ask who holds that hand, what constrains it, and which record explains the bill it produces, alongside the real convenience of one interface. This is not a claim that OpenRouter routes unfairly, that it dominates a market, or that Stripe will combine anyone's records. Nothing published so far shows any of that. It is a claim about where, in this kind of system, a spending decision sits.

What was announced

On August 19, Stripe said it had agreed to acquire OpenRouter, which it described as helping businesses route and optimize token usage across more than 400 models from over 80 providers. Stripe presented the deal as part of building economic infrastructure for AI, helping companies raise revenue while holding down costs.¹ OpenRouter's own post said nothing about existing integrations would change and promised a service that "doesn't bend to any model, any provider, or any parent company." It also said the deal was subject to customary closing conditions.² Those are commitments made at an announcement, not results anyone has yet had a chance to test.

The seller's counsel confirmed that the terms were not disclosed.⁴ Reuters, citing an unnamed source, reported a value slightly above $8 billion;⁷ other reporting gave a different figure.⁸ The price is not the interesting part. The interesting part is the combination. In January, Stripe completed its purchase of Metronome, which runs billing for usage-based pricing.³ Once this deal closes, one company could touch four steps in sequence: the choice of where a request goes, the meter that counts it, the bill that prices it and the payment that settles it. Those are different functions, and owning all four does not mean they have been joined into one system. The announcements describe an ambition, not an architecture.

Where the decision actually sits

Not every request through a gateway hands over authority, and the distinction matters. When an application names the model it wants, the gateway is a switchboard, and the decision belongs to the developer who wrote the call. When a customer writes a fallback sequence, try this provider and then that one, the decision is still the customer's, but the gateway carries it out and holds the record of which branch fired. When a customer lets the service choose among eligible options, by price, by speed or by an automatic router, the policy is now selecting suppliers on the customer's behalf.

Menlo Ventures, which has invested in OpenRouter since its seed round, draws the same line from the seller's side. Its partners write that most developers come for access to many models and make the routing decisions themselves, with automatic routing offered as an option.⁵ An investor's account is an interested one, but the distinction does not depend on who states it. The further a buyer moves along that sequence, the more its spending follows a rule rather than a line of code someone reviewed.

A rule of that kind is a purchasing policy that runs without a purchase order. If it says to pick the lowest charge among models that pass a quality check, then the quality check is a procurement criterion, and whoever sets and measures it is shaping the spend. Figure 2 makes the point with two invented routes. Both are in the catalog, and both pass the same check. Change the priority, and the selection changes. The menu did not move.

The record that explains the bill

The practical answer is a decision record kept beside the invoice. For each request, or each batch, it would note the workload class and the policy version that governed it; the eligible destinations and why any were excluded; the model and the provider actually used, as two separate facts, since one model can be served by several providers; the reason for the selection or the fallback; the metered units and how they became a charge, retries and fees included; and a pointer to wherever the quality of the output is evaluated, because an invoice says nothing about whether the work was any good.

That list is my proposal, not a description of any product's schema, and not a finding that OpenRouter lacks any of it. Nor does it require keeping prompts or outputs. A record of where a request went is metadata. It is not permission to read what was sent, to train on it, or to combine it with payment data, and any claim that a company does those things needs its own evidence.

Competition is real, and it is not the whole answer

On the same day as the Stripe announcement, Ramp launched Router.com, described as one API to reach models, evaluate them and route traffic across them.⁶ That is evidence that others see the same opportunity, and that buyers have alternatives. It is not evidence that two gateways are equivalent, or that moving between them is painless. The models may be easy to swap. The policy you tuned, the evaluation history behind it and the contracts around it may not travel so easily. Portable models are not the same thing as a portable rule.

Objections, considered

Users choose the model themselves. Often they do, and then the gateway decides very little. The question shrinks but does not vanish: which defaults, fallbacks and retries still run on the gateway's side, and are they in the record?

A router reduces dependence on any single model supplier. It does, and that is a real benefit. The test is whether the policy and its evidence stay portable as the suppliers become easier to replace, so that dependence does not simply move one layer up.

Competition will discipline the intermediary. It can, where switching is practical. The decision record is much of what makes switching practical, because it lets a buyer show a new provider what the old rule was doing.

A gateway with no model of its own is neutral. Owning no model removes one possible incentive. Neutrality still depends on terms, controls and behavior. OpenRouter's pledge is the right thing to promise; the buyer's job is to make it checkable, which is not the same as assuming it has been broken.

We can run our own proxy. That changes who operates the router. Someone still has to evaluate models, recover from outages, secure the traffic, negotiate with providers and answer for the rule. For some workloads that is worth doing; it is not a universal cure.

A routing rule is a purchasing decision repeated at machine speed.

Before you sign a gateway contract

• Who sets the rule? Name the person or team, and say who approved the priority it applies.
• What can override it? Defaults, fallbacks, retries, outages, the provider's own choices.
• Which record explains the resulting charge? Route, reason, units and charge basis, per request or per batch.
• Can we take the policy and evidence with us? Ask for the export before you need it.

Back to the invoice. Lay the policy record beside it, and the line that read "Why this route? not stated" has an answer: version 7, lowest charge among routes that pass the check, set by the platform team and approved by finance. The total is the same as it was. What has changed is the question the finance team can ask. It is no longer only whether the arithmetic is right. It is what produced the bill, and who decided.