Why LLM API Prices Are Surging: Value Anchoring and the Shift to Agent Billing

In recent years, as large language models have made rapid capability leaps, their commercial pricing strategies have grown increasingly complex. A widely watched new-generation model recently raised its API prices by a large margin: output tokens jumped to roughly 100 RMB per million tokens, and input and cache-hit prices rose several-fold in step. The move sparked heated debate across the developer community. On the surface, it looks like a “sky-high” price detached from what real applications can absorb. But once you examine the model’s weight-release schedule, its shifting target customers, and the underlying billing logic, the deeper business and technical reasoning becomes clear.

Price Anchoring During the Pre-Open-Weights Window

To understand the steep list price, start with the model’s release cadence and weight-opening plan. According to available information, the model’s open weights are scheduled to be released at the end of the month. Before the weights are fully commoditized—before third-party inference providers can deploy them at low cost and offer cheaper service—the effective window for the official high price is actually very short: only about ten days.

During this window, the ~100 RMB output price is not primarily a vehicle for retail API profit. Its core function is to “stamp an anchor” on the model’s market value before the weights are commoditized—a classic case of the anchoring effect from behavioral economics. Once the official price establishes a 100 RMB reference point, subsequent price drops will be read as “discounts” rather than “devaluation.” Ten days later, when developers deploy the open weights themselves or turn to third-party platforms and see equivalent compute offered at 30 RMB or less, their first reaction will be “what a bargain,” not “this model was only ever worth that much.” Managing this psychological expectation is critical for a model provider that wants to preserve brand positioning and premium pricing power within an open-weight ecosystem.

From Human-Machine to Machine-Machine: A Billing Paradigm Shift

At 100 RMB per million output tokens, conventional chat is unaffordable for any ordinary user. Yet the model’s launch configuration points in another direction: the highest deep-thinking tier is enabled by default, and every intermediate token generated during reasoning is billed as output. Before producing a final answer, the model performs extensive internal reasoning and logical computation, and these hidden costs make a single conversation extremely expensive.

This pricing effectively filters out consumer users. The real target is Agent scenarios—machine-to-machine token consumption in high-frequency, high-density tasks. Developers accustomed to reasoning in “price per million tokens” find that metric breaks down here, because a single Agent task can involve multi-turn self-correction, tool calls, and long chains of reasoning, so per-token billing no longer reflects the actual return on investment.

Buyer evaluation criteria are changing fundamentally, and the industry is moving toward per-task pricing. In a per-task world, developers and enterprises no longer fixate on how many tokens were consumed along the way; they ask, “How much does it cost to complete one standard business task?” For example, if this model completes a composite task involving complex data analysis and code generation for an average of $0.94, that lands in the same tier as the $1.04 that top closed-source models charge for the same task—and it is only about half the cost of some ultra-large-architecture models. Measured on this dimension, the model’s cost-effectiveness on demanding tasks is far from uncompetitive.

Cost Competition and Engineering Challenges Inside the Open-Weight Camp

While the per-task cost holds up on hard Agent benchmarks, a horizontal comparison within the open-weight ecosystem tells a very different story.

Parameter efficiency and algorithmic optimization in the open-source ecosystem have reached a remarkably high level. The same standard task can be completed by some lightweight open models with better architectures for $0.32, and industrial-grade models with extreme memory and compute optimizations push single-task cost down to the 4-cent level. A few months ago, part of the open-source camp permanently cut its flagship models to extremely low input/output prices; the new model’s output list price is more than ten times higher, which is undoubtedly a shock to the open-source community.

This cost gap forces enterprise architects to re-examine their inference infrastructure. For business lines pursuing maximum cost efficiency, several engineering practices are common:

1. Hybrid Routing

Introduce an API gateway with an intelligent routing layer that dispatches requests dynamically by complexity. Simple tasks such as intent classification or text summarization are routed to low-cost open-weight models; only hard tasks requiring long-chain reasoning, complex code generation, or multi-step planning are escalated to the expensive “deep thinking” model.

Illustrative routing pseudocode:

def route_model(query_context):
    complexity_score = evaluate_complexity(query_context)
    if complexity_score < 0.3:
        return "low_cost_open_weight_model"
    elif complexity_score < 0.7:
        return "standard_managed_model"
    else:
        # Enable deep thinking mode: accept higher cost for a higher success rate
        return "premium_max_thinking_model"

2. Aggressive Caching

With output costs as high as ~100 RMB per million tokens, building an efficient cache is the essential path to lower spend. This goes beyond simple question-answer pair caching and requires semantic-level caching. Generic tool definitions that the Agent is likely to invoke, fixed system prompts, and recurring data-processing patterns can be precomputed and stored. When the model encounters similar intermediate steps, the cache is hit directly, sharply reducing the number of thinking tokens that actually need to be generated.

3. Task-Level Budget Control

Enforce a budget-control module inside the Agent framework. For every task execution, set a hard token-consumption threshold and a spending cap. When deep thinking approaches the budget limit, the system should be able to forcibly truncate the run and fall back to a cheaper model for degraded handling, preventing the cost of a single task from spiraling out of control.

Conclusion and Outlook

The surge to the hundred-RMB level for output tokens is, at its core, a precise exercise in market psychology and customer segmentation. The provider uses the brief window before open-weight release to anchor the model’s value, and uses a high-threshold deep-thinking billing mechanism to pivot the service focus from consumer chat to complex, enterprise-grade Agent tasks.

For developers and architects, neither complaining about expensive APIs nor blindly embracing open source is a sound response to this price stratification. Future LLM application engineering will be judged less on tuning a single model and more on the combined strength of multi-model orchestration, task-level cost accounting, and cache engineering. On standardized cloud-native AI infrastructure such as Baidu AI Cloud, teams can more easily integrate general-purpose services—message queues, container platforms, and monitoring and alerting—to build Agent orchestration networks that combine high concurrency, low cost, and strong robustness. Only by understanding the technical substance behind the billing logic can engineering teams hold the initiative as this wave of LLM value repricing unfolds.