The Model Makers' Fight for Pricing Power

At the height of the AI boom, why would model developers move the model itself out of sight, behind an agent?

From the outside, the frontier AI labs appear to be enjoying an extraordinary expansion. In February 2026, Anthropic announced a financing round at a $380 billion post-money valuation. In the same announcement, it said Claude Code’s annualized revenue run rate had exceeded $2.5 billion, more than doubling since the beginning of the year. That measure extrapolates the current pace of revenue over a year. Anthropic’s February 12 announcement.

Valuations, growth, and technical progress make for an impressive picture. Beneath it, however, a contest over customer ownership and pricing power is taking shape.

Why would companies at the center of a technological revolution need to defend their businesses at all?

I write from the perspective of an enterprise AI and SaaS product veteran and entrepreneur. In two earlier essays, I examined the weaknesses of the model API business:

• AI Model Valuations: Business Economics and Reverse DCF (Chinese)
• Why the LLM API Business Has Difficult Economics (Chinese)

The model developers’ recent moves suggest a response to those weaknesses. I see three overlapping phases in the industry’s development, with companies moving through them at different speeds.

• Phase one: the model developer’s API plus a third-party agent. Early in the generative AI boom, a small group of frontier labs held a substantial capability advantage. Application developers built agents on their APIs. That scarcity gave the labs pricing leverage and the prospect of attractive software margins. Their ability to sustain those margins would depend on how long the capability advantage lasted.
• Phase two: an inference provider’s API plus a third-party agent. As open-weight models became credible substitutes for more tasks, specialized inference providers began competing on serving efficiency and price. Agent developers could introduce a routing layer, retaining the customer relationship while sending routine work to cheaper models. The model developer risked becoming a replaceable supplier behind someone else’s interface, while continuing to bear substantial research and infrastructure spending.
• Phase three: model developers launch their own general-purpose agents. Building the application becomes a form of forward integration. The developer seeks to control the customer relationship, the workflow, and the commercial terms under which its models are used. The strategic objective is straightforward: retain the ability to price the service around its value to the customer.

One manifestation of that shift is an interface that delegates model selection to the provider. In the Chinese essay, I cited three product observations involving Muse, Grok bot, and Gemini Agent:

• Muse’s personal edition did not offer a model selector.
• Grok bot restricted model choice to its own models and otherwise routed tasks to what it described as the most suitable backend.
• The Gemini Spark app did not expose a model selector.

These observations lack versioned official documentation and should be read with that limitation. Product names, editions, and available controls require confirmation before a purchasing decision.

Where the choice is delegated to the provider, users may have limited visibility into which model handles a particular step. Claude Code illustrates a different arrangement: its documentation provides for explicit model selection and an opusplan setting that uses Opus for planning and Sonnet for execution. Routing and user choice can coexist. Claude Code model configuration.

Removing a selector can simplify an interface. It can also serve a commercial purpose: the provider prices the overall service while controlling the mix of resources used to deliver it. The engineering premise behind this strategy is that many steps in an agent workflow may not require the most capable, most expensive model available.

01. The Financial Incentive and the Engineering Premise

The shift from selling API access to selling an agent becomes easier to understand when its economics and engineering are considered together.

1.1 Reclaiming Pricing Power: From Token Prices to Customer Value

In an architecture built around an independent agent and interchangeable inference services, the agent developer owns the customer relationship and the business context. It can decide which underlying model to buy for each task.

That creates pressure on upstream suppliers. If several models are adequate substitutes, customers can compare prices and switch. Competition pushes the service toward cost-based pricing, with electricity, hardware depreciation, utilization, and serving efficiency becoming important variables. A frontier developer must also recover the research spending behind its models.

An agent sold directly by the model developer changes the unit of comparison. Instead of buying a million tokens, a customer buys a subscription, a seat, a completed task, or access to a workflow. The provider can seek a price tied to the value of the work while optimizing its internal delivery costs.

The supplier gains room to price the application around customer value. How much room it gains depends on competition and willingness to pay.

1.2 Why Routing Can Work: Uneven Demand for Reasoning

Why might a company be comfortable choosing the model on the user’s behalf, even if its flagship does not lead every benchmark?

Because the value of a more capable model can differ sharply from one step to another.

In a single-turn chatbot interaction, one question produces one answer. A capability gap can be immediately visible. An agent, by contrast, may break a request into a sequence of actions: planning, searching, parsing a web page’s document object model, extracting JSON fields, fixing a syntax error, and assembling a result.

Consider an illustrative workflow of 30 to 100 steps, with the following workload mix:

• About 5–10% of steps require frontier-level reasoning, such as difficult planning or decisions at unusual edge cases.
• The remaining 90–95% involve comparatively routine work, such as summarizing a page, converting formats, or checking fields.

