After model price cuts: why revenue, profit and compute demand can diverge

Lower model prices usually help application buyers. For model developers and data-center investors, the question is whether new paid demand offsets lower receipts per call and less equipment time per task. A price war can expand usage while reducing revenue. It can also make infrastructure busier while compressing the provider’s profit.

At the August 1, 2026, 23:00 Beijing-time cutoff, OpenAI offered GPT-5.6 in Sol, Terra and Luna tiers, while Anthropic offered Sonnet 5, Opus 4.8 and Fable 5.^[1][4][5][6] Customers could select among capability, latency and cost. The strongest model was therefore not necessarily the most profitable business. This archive revision retains that historical perspective rather than inserting later products.

Tiers expand choice and change the revenue mix

An enterprise can route classification and extraction to a cheaper model while reserving stronger models for difficult coding, planning or verification. OpenAI’s release materials listed GPT-5.6 input prices from $1 to $5 per million tokens. Anthropic allowed different reasoning-effort levels for Sonnet 5, with higher effort consuming more tokens.^[1][4] Price, resource use and capability need to be assessed together.

A low-cost tier can attract customers who would never have purchased the flagship. It can also move existing customers away from a more expensive tier. The first expands the business; the second may reduce the bill for unchanged work. The net effect requires data on additional usage and migration. More product names establish neither incremental revenue nor customer losses.

Input pricing is only part of a bill. Output length, cache reads, reasoning rounds, external tools and retries all matter. Two systems receiving the same input can produce different charges if one generates longer answers or repeatedly uses tools. Better first-pass success can instead reduce subsequent work. The $1–$5 range is an input-price range, not the price of a completed task.

Rankings need the same qualification. A higher score at greater effort should be accompanied by its latency and usage. A cheaper configuration with a lower score may still meet the buyer’s requirement. Extra capability has economic value when it reduces rework, speeds delivery or completes harder work, rather than merely exceeding an unnecessary benchmark threshold.

Price a successful task before deciding to migrate

A useful formula is cost per qualified task = (model calls + external tools + retries + human review + allocated migration and maintenance) / tasks meeting a pre-agreed standard. More outputs do not automatically enlarge the denominator. Lower human-review requirements must be demonstrated in the workflow; a better model score does not establish that approval steps or jobs can disappear.

The following examples use assumed renminbi costs, not any product’s price or customer result. An original process spends RMB100 on 100 successful tasks. A cheaper process spending RMB85 but succeeding on only 70 costs about RMB1.21 per success. A stronger process spending RMB120 for 150 successes costs RMB0.80. The success rate can reverse the purchasing conclusion.

Migration also requires upfront spending. Assume annual savings of RMB200,000 against RMB300,000 for adaptation, validation and training. Sustained savings give a 1.5-year simple payback, ignoring discounting and maintenance differences. If the workflow or interface changes materially after six months, the savings may never recover the investment. Lower API prices need to be evaluated over a usable lifetime.

Tests should preserve the actual task distribution and record error types and tail latency. Routing easy work to a cheaper model and escalating difficult work can save money, but routing mistakes can cause duplicate execution. A mixed-model architecture must include that overhead rather than promising savings from an idealized allocation.

More calls do not guarantee more gross profit

The supplier’s profit requires an additional bridge from price to service cost. Assume a task sells for RMB1 and costs RMB0.60 to serve, earning RMB0.40 of gross profit. If efficiency reduces cost by 30% to RMB0.42 while price also falls 30% to RMB0.70, the gross margin remains 40%, but gross profit per task falls to RMB0.28. Volume must rise approximately 42.9% merely to hold total gross profit: 0.40 / 0.28 − 1.

This does not estimate OpenAI or Anthropic margins. It demonstrates that a stable percentage can conceal lower unit profit. Insufficient additional usage would reduce revenue and profit dollars. Sustained expansion could instead generate enough contribution to support research, sales and platform overhead.

