LLM API Price Hikes: Moving Beyond Unit Pricing to True Cost Accounting

Recently, a newly released flagship LLM’s API pricing increased several-fold compared with its predecessor. According to widely circulated figures, output pricing reached roughly 100 RMB per million tokens, input around 20 RMB, and cache hits about 1 RMB. The developer community immediately split into two camps: one argued that “better capabilities justify higher prices,” while the other ran the numbers and pointed out that the subscription plan’s cost-effectiveness lags noticeably behind international peers. Emotional arguments have limited value. What actually matters is building a quantifiable, reproducible cost accounting framework. This article abstracts the debate into a general analytical methodology for model selection and budget planning.

1. Reading the Pricing Table: The Three-Part Structure of Input, Output, and Cache

Modern LLM API pricing typically consists of three unit prices:

• Input price: The cost of processing the prompt, including system prompts, context, and tool call results.
• Output price: The cost of generated tokens, usually several times the input price because autoregressive generation is the most compute-intensive stage.
• Cache hit price: When the prompt prefix matches a recent request and hits the server-side cache, billing drops sharply, often to one-tenth of the input price or lower.

Three key observations follow:

1. Output price is the primary cost driver. In coding, long-form writing, and similar scenarios, output tokens often account for more than 60% of total cost. When evaluating a price increase, focus first on changes in output pricing rather than anchoring on the cheaper input rate.
2. Cache pricing is a hidden cost-reduction lever. In the pricing example above, the cache hit rate is about 5% of the input price. For agent workflows carrying long system prompts and large reference materials, the cache hit rate directly determines the overall cost magnitude.
3. Unit price does not equal total cost. Total cost = sum(input volume × input price) + sum(output volume × output price) + sum(cache hit volume × cache price). Of the three variables, the first two are determined by the task, while the third is determined by engineering decisions. All three are controllable.

2. Two Coordinates for “Is It Expensive?”: Cost-Effectiveness and Task Cost

2.1 Performance-to-Price Ratio

Price alone cannot answer whether a model is expensive; the capability dimension must be introduced. The core argument from supporters of the price increase is that the new model ranks among the global top tier in several authoritative benchmarks, matching leading capabilities at a lower unit price. The price per unit of capability is therefore favorable, falling within a “reasonable capability premium.” This logic is methodologically sound. A common industry practice is to plot benchmark scores on the x-axis and unit prices on the y-axis as a “cost-effectiveness scatter plot.” Only models falling in the lower-right region of the curve can be considered genuinely cost-effective. Conversely, if capabilities have not significantly improved while prices double, the move is purely a commercial decision, and users will naturally vote with their feet.

2.2 Task-Level Cost: A More Realistic Metric

A more accurate metric than “price per million tokens” is the cost to complete a single task. The reason: different models require different numbers of tokens to complete a task. Weaker models often need more conversation turns, longer reasoning chains, and more retries. The estimation formula is:

Task cost ≈ Number of turns × (Input tokens × Input price + Output tokens × Output price)

Note that input tokens accumulate across turns (context grows roughly linearly in multi-turn conversations), leading to two implications. First, a capable but expensive model may not be more expensive than a cheaper model that requires repeated debugging, if the former solves the problem in a single turn. Second, in agent-style workflows, input costs account for a far larger share than intuition suggests, which amplifies the importance of cache hit pricing. Community measurements support this: independent evaluations show that some new models’ average token consumption per task is approaching that of international flagship models, meaning that price gaps need to be re-examined under the task-cost lens.

3. The Key Variable in Subscriptions: Usage Multiple

Perhaps the most insightful perspective in this debate is the “usage multiple” of subscription plans — the ratio of the actual usage value included in a plan to its subscription fee. Consider a set of community-calculated comparisons:

• An international vendor’s entry-level subscription costs about $20/month and includes roughly $400–$800 worth of API usage, a multiple of about 20–40×.
• Its premium subscription costs about $200/month and corresponds to nearly $10,000 in usage, a multiple of over 50×.
• The domestic model subscription under discussion costs about 199 RMB/month, covering usage worth roughly 1,000 RMB, a multiple of only about 6–14×.

Why does the usage multiple matter so much?

1. The cost floor for heavy users is determined by subscriptions. In heavy-usage scenarios such as coding assistants, automation agents, and batch data processing, pay-as-you-go pricing will almost inevitably blow through budgets. Subscriptions are the only viable business model.
2. A high multiple reflects a vendor’s “margin for scale” strategy. It signals confidence in inference cost efficiency (high cache reuse, mature inference optimization) and a strategic intent to capture the developer ecosystem.
3. A low multiple makes subscriptions practically meaningless. If the multiple is in the single digits, heavy users will exhaust their quota and be switched back to expensive pay-as-you-go pricing, causing a cliff-like degradation in experience.