Suppose a smaller model could perform the routine steps to the required standard at one-fiftieth of the inference cost and one-tenth of the latency. A Mini- or Flash-tier model, or a distilled model with 7 billion or 8 billion parameters, is the kind of lower-cost alternative contemplated here. The proportions and cost ratios are scenario inputs. Establishing their applicability requires evaluation on the actual workload.

The mechanism remains economically meaningful without treating those ratios as universal. If a less expensive model meets the required quality threshold on routine steps, reserving the more capable model for difficult decisions can reduce cost. If it causes additional errors, retries, or human review, some or all of the savings disappear.

Sending every step to a frontier model can increase both inference expense and latency, including time to first token. A provider with a sufficiently capable planner, a well-chosen model portfolio, and effective execution scaffolding may therefore compete on the quality of the completed task rather than on a single model’s benchmark ranking.

1.3 Why an Aggregator May Preserve Model Choice

An enterprise platform organized around Microsoft 365 or GitHub has an incentive to make its own workflow indispensable while drawing on multiple model suppliers. Giving customers model choice can fit that strategy: it reduces dependence on any one supplier while keeping the application relationship with the platform.

The incentive is broader than any particular Copilot interface. Product controls vary, and Claude Code’s documented model selection demonstrates that model developers can also pursue a hybrid approach.

For a developer seeking to commercialize its own models, an open selector creates a different trade-off. It makes comparisons more explicit and may complicate the provider’s effort to balance workloads across its GPU or TPU infrastructure. A managed router gives the provider more control over that allocation. Neither approach determines the commercial outcome on its own.

1.4 Execution Traces and the Potential for Distillation

Owning the agent may also give the provider a more complete view of how a task is carried out.

In a third-party agent architecture, the application operator can observe the entire execution trace: which tool call failed, how the agent retried, and which sequence eventually worked. An API supplier may see only individual requests, unless the application sends it the wider context.

A model developer operating its own agent can potentially retain that end-to-end record. Successful traces from a more capable model could then support training or distillation for a smaller model, allowing it to handle similar work at lower cost.

A successful feedback loop could move recurring work to a smaller model over successive training cycles. The original’s suggestion of a transition within weeks is an illustrative timetable. Data permissions, contractual restrictions, privacy controls, evaluation, and training effectiveness determine whether the loop is available and how quickly it can work.

If the loop works, it creates an attractive economic prospect: maintain the customer’s required quality while reducing the cost of delivery. The resulting improvement in contribution economics would still need to be distinguished from company-wide profitability, which also depends on research, infrastructure, sales, and other expenses.

02. A Four-Stage Competitive Scenario

Consider the ecosystem incumbents, such as Google, Meta, and xAI; independent frontier labs, including OpenAI and Anthropic; independent general-purpose agent startups; and specialized inference providers. Viewed together, they suggest a possible four-stage competitive progression.

The stages below are a scenario, not a forecast with a specified timetable or probability.

2.1 Stage One: Internal Routing and the Delivery-Cost Spread

The first stage is to internalize routing. A provider attracts customers with a flagship model and a branded application, then decides how much computation each request needs and which model should supply it.

The original’s numerical example assumes a 50–80% reduction in reasoning-token use and an allocation in which more than 85% of execution steps go to smaller models. Those figures illustrate the proposed mechanism. The source essay attributes them to GPT-5’s routing without supplying evidence for that attribution, so they cannot establish a provider’s actual production workload or realized savings.

It is also important to distinguish application-level routing from the API contract for a model. OpenAI’s GPT-5 API documentation describes configurable reasoning effort; that does not disclose the workload mix or realized margins of an entire agent service. GPT-5 API documentation.

The economic proposition is conditional but clear. A subscription can be priced around the value of the finished work, while internal routing lowers the cost of supplying it. What I call “margin arbitrage” is the effort to retain that price-cost spread. Actual margins depend on usage, routing accuracy, infrastructure utilization, competition, and support requirements.

2.2 Stage Two: Independent Agent Developers Face Pressure From Both Directions

An independent startup that buys external model APIs and orchestrates broadly available tools can face two forms of competition.

• Distribution from ecosystem incumbents. An agent embedded in an operating system, browser, social platform, or office suite reaches customers through an existing channel. That can make distribution difficult for an independent product that asks users to adopt a separate interface.
• Forward integration by model developers. OpenAI and Anthropic have reasons to sell applications directly rather than remain wholesale suppliers to other developers. Claude Code illustrates the opportunity: a model developer can own a substantial developer-facing product as well as supply APIs. Anthropic’s February 2026 disclosure of a Claude Code revenue run rate above $2.5 billion shows the commercial scale such a product can reach. Computer-use capabilities also extend the range of workflows a model developer can seek to serve.

