Token Routing Has Entered the P&L

The clearest August 21 signal came from Digg AI and Digg Tech clustering around Stripe agreeing to acquire OpenRouter. The primary source matters because Stripe states the product shift directly: the hard problem is no longer only access to models, but managing a fast-moving matrix of task complexity, price, speed, reliability, and constant model repricing in real time. OpenRouter’s own announcement sharpens why this matters in practice: one interface, model-agnostic observability, cost management, and routing across 400+ models has already become a daily production surface for millions of developers and companies. Simon Willison’s recent operator notes on DeepSeek via OpenRouter give the builder-level translation for why this has become urgent: frontier-adjacent performance is now appearing at sharply different price points and reasoning settings, so the economic consequences of a routing decision can be as important as the quality consequences. The useful synthesis is that token routing is moving out of the infra team’s bag of tricks and into the product P&L.

A lot of teams still ship AI features as if model choice were a one-time architectural decision. That breaks once comparable models keep appearing with different price, latency, context, and reliability profiles. If every request defaults to the safest expensive route, usage growth turns into margin pressure. If every request chases the cheapest route, trust erodes and teams quietly add human cleanup. Builders who own routing as a business primitive can keep quality legible while making cost, latency, and fallback behavior explicit. Builders who do not will end up with AI features that work in demos but degrade once real traffic, retries, and edge cases hit the budget.

Turn one production AI workflow into a routing-and-margin policy. Trigger: choose a user path where AI usage is growing or costs are becoming hard to explain, such as coding assistance, support drafting, sales research, document extraction, or internal ops automation. Context: classify the task classes, acceptable failure cost, latency target, data boundary, and which outputs truly need frontier-level reasoning versus cheaper or narrower models. Tools: use a gateway or internal router, prompt templates by task class, spend and latency logging, provider failover, and one visible policy for reasoning budget rather than a hidden default. Verifier: require an external acceptance check such as tests, rubric review, grounded citations, schema validation, or downstream state confirmation. Budget: set per-class ceilings for cost, wall-clock time, fallback count, and human rescue minutes. Artifacts: keep the route table, verifier outcomes, cost per accepted run, escalation reasons, and a weekly review of which requests should move up or down market. Stop condition: a route is promoted only when it clears the verifier within budget at production-like traffic, and it is demoted when acceptance, latency, or margin drift breaks the policy.

Pick one expensive AI workflow and write a three-lane route table: default, premium, and fallback. For each lane, define trigger, model or provider choice, verifier, cost ceiling, and the exact reason a request is allowed to move upward. If the answer is still “send everything to the best model,” you do not yet own the economics of the feature.