Research and training also sit outside the inference-service margin. A service can earn money after runtime costs while its company still consumes cash developing the next generation or reserving capacity. Conversely, large research spending does not prove each call loses money. Valuation should distinguish service economics, shared expenses and future capital commitments.

Competition determines how much efficiency the supplier retains. Similar results from several providers can pass savings to application customers through lower prices. A model that materially reduces failure on valuable work may retain a premium. Renewals and task results must support that pricing-power argument; a capability announcement alone does not.

Deeper agents use more work; efficiency reduces machine time

An agent may plan, retrieve, code, check and retry, sometimes running branches concurrently. A user request need not equal a single model call. Lower costs encourage experimentation with previously uneconomic processes, but steady demand requires continuing paid production. Free trials, temporary testing and internal evaluations cannot be extrapolated directly into permanent load.

Equipment requirements depend on successful task volume multiplied by machine time per task. Assume efficiency cuts the latter by 30% while task volume rises 50%. Total machine time becomes 1.5 × 0.7 = 1.05, a 5% increase. If task growth is only 20%, the result is 1.2 × 0.7 = 0.84, a 16% decline. Both changes are needed to determine the direction.

Revenue can diverge from machine time. In the independent assumption of 50% task growth, a halving of unit price leaves revenue at 1.5 × 0.5 = 0.75, down 25%, even as machine time could rise 5%. This is not a company forecast. It shows why a busier facility can coexist with tighter profit and payback.

Average utilization also differs from peak capability. Enterprise deadlines and sudden concurrency may require spare capacity. Long tasks impose different memory, network and scheduling demands. Sharing and batching improve efficiency but can increase waiting. Operators must balance cost with service obligations; higher GPU utilization is not automatically a better commercial result.

Contracts allocate the first benefit of efficiency

Under token-based pricing, an operator can initially retain a reduction in service cost before deciding whether to lower prices. Under GPU-hour rental, less time per task may initially benefit the customer, while the operator must fill the released hours. Reservations and minimum payments change the short-term allocation again. Actual responsibility requires the contract.

Fixed spending introduces a lag. Purchased equipment and leased sites continue to incur depreciation, interest and some operating expense when usage falls. Software changes utilization first; subsequent renewals and procurement can change equipment additions. Translating a week’s model news directly into lower quarterly construction skips that commercial process.

BloombergNEF’s public construction analysis identifies power and execution as important constraints.^[8] Cheaper models do not shorten interconnection, delivery and commissioning for a project with real demand. More announced products do not solve a project’s lack of customers either. Energized capacity, saleable services and actual billing sit closer to cash returns than planned floor space.

Region and workload mix matter as well. Queued background work can use off-peak capacity more easily than interactive services requiring local deployment and low latency. The same model can imply different equipment and redundancy requirements. Infrastructure analysis should work backwards from production requirements rather than from model names to megawatts.

Test growth with prices, paid work and cash

The favorable path combines sustained reductions in cost per successful task with faster expansion in paid work. Providers can then increase revenue or gross-profit dollars and fill existing capacity more reliably. Efficiency and equipment expansion can coexist. Slow demand, substantial migration to cheap tiers and fixed supply commitments instead turn efficiency into price and margin pressure.

Relevant disclosures include traffic and realized prices by tier, usage and success per task, peak latency and concurrency, capacity in service and customer collections. Model developers, application vendors and clouds each see only part of that chain. Registrations or call volume at one participant cannot stand in for revenue throughout the industry.

The available sources include Reuters’s July 24 report about Opus 5, without locating a corresponding official Anthropic product announcement by the original cutoff.^[7] The analysis therefore excludes its price, capability and training scale from calculations. The confirmed product tiers already provide sufficient evidence to examine demand elasticity and profit allocation.

Over 12–36 months, dependable completion of valuable work is the capability customers can repeatedly pay for. Model advances make that possible; adoption and collections establish whether it happens. Calls, revenue and hardware demand may move in different directions. Contracts and profits determine who receives the efficiency benefit.