The result could be channel conflict. A lab’s application may compete with products built by its API customers. The lab would then be selling both an input and a finished service, potentially moving into the same market as its customers.

An independent general-purpose agent therefore needs a stronger reason for customers to adopt and retain it.

2.3 Stage Three: What Separates a Frontier Lab From an Inference Utility?

The third stage exposes a financing problem. An inference specialist serving open-weight models does not bear the original developer’s full pretraining research bill. It can concentrate on serving efficiency, hardware economics, and utilization, although those activities still require investment.

A frontier lab has a different cost structure. If a third-party router sends most routine work elsewhere and purchases the frontier model only for difficult tasks, the lab must recover its research spending from a narrower pool of demand, higher prices, or other revenue sources.

Put starkly, a lab could fund its entire research program while being called only for the hardest tenth of a workflow. That is the mismatch behind the original’s “100% of the research burden, 10% of the traffic” formulation. The figures are illustrative; the financial outcome depends on the value and price of the remaining tasks, cost efficiency, and financing.

The argument identifies two possible defenses:

1. Expand from a stateless API into a stateful agent runtime. The service can include persistent memory, saved context, code-execution environments, and integrations through protocols such as MCP. These capabilities may make switching more involved than substituting one inference endpoint for another. The source essay also cites context-caching discounts of up to 90%; any such discount applies to eligible cached input under the relevant pricing terms. Its effect on total agent costs depends on the workload. Portability, implementation choices, and contract terms determine how difficult it is to move the wider service.
2. Remain indispensable at the hardest planning and correction steps. If a lab maintains a material advantage on the decisions that determine task success, it can use that capability to support an integrated application. Routine work can then be assigned to its lower-cost models. This is the bundling logic behind the “10% planning brain” argument; the percentage is a scenario assumption, and the capability advantage is something the provider must continue to earn.

The most exposed position in this scenario is a model developer with neither a defensible capability lead nor a differentiated application. It bears substantial model-development costs but lacks both a compelling reason for customers to pay a premium and a direct channel through which to retain them. Price competition could then place it alongside inference providers with a different cost base.

Open-weight inference providers would face pressure as well. Their scope for differentiation would rest increasingly on serving efficiency, reliability, data residency, and customer-specific requirements.

2.4 Stage Four: Three Potential Positions, With Room for Vertical Specialists

If the preceding pressures persist, the market could organize around three broad positions. The categories describe business models; a company may occupy more than one, and the outcome is not predetermined.

Outside those positions, independent agent companies may find more defensible opportunities in vertical markets: workflows requiring access to private data, demanding compliance controls, or close integration with complex, nonstandard operations.

The remaining “10%” is shorthand for this specialized territory, rather than an estimate of its market share. A product grounded in a customer’s specific operations may be harder to replace than a general-purpose layer over widely available APIs.

03. The Contest Is Over Who Captures the Value

The progression from a model developer’s API, to an interchangeable inference service, to an agent sold by the model developer captures an important commercial tension. Technical capability creates an opportunity, but the interface, workflow, and customer relationship influence who can charge for it.

A model selector is a small interface element with potentially large strategic implications. Delegating the decision to a provider can let that provider optimize delivery behind a single service price. Preserving choice can help an application platform aggregate competing suppliers. Neither design is, on its own, proof of superior economics.

The core thesis is that cheap tokens need not make every model developer a commodity supplier. A company that retains differentiated reasoning capabilities, operates a valuable application, and manages delivery costs effectively may keep a greater share of the value created by AI. Its success will show up in customer retention, cost, and pricing power. The ambition is to sell the appliance, manage the grid, and retain a say in the bill.

04. Original Publication

This is an edited English translation of the Chinese article, first published on the WeChat public account “中老年叨叨” on October 14, 2026, at 19:25 China Standard Time. Read the WeChat original.

The English edition preserves the original’s competitive framework while clarifying financial terminology and distinguishing reported facts, product observations, illustrative assumptions, and conditional scenarios. It does not present the original’s workload percentages, cost ratios, or market shares as independently measured results. Research spending and capital expenditure are not interchangeable accounting categories; annualized revenue run rate, gross margin, and net profitability are also distinct measures.

Primary sources consulted for this edition:

• Anthropic’s February 12, 2026, financing announcement, supporting the reported valuation and Claude Code revenue run rate.
• Claude Code model configuration, supporting explicit model selection and the documented planning/execution model switch.
• OpenAI’s GPT-5 API documentation, documenting the API model and configurable reasoning effort; it does not establish the routing shares or service margins assumed in the source essay.