Domestic LLM Price War Intensifies: Inference Cost Restructuring Through a Flagship Launch

1. Starting with Price: Inference Costs Are Being Redefined

The most noteworthy aspect of a cloud provider’s recently released flagship model isn’t its benchmark scores—it’s the price sheet. Per-million-token list pricing: 1.3 RMB for cached input, 13 RMB for uncached input, and 68 RMB for output. Compared to the previous flagship generation’s 2 / 20 / 100 RMB, input prices dropped roughly 35% and output prices roughly 32%. Converted to USD (approximately $2 input, $10 output), this pricing level sits at roughly one-fifth to one-half of what some leading overseas closed-source models charge.

What do these numbers mean? Consider a concrete engineering scenario. Suppose you need the model to read through a 300-page bidding document (approximately 150,000 tokens) and perform one round of cross-chapter data verification:

• Input cost: 150K tokens × 13 RMB/million ≈ 1.95 RMB (uncached)
• Output cost: Assuming 8,000 tokens of structured verification results ≈ 0.54 RMB
• Total per-round cost: Approximately 2.5 RMB

If the same task ran on a closed-source model priced at $10 input and $50 output, the per-round cost would be roughly 12–15 RMB. When tasks require repeated iteration and multiple rounds of rework, the cost gap widens to more than tenfold. This is the underlying logic of the “evaluation coordinate shift”—moving from model capability leaderboards to unit-task economic accounting.

Engineering Implications of Cache-Hit Pricing

Worth highlighting separately is the “cache hit” pricing tier. Cached input at 1.3 RMB per million tokens is only one-tenth the uncached price. This sends a clear signal: context reuse is the core lever for cost optimization.

In practical engineering, cache hits typically apply to the following scenarios:

# Illustrative pseudocode: multi-turn conversation cost structure with cache reuse
system_prompt = load_long_system_prompt()  # ~5,000 tokens, fixed
knowledge_base = load_domain_docs()        # ~50,000 tokens, infrequently changed
# First round: everything is uncached, higher cost
response_1 = model.chat(
    system=system_prompt,
    context=knowledge_base,
    user="Please extract the key clauses from the document"
)
# Subsequent rounds: system + knowledge_base hit cache
# Only the user portion is billed as uncached, significantly lower cost
response_2 = model.chat(
    system=system_prompt,      # cache hit
    context=knowledge_base,    # cache hit
    user="Please analyze the risks in clause three"
)

For scenarios requiring long-running sessions, fixed knowledge-base Q&A, or continuous codebase understanding, caching mechanisms can reduce effective input costs by an order of magnitude. When making technology choices, developers should not look at the “uncached input price” alone but should incorporate cache hit rates into their cost models.

2. Capability: Engineering Deployment of Long Context and Multimodality

Beyond pricing, several key capability parameters of this flagship generation deserve attention:

Context window reaching the million-token level. What does this magnitude of context mean? Taking the code scenario as an example, a million tokens can accommodate a complete codebase for a mid-sized project (roughly 200,000–300,000 lines of code), plus full documentation, configuration files, and historical commit records. This makes “whole-repository understanding” tasks possible, rather than being limited to single-file fragment analysis.

Native visual understanding support. Multimodal capability moving from “bolt-on” to “native” means the model establishes joint text-image representations during training. In engineering practice, this directly affects the feasibility of the following scenarios:

• Joint reasoning over architecture diagrams and code: input a system architecture diagram and the model directly generates corresponding interface definitions or data models
• UI screenshot-to-code conversion: design mockups directly converted to front-end component structures
• Cross-analysis of log charts and anomaly text

Terminal task benchmark performance. On evaluations like Terminal-Bench that target real terminal operations, this model achieved 65.7%, narrowing the gap with leading closed-source solutions to within 1 percentage point. The value of such evaluations lies in measuring the model’s multi-step operation capability in real command-line environments, rather than single-turn Q&A accuracy.

Engineering Challenges of Multi-Agent Architectures

Notably, this model generation has been specifically optimized for multi-agent tasks. The basic approach of multi-agent architecture is: decompose a complex task into multiple subtasks, executed in parallel or sequentially by different agent instances, then aggregate the results.

The engineering benefits of this architecture are significant:

# Illustrative configuration: multi-agent task decomposition
task: "Complete a market analysis report"
agents:
  - name: data_collector
    role: "Extract metrics from structured data sources"
  - name: trend_analyzer
    role: "Perform trend analysis on time-series data"
  - name: report_writer
    role: "Integrate analysis results and generate a structured report"
coordination: sequential_with_feedback

