Pricing Logic in the Era of Task-Based LLM Pricing

Why a Price Hike Sparked Debate

When a leading model provider released a new version with official pricing several times higher than previous levels—output priced in the hundreds of RMB per million tokens, with input and cache-hit prices also rising—the developer community took notice. The reason is straightforward: over the past two years, the domestic LLM market has been defined by “capable enough, extremely cheap” pricing. User expectations were set accordingly. A sudden official price tag significantly above the market average—and in some cases above promotional pricing from overseas flagship models—naturally creates a perception gap.

But focusing only on whether the price is “expensive” misses the real signal. Price is never just a function of cost; it is also a statement—what the vendor believes its model is worth.

Aligning with Flagship Pricing: A Deliberate Positioning

Notably, the adjusted price closely mirrors the standard pricing of a certain overseas flagship model. The distinction between “standard price” and “promotional price” matters here: that overseas model’s actual charged price during promotion periods is far below its standard price, which only resumes after the promo ends. In other words, during the promotional window, calling the new model could actually cost more than calling that overseas flagship.

The logic is clear: the new model’s pricing aligns not with the competitor’s discount but with its perceived “standard value.” Discounts are operational decisions that shift with competitive dynamics; the standard price is the vendor’s own valuation of its intelligence level. By choosing to align with the latter, this vendor is explicitly stating—at the pricing level—that it no longer competes as a “shadow model” or a “budget alternative.” It is entering the flagship pricing tier directly. Among Chinese model companies, this is a first.

It takes ambition, but ambition needs substance. Without convincing evaluation results, such pricing would be quickly abandoned by the market.

The Narrative Price: The Ten-Day Window Before Weights Are Released

To understand this pricing, one must consider a key action: the model weights are scheduled for public release before July 27.

Once weights are public, third-party inference providers will almost certainly list the same model at lower prices. The price of an open-weight model is determined by compute costs and market competition, not by the original vendor’s official list price. Thus, the official price may only hold for around ten days.

What is the function of those ten days of official pricing? It is not a faithful reflection of cost. It is a “narrative price”—a number carved into the market’s perception of the model’s value before the weights become commoditized. When developers later see the same model at a third of the official price (or less) on third-party platforms, their first reaction will be “what a bargain,” because the official price tag has already anchored value perception.

Phase	Role of Official Pricing	Market State
Before weight release	Value anchor	Sole supply; price defines positioning
After weight release	Reference baseline	Multiple suppliers; price declines
Long term	Brand pricing	Official channel vs. third-party channels diverge

The combination of “open source + high price” has almost no precedent in global model history. Open source means relinquishing price monopoly; high price means refusing a price war. Using both simultaneously can only be explained as: using high pricing for brand positioning, and open source for ecosystem expansion.

The Cost Center Has Shifted to Output

For developers, the more important thing to watch is not the sticker price but the shift in bill structure.

The traditional per-token pricing mindset is: input is cheap, output is expensive, but output share is limited. In the era of reasoning models, this structure is completely disrupted. A model generates extensive thinking before delivering a final answer, and those thinking tokens are typically all billed as output. Reasoning models are designed to “think as much as possible,” so output-side token consumption expands dramatically.

The result: the multiple of the price increase is not the multiple of the bill increase. Actual bill growth is often steeper because:

• Input price increases affect context and prompt costs;
• Output price increases affect both the entire thinking process and the final answer;
• Thinking length is not controlled by the user; it is controlled by the model’s strategy.

For pure chat scenarios, an output price in the hundreds of RMB per million tokens is nearly unaffordable. The real target customers for this pricing are not chat users but agents—machine-to-machine token consumption scenarios.

From “Per Million Tokens” to “Per Task”

When the buyer shifts from human to agent, the cost accounting method changes as well.

In agent scenarios, no one calculates the cost per million tokens, because token count is itself an unpredictable intermediate variable. The truly meaningful metric is: how much does it cost to complete one task.

This shift in pricing logic parallels cloud computing evolving from “per resource” to “per request” or “per invocation.” Developers care about unit business cost, not unit resource cost.

Measured per task, the picture changes. The cost for certain high-priced models to complete a typical task may be close to that of other flagship models in the same tier, or even half that of more expensive models. In a “per-task pricing” world, a high absolute unit price does not mean high total cost—what matters is task completion rate and retry count.

Per-task cost = (input tokens × input price + output tokens × output price) × retry factor

The retry factor is the hidden variable. If a cheap model needs three attempts to finish a task while an expensive model succeeds on the first try, the cheap model’s actual cost could be two to three times higher.

Cost Divergence Within the Open-Weight Camp

However, narrowing the comparison to the open-weight camp yields a different conclusion.

When completing the same task, cost differences among open-source models can reach an order of magnitude. Some models cost on the order of thirty cents per task; others only a few cents. This divergence comes from three sources:

1. Parameter scale and inference cost: larger models incur higher compute overhead per inference;
2. Thinking strategy: whether long reasoning is enforced, and whether thinking budgets are supported;
3. Inference optimization maturity: engineering practices such as quantization, distillation, and batch processing.

For developers, this means “open source” does not equal “cheap,” nor does it equal “homogeneous.” When selecting models in the open-weight ecosystem, you need to build your own evaluation baseline rather than relying on official list prices or a single leaderboard.

Practical Recommendations for Developers

First, replace token-based cost metrics with task-based ones. Build your own task set and measure each model’s per-task cost in real business scenarios, including failed retries. That is the only comparable number.

Second, distinguish official channels from third-party channels. After weights are released, the same model will have multiple suppliers. Official channels offer stability, SLAs, and latest features; third-party channels offer lower prices. Segment your traffic based on business requirements for stability.

Third, control thinking budgets. If a model supports thinking-length control or tiered thinking modes, use lower tiers on non-critical paths. For reasoning models, the cost center is on the output side—the thinking budget is the cost budget.

Fourth, design degradation strategies for agent scenarios. Use high-priced models for high-value tasks, low-priced models for low-value tasks, and rule-based or small models for the middle layer. Relying on a single model for everything becomes cost-ungovernable in the agent era.

# Example: route tasks by complexity
def route_task(task):
    if task.complexity == "high":
        return call_premium_model(task)
    elif task.complexity == "medium":
        return call_balanced_model(task)
    else:
        return call_lightweight_model(task)

Fifth, watch the weight release timeline. The “validity period” of official pricing is often the window before weights are opened. Conduct technical validation within that window, then optimize costs after weights are released. This is a more rational rhythm.

Conclusion

A price increase, on the surface, is a numeric change; at its core, it is a positioning statement. It announces a possibility: a Chinese model company can refuse to be a shadow at the pricing level, refuse a pure price war, and instead use pricing to express its own valuation of its intelligence.

For developers, what matters is not judging whether the price is “expensive,” but understanding that the pricing logic underneath is shifting—from per million tokens to per task, from the input side to the output side, and from official list prices to market equilibrium prices. Whoever completes this conversion faster will turn cost control into a competitive advantage in the agent era.