When Flagship LLM API Prices Double: Billing Logic and Model Selection Guide

A notable pricing shift has emerged on LLM open platforms: a new-generation flagship model’s API price has risen sharply compared with its predecessor, forming a three-tier price structure—roughly triple-digit (in RMB) per million output tokens, double-digit per million input tokens, and single-digit per million cached tokens (all figures are order-of-magnitude examples for discussion only). The topic of “nominal unit price rising several times over” has sparked debate. For developers, the emotional question of “is it expensive?” is not useful. The real questions are three: What is the cost logic behind the increase? How does three-tier pricing affect the actual bill? And how should one choose between subscription plans and pay-as-you-go APIs? This article breaks each down.

1. Why Flagship Models Get More Expensive Each Generation

1.1 Capability Leaps Drive Up Inference Costs

Generational upgrades of flagship models typically come with three cost variables rising simultaneously:

• Context length expansion: Moving from the hundred-thousand-token level to the million-token level significantly increases attention computation and memory footprint as sequence length grows. A single inference on a long-context request costs far more than a short one.
• Larger parameter and activation counts: Although architectures such as Mixture-of-Experts (MoE) can control the activation ratio, once total parameters reach the trillion level, the engineering costs of routing, communication, and memory management still feed into pricing.
• Longer reasoning chains: Complex coding and agent tasks require multi-step thinking and tool calls, multiplying output token counts—and output is precisely the most expensive part of the billing.

1.2 Pricing Is a Stack of Cost Structure and Market Strategy

On the inference side, the prefill computation in the input stage can be highly parallelized, while the decode in the output stage must generate tokens autoregressively one at a time. This explains why output unit prices are usually several times higher than input. On the market side, flagship models serve as “capability anchors,” and vendors generally adopt a tiered system of “high-priced flagship + low-priced lightweight models.” Meanwhile, open-weight models and closed-source APIs are in long-term competition, keeping the pricing system in dynamic adjustment.

A rational view, therefore, is this: a price increase is not simply profiteering—it prices stronger capability higher while pushing the price of high-frequency, repetitive parts (cache hits) extremely low. Nominal unit price and actual bill cost are two different things.

2. Understanding Three-Tier Billing: Input, Output, and Cache Hits

2.1 Why Output Is the Most Expensive

The generation stage is autoregressive: each token generated requires a forward computation over the entire sequence, which cannot be processed in parallel in one pass like the input stage. The longer the output, the more cost and latency grow in tandem. In coding scenarios, a large-scale refactor may produce tens of thousands of output tokens, and the output unit price often affects the bill more than the input.

2.2 Why Cache Hits Cost Only “Small Change”

The principle is KV Cache reuse: identical prefixes (system prompts, tool definitions, long documents, conversation history) are cached after the first computation and reused directly in subsequent requests, eliminating repeated prefill computation. As a result, the price can drop from tens of RMB to the single-digit level. For workloads with highly repetitive prefixes—agent loops, long sessions, retrieval-augmented generation—the cache hit rate often determines the bulk of the bill.

2.3 A Reusable Bill Estimator

def estimate_cost(prompt_tokens, completion_tokens, cached_tokens,
                  price_in=20, price_out=100, price_cache=1):
    """Units: RMB per million tokens; price figures are examples only"""
    uncached = max(prompt_tokens - cached_tokens, 0)
    return (uncached / 1e6 * price_in
            + cached_tokens / 1e6 * price_cache
            + completion_tokens / 1e6 * price_out)
# Example: one agent loop, with system prompt + history totaling 140K tokens
# (100K of which hit the cache), and 4K tokens actually output this round
cost = estimate_cost(prompt_tokens=140_000,
                     completion_tokens=4_000,
                     cached_tokens=100_000)
print(round(cost, 2))  # about 1.3 RMB

You can verify: 40K uncached input tokens cost 0.8 RMB, 100K cached tokens cost only 0.1 RMB, and 4K output tokens cost 0.4 RMB. Caching turns what would have been 0.2 RMB into 0.1 RMB—seemingly not much—but once the hit rate rises above 80%, input-side costs can be compressed by an order of magnitude.