From a product perspective, the community’s expectation — entry-level plans offering tens of times the usage value and premium plans offering a hundred times — is not unreasonable. It simply aligns with established commercial practices from leading international vendors. For vendors, the ability to offer high-multiple plans fundamentally tests their overall efficiency in inference cost, cache architecture, and resource scheduling, not merely their pricing courage.

4. A Developer’s Cost Accounting Methodology

4.1 Build a Task-Level Cost Ledger

# Task-level cost accounting example (unit: yuan per million tokens)
PRICE = {"input": 20.0, "output": 100.0, "cache_hit": 1.0}
def task_cost(input_tokens, output_tokens, cache_hit_rate=0.0):
    cached = input_tokens * cache_hit_rate
    fresh  = input_tokens * (1 - cache_hit_rate)
    return (fresh * PRICE["input"]
            + cached * PRICE["cache_hit"]
            + output_tokens * PRICE["output"]) / 1_000_000
# Typical agent task: 80,000 input tokens, 5,000 output tokens
print(f"{task_cost(80_000, 5_000, 0.7):.2f} yuan")  # 70% cache hit: ~1.04 yuan
print(f"{task_cost(80_000, 5_000, 0.0):.2f} yuan")  # No cache hit: ~2.10 yuan

For the same task, a 70% cache hit rate nearly halves the cost compared with 0%, with input-side expenses dropping about 65%. In multi-turn workflows, this gap widens further with each additional turn.

4.2 Three Accounting Perspectives Are All Necessary

• Per-token cost: For horizontal comparison across model pricing tables.
• Per-task cost: Use the “average cost per 100 tasks” as the statistical unit to smooth out long-tail fluctuations and evaluate the real cost of a specific workflow.
• Per-subscription-cycle cost: Convert monthly task volume into quota consumption to determine whether you are hitting subscription limits, which informs plan tier selection or switching billing modes.

Only by combining all three can you rigorously answer whether switching models or plans is worthwhile.

4.3 Model Selection Checklist

• Assuming capability requirements are met, compare task costs first rather than per-token prices.
• Calculate the ratio of monthly usage to subscription quota. A ratio approaching or exceeding 1 means it is time to upgrade plans or switch to pay-as-you-go.
• Confirm cache mechanism details: whether it is enabled by default, the granularity of prefix matching, and any minimum prefix length requirements.
• Beware the “cheap but weak” trap: the retry and rework costs of cheaper models are often severely underestimated.

5. Cost-Reduction Practices: Softening the Blow of Price Hikes

1. Use caching effectively. Place stable content such as system prompts, tool definitions, and reference materials at the beginning of the prompt, with dynamic content appended afterward. Maximizing prefix hit rates requires almost zero engineering overhead.
2. Route across model tiers. Assign simple tasks like classification, extraction, and format conversion to lightweight models, reserving flagship models for complex reasoning. This can significantly reduce average task costs, typically paying for itself within weeks.
3. Control output length. Use structured output constraints and chain-of-thought trimming to reduce expensive output tokens.
4. Govern context. Prune conversation history in a timely manner and compress intermediate results into summaries to prevent input costs from growing linearly with turns.
5. Leverage batch and off-peak discounts. If the vendor offers batch inference APIs or off-peak discounts, these can further reduce unit costs.

6. Industry Perspective: How to Read This Round of Price Hikes

From an industry standpoint, this pricing adjustment sends two signals. First, LLM pricing is shifting from “customer acquisition” to “value-based” — when model capability becomes the answer to productivity bottlenecks, vendors begin pricing by value rather than cost. Second, the dual-track system of subscriptions and pay-as-you-go will coexist for the long term: pay-as-you-go serves long-tail and integration scenarios, while subscriptions serve heavy developers. The key competitive battleground going forward is not unit price but the usage multiple and quota ceiling of subscription plans, which directly determine heavy users’ willingness to migrate. For domestic vendors, the real demand behind this debate is clear: after flagship capabilities reach parity, the next contest is about “who will backstop heavy users.” Whoever first offers high-multiple, high-quota subscription plans will convert capability advantages into ecosystem advantages.

Conclusion

A unit price increase is not frightening in itself. What is frightening is making decisions based solely on unit price. The rational path is to understand the three-part pricing structure, replace per-token prices with task costs, incorporate subscription usage multiples into the selection formula, and proactively compress costs through caching and routing. Model prices are exogenous, but usage structure is endogenous. Get the math right, and you can keep your budget stable even amid rising prices.