Audit your token router before OpenRouter changes hands

If production traffic depends on a token router, ownership changes the pricing, neutrality, and exit terms. Stripe announced on August 19, 2026 that it had reached an agreement to acquire OpenRouter. The trade-off is arithmetic: OpenRouter charges a 5.5% fee on credit purchases, adding 5.5 cents per dollar, whereas Vercel's AI Gateway and Kilo Gateway pass provider pricing through without a per-token markup. The fee is small until it sits in front of production traffic, where it affects routing, pricing, failover, and exit.

The markup is the first dependency

The fee is the easiest dependency to measure. It scales with spend, and when the router is the only path to inference, it applies to every prompt, completion, retry, and fallback. In mid-2026, OpenRouter had roughly 8 million users, weekly token throughput of about 25 trillion, and annualized revenue near $140 million. The platform routes token usage across more than 400 models supplied by more than 80 providers. A small percentage on a large token flow becomes a cost line the platform team owns. The platform team should track it in the same budget as provider spend, not as a rounding error.

Neutrality drifts when the buyer owns the billing data

The mix of routed traffic is the second test. In mid-2025, OpenAI, Anthropic, and Google accounted for about 70% of routed traffic; a year later, that share was roughly 30%, while Chinese open-weight models grew from under 2% to about half of platform tokens and DeepSeek became the largest provider by volume. A router can route by owner incentives when billing is involved, even if it once routed by model fit.

Stripe has launched Token Billing as a product to help companies optimize token costs and route tokens efficiently. The platform team should treat the neutral default as a contract question. Third-party reports placed the OpenRouter acquisition at roughly $7 billion to $8 billion, with the New York Times citing about $7.5 billion and $1.5 billion reportedly paid to OpenRouter's founders.

Run the audit before the contract does

Each item maps to a failure mode: fee, mix, fallback, provider, billing, key, egress, and build cost.

• Markup: compare the router invoice to provider list price for the same model and token count.
• Neutrality: pull recent provider mix and check for unexplained shifts in model families or labs.
• Failover RTO: trigger a provider outage in staging and time the first successful fallback response.
• Provider concentration: count the largest providers by token share and flag any single provider that dominates the mix.
• Billing integration: reconcile router invoices against provider invoices and internal cost tags.
• Key/data isolation: confirm whether router-held keys can access production keys and whether prompts are logged or used for training.
• Egress: measure the extra network path and data egress when the router is enabled versus bypassed.
• In-house build cost: estimate engineer-hours to replicate routing, retries, rate limits, and billing for your current model set.

The build-cost item is the exit test. That test matters most right now, before a repricing, outage, contract renegotiation, data migration, or ownership change in production. A router that is a thin wrapper over provider APIs may be a small in-house service: model mapping, retries, rate limits, cost tags, and a fallback table. Billing, key custody, or data processing raises the build cost because the team must replace more than code. A router that is easy to call can still be hard to leave when it holds keys, logs prompts, or becomes the billing record.