2.4 A Nominal Price Increase Does Not Equal a Doubled Bill

When evaluating the cost of an upgrade, focus on the “comprehensive cost of completing a task”: unit price × token volume × retry count. A stronger model usually means less rework, shorter correction loops, and a higher first-pass success rate. Combined with a low cache-hit price, the real bill increase is often far smaller than the nominal unit price increase.

3. Subscription Plans vs. Pay-as-You-Go APIs: Two Ledgers

3.1 Subscriptions: A Fixed Monthly Fee for Quota

A coding subscription plan takes the form of a fixed monthly fee in exchange for monthly quota, which may be denominated in credits or converted to tokens. Its advantages are a predictable budget and suitability for individual developers and teams with steady development rhythms. But before choosing, you must check three things: which model tiers the quota covers, whether context length is subject to tiered limits, and by what rules the quota is deducted (credit systems need to be converted into token terms). In addition, subscription quota is usually usable only within the vendor’s own coding tools and may be subject to fair-use constraints such as short-cycle rate limits, so it is generally not suitable for directly supporting external production services.

3.2 Pay-as-You-Go APIs: Pay for What You Use

The advantages of usage-based billing are elasticity and integrability: it can be integrated into production services, allows fine-grained control of concurrency and budget, and lets you freely choose model tiers. The price is greater bill volatility, which requires usage monitoring and budget alerts.

3.3 A Unified Basis for Comparison: Equivalent Unit Price

To make the two models comparable, you must convert subscription quota into an “equivalent token unit price”:

def equiv_price(monthly_fee, quota_tokens):
    """Convert subscription fee to RMB per million tokens (example)"""
    return monthly_fee / (quota_tokens / 1e6)
# Assume a tier with a monthly fee of 199 RMB and about 20 million
# equivalent output tokens
print(equiv_price(199, 20_000_000))  # about 9.95 RMB per million tokens

If the converted equivalent unit price is significantly lower than the API output unit price, and your usage is stable enough to exhaust the quota, a subscription is more cost-effective. If usage fluctuates widely or you need to integrate into a product, the pay-as-you-go API is more suitable. When converting, be careful to price against the “model tiers and context tiers you will actually use,” or the conclusion will be distorted.

4. A Cost-Optimization Checklist for a Price-Increase Cycle

1. Prioritize prefix caching: Put stable system prompts, tool definitions, and examples at the very front of the prompt to maximize cache hits.
2. Route by model tier: Assign architecture design and difficult debugging to flagship models, and route routine tasks such as completion, summarization, and classification to lightweight models.
3. Control context: Trim conversation history and summarize tool return results to avoid stuffing an entire repository into the context.
4. Limit maximum output: Set a reasonable upper bound on output length to prevent agent loops from “running away” and generating invalid bills.
5. Monitor and budget: Major cloud providers generally offer logging, monitoring and alerting, and usage statistics. Tag by project and environment, and set daily/monthly budget thresholds.
6. Stress-test and regress: Use a fixed evaluation set to compare the “task completion cost” of old and new models, and let data decide the migration pace.

5. A Decision Framework for Model Selection

• Is usage stable and predictable? Stable and quota-exhausting → subscription; highly variable → pay-as-you-go API.
• Does it need to be integrated into a customer-facing product? Yes → pay-as-you-go API (requires concurrency capacity and billing granularity).
• Does it rely heavily on long context and agent loops? Yes → prioritize examining cache-hit pricing and your own hit rate.
• Budget governance requirements? Individuals/small teams → subscriptions offer controllability; enterprises → pay-as-you-go API plus budget alerts and cost allocation.

Conclusion

A pricing-structure adjustment is essentially a signal that the industry is moving from “low prices for scale” toward “pricing by capability and cost.” For developers, rather than agonizing over how many times the unit price has risen, it is better to nail down three things: calculate the equivalent unit price, make full use of prefix caching, and build solid model routing and budget mechanisms. Prices are set by the market, but costs are saved through engineering—that is the most professional response to a price-increase cycle.