But multi-agent architectures also introduce new cost and governance challenges: each sub-agent independently consumes tokens, and the longer the task chain, the greater the total consumption. Without effective quota control and task orchestration, it’s easy to end up with “quota exhausted before the task completes.” This is precisely the problem discussed in the next section.

3. The Third Sheet: Availability Governance Is the Real Barrier

Two days after launch, the team pinned an apology in the comments section: some subscription users encountered rate limiting when using the new model, hitting the rolling window quota limit before tasks completed, and multi-agent tasks exhibited abnormal consumption. The compensation plan was to reset quotas for all subscription members and provide compensation at 25% of the monthly total.

The problem this incident exposed is more worthy of developer attention than benchmark scores and pricing: when model capability is strong enough and pricing low enough, availability governance becomes the real bottleneck.

The Engineering Nature of Rolling Window Rate Limiting

Rolling window rate limiting is a common API quota management strategy. Its basic logic is: within any given time window (e.g., 5 hours), a user’s cumulative consumption cannot exceed a certain threshold. Unlike fixed windows, rolling windows continuously “release” older consumption records as time passes.

This strategy is friendly to short tasks but has a structural conflict with long tasks and multi-agent tasks:

# Illustrative pseudocode: long-task risk under rolling windows
window_size = 5 * 60 * 60  # 5 hours, in seconds
quota_limit = 1000000      # token limit within the window
def check_quota(task):
    current_usage = sum(
        record.tokens for record in usage_records
        if record.timestamp > now() - window_size
    )
    if current_usage + task.estimated_tokens > quota_limit:
        raise QuotaExceededError("Estimated task consumption exceeds window quota")
    return True
# Problem: multi-agent task consumption is dynamic
# Inaccurate estimation → task rate-limited midway → all prior work wasted

For multi-agent tasks, each sub-agent’s consumption depends on the previous step’s output, making it difficult to accurately estimate total consumption before the task begins. If the rate-limiting strategy is too rigid, it leads to the poor experience of “task cut off halfway through.”

Engineering Recommendations for Availability Governance

From a developer’s perspective, the following engineering approaches can improve task success rates when facing such rate-limiting mechanisms:

Task sharding and checkpoint-based resumption. Split long tasks into independently executable segments, persisting intermediate state after each segment completes. When rate-limited, resume from the most recent checkpoint rather than starting over.

# Illustrative pseudocode: task orchestration with checkpoint resumption
def run_long_task(task, checkpoint_store):
    steps = decompose(task)
    for i, step in enumerate(steps):
        if checkpoint_store.exists(i):
            result = checkpoint_store.load(i)
            continue
        try:
            result = execute(step)
            checkpoint_store.save(i, result)
        except QuotaExceededError:
            # Save progress and continue after the window resets
            schedule_retry(task, next_window_start())
            return
    return aggregate_results(steps)

Dynamic budget allocation. In multi-agent architectures, set independent token budget caps for each sub-agent to prevent a single subtask from consuming excessive resources and triggering rate limits for the entire task.

Cache-first strategy. Reuse cache hits wherever possible to reduce uncached input consumption. For fixed system prompts and knowledge bases, ensure they are properly cached.

4. Three Dimensions for Developer Model Selection

Taking a comprehensive view, model selection today can no longer rely on a single dimension. A three-dimensional evaluation is recommended:

First, unit task cost. Don’t just look at the per-million-token list price—factor in cache hit rates, average input-output ratios, and rework iterations. A model that is slightly more expensive but achieves higher first-pass success rates may be more economical than a cheaper model requiring multiple rounds of rework.

Second, capability fit. Million-token context suits whole-repository understanding and long-document analysis; multimodal capability suits mixed text-image scenarios; terminal task capability suits automated operations and command-line work. Clarify your core scenarios rather than blindly pursuing “all-in-one” capability.

Third, availability guarantees. Understand the target platform’s rate-limiting policies, quota management mechanisms, and failure compensation plans. For critical production tasks, design fallback plans and multi-model backup strategies.

5. Conclusion

When domestic flagship models push pricing to one-fifth to one-half of the global top tier, the industry’s evaluation coordinate system genuinely needs adjustment. Benchmark scores remain important, but “how much does it cost to complete a real task, how many times does it fail, and how many rounds of rework are needed” is becoming a more engineering-relevant measuring standard.

At the same time, availability governance challenges are surfacing. Low prices and strong capabilities mean little if a task gets rate-limited halfway through—the cost of wasted work is actually higher. For developers and enterprise users, choosing a model means not just choosing a set of parameters, but choosing a cost model, a capability boundary, and an availability guarantee mechanism.

In this sense, the real highlight of this launch isn’t a particular benchmark number—it’s that it has pushed “inference cost” and “availability governance” to the center of industry discussion.