Investor documents put inference costs above half of revenue at both OpenAI and Anthropic. On OpenRouter, Chinese models account for about 60% of tokens used by US companies. The figures look like separate stories—one about cost, one about geography—but they meet at a decision most applications used to make only once.
Key takeaways
- Model choice is shifting from a one-time architecture decision to a per-request allocation based on cost, quality, latency, availability, policy, and data governance.
- A model router can turn multiple provider APIs into a portable workload layer, but its strategic value comes from recording why each model, fallback, tool, and escalation path was chosen.
- Inference economics make static defaults costly: OpenAI and Anthropic reportedly spend more than half of revenue on inference, while potential cost reductions can quickly change which models are economical for a task.
- Agentic workflows strengthen the router’s role because each planning, retrieval, tool-use, and execution step can require a different model, budget, policy, or review threshold.
- Routing increases buyer power but also creates a chokepoint: the operator can observe demand, determine model eligibility, enforce geographic rules, and redirect traffic without application changes.
For the first phase of foundation-model adoption, model choice looked like architecture. A team selected a provider, integrated its API, tuned prompts around its behavior, and treated the resulting dependency as a technical commitment. Switching was possible in theory and expensive in practice. The provider’s interface, tool semantics, security controls, and model behavior all leaked into the application.
Teams could tolerate those dependencies while model selection was infrequent. They cannot when capabilities and inference economics move this quickly. The model appropriate for a difficult research task may be wasteful for classification. The model suitable for a customer-facing response may be too slow for a background agent. A model approved for one geography or data class may be inadmissible for another. Teams moved toward routing independently because the economics changed.
The gateway emerged because model choice stopped being stable
A model gateway gives applications a common interface to multiple providers. It translates requests and can enforce authentication, rate limits, logging, fallbacks, and routing rules. Compatibility plumbing becomes more important when the service behind the interface changes frequently.
The architectural move is familiar. A common request language separates the application’s domain from the provider’s implementation. Instead of teaching every product workflow the dialect of every model API, the gateway publishes one language between them. That does not make the models equivalent. It makes their differences manageable in one place.
A router adds decisions to that gateway. It classifies a request, matches it against eligible models, assigns it according to cost and performance requirements, evaluates the result, and may escalate. The router does not perform the underlying business operation; it changes the operational plan used to perform it.
| Routing decision | Variable being optimized | Control-plane obligation |
|---|---|---|
| Admit or reject | Policy, data class, jurisdiction | Record which rule governed the request |
| Select a model | Cost, quality, latency, availability | Preserve the reason for selection |
| Run in parallel | Confidence and task difficulty | Compare outputs using a declared method |
| Escalate or retry | Failure, uncertainty, sensitivity | Retain the decision path and fallback history |
| Accept an output | Quality and safety thresholds | Attribute the result to model, policy, and version |
The router sits at the intersection of tradeoffs that cannot all be maximized. The cheapest model may be slower. The fastest may be less reliable in a particular domain. Parallel execution may improve confidence while increasing cost. A common interface may conceal provider-specific features that produce better results. Routing makes those compromises continuously instead of burying them in an annual vendor review.
Every inference request is becoming a procurement event
Investor documents indicated that OpenAI and Anthropic reported inference costs exceeding half of revenue, while presenting profitability projections with and without training costs. Training attracts attention because it arrives in spectacular clusters. Inference repeats every time a user or agent asks for work. At that scale, a single-model default is an unexamined purchasing policy.
The cost curve is also unstable. OpenAI engineers reportedly identified a method that could more than halve inference costs. A change of that magnitude alters which workloads are economical, which latency-quality combinations are acceptable, and how much value a buyer can capture by moving requests among models.
A model procurement stack turns model selection from a platform commitment into a repeated buy decision. The relevant unit is not cost per token but cost per useful task, including retries, tool calls, evaluation, latency, and failures. A nominally cheap model can be expensive if it needs three attempts. A frontier model can be economical when one invocation replaces a long chain of weaker ones.
A buyer therefore sets routing policy before negotiating provider volume: which tasks qualify for a frontier model, which failures trigger escalation, what data may cross borders, and whether savings survive retries. Procurement becomes a live allocation policy rather than a vendor scorecard.
OpenRouter’s Fusion makes that portfolio logic explicit. It sends prompts to multiple models in parallel and claims Fable-level intelligence at half the price. OpenRouter has not independently validated that benchmark, but the product design is the signal: the unit being sold is no longer access to one model. It is a result assembled from a portfolio.
Routing does not make frontier models irrelevant. It makes their quality differences more economically legible. If every model were interchangeable, a price list would be enough. Routing has value because some tasks justify expensive capability and others do not.
Meta is acting like a large buyer of intelligence
Meta’s internal AI incubator is developing a model router modeled on OpenRouter’s approach, with the stated purpose of sending some tasks to lower-cost models. The project matters not because Meta discovered gateways, but because a company investing heavily in models and infrastructure still wants a layer that can decline to use the most expensive option. By building it, Meta is creating procurement and scheduling infrastructure for intelligence.
The financial context makes the incentive difficult to miss. Meta has raised $62 billion of debt since 2022, roughly half of it during 2025. It also moved $30 billion of debt for AI data-center construction off its balance sheet through special-purpose vehicles. Across Alphabet, Microsoft, Amazon, Meta, and Oracle, estimated off-balance-sheet debt grew roughly eightfold since 2022 to about $1.65 trillion.
The broader market for contracted AI capacity turns powered compute into infrastructure that can be financed and leased. Once capacity carries long-term financial obligations, utilization quality matters alongside utilization volume. A router can extract more useful work from that financed base by reserving expensive capacity for requests that need it.
Meta’s surrounding narrative reflects the same operational turn. Enterprise framing in Meta coverage rose from 10.8% to 15.7%, while research framing fell from 16.5% to 12.0%. The emphasis is shifting from whether Meta can build a model to how it allocates, finances, and governs model use.
Meta’s router remains an internal project under development. There is no evidence that it is a public product, much less an adopted interoperability standard. The signal is behavioral, not commercial: a large model builder has concluded that model choice deserves its own infrastructure.
Agents turn routing into the workflow scheduler
A conventional application may make one model call and wait. An agentic workflow can invoke a model, search the web, retrieve files, call external tools, inspect the result, revise a plan, and invoke another model. Each step has a different error cost and capability requirement.
OpenAI’s Responses API and Agents SDK give agents an orchestration surface for searching the web, scanning files, and operating computers. The Responses API later added remote MCP servers, image generation, and Code Interpreter. Codex launched more than 20 initial plugin integrations, including Figma, Notion, Gmail, and Slack.
Those additions make workflows more useful, but they also multiply decisions. A routine extraction step may need a fast, inexpensive model. A planning step may justify a stronger one. A tool call involving sensitive records may require a model approved for that data class. A final action may need human review regardless of which model generated it.
Traditional failover plumbing asks whether the preferred model is available. An agent router asks which model should perform this step, under this policy and budget, given what happened in earlier steps. The difference is the difference between a spare tire and air-traffic control.
Provider-specific agent APIs, SDKs, plugins, and security controls complicate portability. A gateway may normalize the underlying model call while the workflow remains dependent on one provider’s tool semantics, conversation state, sandbox, or evaluation system. Teams can move prompts before tools, and tools before operational history.
OpenAI and Anthropic therefore benefit when their APIs become the application’s native operating surface. Integration depth can preserve demand even when raw model calls are routable, so providers can support common interfaces while making their native paths more useful.
Portability and gatekeeping arrive in the same interface
A router can turn a collection of provider APIs into a portable workload layer. The application targets one interface while the router changes the model behind it. That increases buyer power, lowers the operational cost of testing alternatives, and can make geographic substitution routine.
OpenRouter provides unusually sharp evidence about what happens when an intermediary lowers the friction of cross-provider and cross-geography consumption:
The figure does not measure the entire US market. It shows how developers behave when a common interface makes alternatives easy to consume. US companies did not collectively announce a strategy to shift token demand toward Chinese models. Individual builders responded to price, capability, and availability, and the gateway aggregated their choices into a strategically significant pattern.
The same interface can become a chokepoint. Its owner sees request patterns, determines which providers are eligible, defines fallback behavior, controls observability, and can impose geographic or data-handling rules. It can redirect demand without changing the application code above it or the models below it.
That position is attracting strategic attention. OpenRouter reportedly discussed a potential sale at a multibillion-dollar valuation, above its reported $1.3 billion valuation in May. The asset is not merely API aggregation. It is visibility into workload demand and the ability to direct it.
The owner’s business model determines how that power is used. OpenRouter benefits from preserving a broad model market. Meta’s internal router optimizes for Meta’s economics. AWS Bedrock, Google Vertex AI, and Microsoft Azure AI Foundry make portability available inside their administrative perimeters. Chinese model providers gain distribution when gateways make them operationally substitutable. The interface may look common while the governing interests remain different.
Provider-specific tools keep routing from becoming universal
Routers cannot erase model differences beyond price and benchmark quality. Providers expose distinct tools, context behavior, safety systems, structured-output guarantees, and operational controls. Applications built around those features cannot always substitute another model without losing functionality.
Parallel routing has its own costs. Sending a task to several models can improve the chance of obtaining a useful answer, but it consumes more inference and requires a scoring method. If the evaluator is unreliable, the system has moved the difficult judgment from generation to selection. A router can optimize only what its objective function measures.
Neither Meta’s internal project, OpenRouter’s interface, nor any managed-cloud gateway has become a universal interoperability standard. Competing gateways normalize common operations while preserving proprietary extensions around them.
Routing also does not abolish concentration. If one frontier model remains decisively better on enough valuable tasks, traffic will still concentrate there. Winner-take-all behavior requires capability advantages large enough to outweigh cost, latency, portability, and policy constraints. The router makes that threshold visible; it does not determine the answer.
Gateways remain consequential only while buyers have multiple viable models, low switching friction, meaningful capability differences, and freedom to move workloads. Remove broad model access or make provider-specific tools indispensable, and the gateway returns to fallback plumbing.
Cheap switching is reproducible; accountable judgment is not
A team can copy basic routing logic: choose the cheapest eligible model, retry on failure, and send difficult requests to a frontier provider. That is useful, but it does not create a durable control plane. The harder capability is deciding under multiple constraints and retaining an auditable account of the decision.
A policy-aware router must answer questions that a price comparator cannot. Was the request allowed to leave a particular jurisdiction? Could the selected model process the relevant data class? What quality threshold applied? Which model version produced the output? Why did the workflow invoke or bypass a human reviewer? What happened when the first model failed?
The harder moat is not lower cost but safety auditability: the ability to reconstruct the policy, model, tools, data conditions, and escalation path behind an automated result.
Meta’s moderation systems show why efficiency metrics are insufficient. Meta says its AI moderation makes 13% fewer errors and identifies 10% more violations than human moderators, while some Instagram and Facebook users reported that automated moderation deleted their accounts. Both facts can coexist. Aggregate improvement does not establish whether a particular high-impact decision was correct, reviewable, or reversible.
A team that optimizes only average cost or accuracy can reproduce that failure at a larger scale. Its router may send a sensitive task to a model that performs well statistically but violates a specific policy. It may optimize latency by skipping review or select a model using a benchmark that does not represent the affected user. By allocating the model before generation, the router automates judgment one layer earlier.
Operators therefore need explicit escalation rules, policy boundaries, model-version records, and outcome feedback. They should not seek a universally best model; no model is best independent of the task. They need to make each tradeoff declared, repeatable, and inspectable.
The decision layer inherits the power
A router does not need to own the models or compute to shape the market. It needs enough viable options to make selection real and enough workflow context to make selection consequential. Then it can direct demand while recording who was eligible, what was spent, and why one model won.
Inference costs above half of revenue and a 60% share of US-company token usage are not just cost and geography figures. They mark the same shift: model choice has stopped being a one-time architecture decision and become a repeated, accountable purchase. When intelligence is bought per request, the layer that can explain every purchase inherits the stack.
How Meta’s coverage framing shifted, 2024 to 2026
| Framing | 2024 share | 2026 share |
|---|---|---|
| Consumer | 37.3% | 33.6% |
| Developer | 14.9% | 12.5% |
| Enterprise | 10.8% | 15.7% |
| Regulation | 18.7% | 14.0% |
| Research | 16.5% | 12.0% |
Frequently asked questions
What is an AI model router?
It is a control layer that classifies each request, identifies eligible models, selects among them using cost, quality, latency, availability, and policy constraints, and may retry, escalate, or compare outputs.
Why are companies adopting model routing now?
Model capabilities and inference prices are changing too quickly for a single-model default to remain efficient. Routing lets companies reserve expensive models for tasks that justify them while sending routine work to cheaper or faster alternatives.
Is Meta’s model router available as a public product?
No. The piece describes it as an internal project under development, with no evidence that it is a public offering or an adopted interoperability standard.
Does routing eliminate dependence on AI providers?
Not completely. A gateway can normalize basic model calls, but proprietary tools, conversation state, safety systems, structured-output guarantees, sandboxes, and evaluation systems can still lock workflows to a provider.
What makes a model router defensible rather than easy to copy?
Basic price-based routing and failover are reproducible. The harder capability is auditability: reconstructing the policy, model version, tools, data conditions, evaluator, failures, and escalation path behind every automated result.