LLM API Cost Calculation: Unit Price, Cache Hit, and Subscription Leverage

Introduction: Why the Price Debate Goes Nowhere

A recent pricing update for a Chinese LLM’s next-generation model sparked heated discussion: output price jumped several-fold from the previous version, reaching roughly 100 yuan per million tokens, with input at around 20 yuan and cache-hit pricing at about 1 yuan. One camp argues that the model’s public benchmark scores justify a premium aligned with top-tier international offerings. Another camp did the math and concluded that the real cost is actually higher than expected.

Who is right? The question itself is flawed. Whether a model is “expensive” is not a static conclusion determined by the list price. It is a dynamic calculation shaped by the pricing structure, per-task token consumption, and subscription packaging. This article offers a reusable evaluation framework.

1. Understanding the Three-Tier Pricing Structure

Modern LLM APIs typically split billing into three price tiers. Understanding why they exist is the first step in cost estimation.

1.1 Why Output Prices Are Far Higher Than Input Prices

Inference happens in two phases. During the prefill phase, the entire input can be processed in parallel, which means high compute density and lower unit cost. During the decoding phase, tokens must be generated sequentially, with continuous reads and writes to the KV cache, making batch processing naturally less efficient. As a result, output unit prices that are 3–5 times input prices are an industry norm. An input price of 20 yuan and output price of 100 yuan (a 5x ratio) is not unusual. Judging a model as “expensive” based solely on the output price ignores the fact that this ratio is standard across the industry.

1.2 Cache-Hit Pricing: The Most Underestimated Cost Lever

Prompt caching works by reusing the KV cache for request prefixes that repeat across calls (system prompts, few-shot examples, fixed document contexts). Providers typically charge an extremely low price for cache hits. In the pricing example above, cache-hit tokens cost only one-twentieth of the regular input price. This is essentially an incentive to adopt an engineering pattern: keep stable content at the front, put variable content at the end. Practical implications include:

• Place system prompts, tool definitions, and reference documents at the very beginning of the prompt and keep them stable.
• In multi-turn conversations, append only new information instead of rewriting the entire context each turn.
• In high-frequency fixed scenarios (customer support scripts, knowledge-base Q&A), maximize prefix reuse.

1.3 Align Measurement Standards Before Comparing Prices

Different providers may use different billing conventions: whether reasoning tokens count toward output billing, whether cache hits are billed separately, how rate limits and overage charges work. Without aligning these definitions, any direct unit price comparison will be misleading.

2. The Limits of Unit Price Comparison: Per-Task Consumption Is the Hidden Variable

A low price per million tokens does not guarantee a low cost per thousand tasks. Different models may consume vastly different token counts to complete the same task. The differences come from:

• Reasoning chain length: reasoning-enhanced models generate many internal reasoning tokens. On complex tasks, this buys accuracy but also drives up output consumption.
• Output style: a concise model may finish a task in 300 tokens, while a verbose model may take 800.
• Context management strategy: some models repeatedly send the full conversation history, causing input consumption to grow linearly with turns.

Third-party agent benchmark results show that some next-generation models now have average per-task token consumption close to top international models. This means the traditional route of “offsetting high unit prices with low consumption” is no longer reliable. The product of unit price and consumption — task cost — is the metric that actually matters. The script below unifies price and consumption into a single calculation:

from dataclasses import dataclass
@dataclass
class PricingProfile:
    """Price per million tokens (yuan)"""
    input_price: float
    output_price: float
    cache_hit_price: float
@dataclass
class TaskProfile:
    """Average token consumption per task, derived from benchmark statistics"""
    avg_input_tokens: int
    avg_output_tokens: int
    cache_hit_ratio: float = 0.0  # Share of input tokens that hit the prefix cache
def cost_per_task(task: TaskProfile, p: PricingProfile) -> float:
    cached = task.avg_input_tokens * task.cache_hit_ratio
    fresh = task.avg_input_tokens - cached
    return (fresh * p.input_price
            + cached * p.cache_hit_price
            + task.avg_output_tokens * p.output_price) / 1_000_000
# Example (yuan per million tokens): input 20, output 100, cache hit 1
pricing = PricingProfile(20.0, 100.0, 1.0)
# Scenario A: 8k input, 2k output, no cache reuse
task_a = TaskProfile(8_000, 2_000)
# Scenario B: 20k input, 2k output, 80% stable prefix
task_b = TaskProfile(20_000, 2_000, cache_hit_ratio=0.8)
print(cost_per_task(task_a, pricing))  # ≈ 0.36 yuan/task
print(cost_per_task(task_b, pricing))  # ≈ 0.30 yuan/task

Note the result: Scenario B has 2.5 times the input of Scenario A, yet it costs less per task because of cache hits. This suggests shifting the focus of cost optimization from “lower unit prices” to “designing cache-friendly task structures.”

3. Subscription Leverage: The Effective Unit Price Is the Real Cost

For high-volume users, the list price is rarely the actual cost. The effective unit price after subscription packaging is what matters. The industry is clearly split:

• Some international providers offer subscription plans with extremely high leverage (usable credit / monthly fee). Developers have reported entry-tier leverage above 20x, with higher tiers reaching the 50x range.
• Some domestic providers currently offer leverage mostly in the single digits to low teens. For example, a 199 yuan plan may correspond to roughly 1,200–2,800 yuan in nominal usage, implying leverage of about 6–14x.

Major cloud platforms (such as Baidu AI Cloud) typically offer both pay-as-you-go and subscription-based billing. Both models should be included in any cost evaluation. The math behind leverage is straightforward:

Effective cost discount = 1 / leverage. At 20x leverage, every 1 yuan of nominal usage costs only 0.05 yuan when the credit is fully used. Consider this illustrative comparison:

Plan	Nominal Cost Index	Subscription Leverage	Effective Cost Index at Full Usage
Plan A	1.0	8x	≈ 0.125
Plan B	1.5	25x	≈ 0.06

Even though Plan B has a list price 50% higher than Plan A, its effective cost is less than half. This is the mathematical root of the “high list price, actually cheap” phenomenon — and the core benefit that mature subscription systems reserve for heavy users. Conversely, if a model already has a high list price and only single-digit subscription leverage, high-frequency teams will see their total costs significantly amplified.

4. What Makes a Pricing System “Product-Competent”

Bringing the analysis together, the comprehensive cost of a model service can be approximated as:

Comprehensive cost ≈ nominal unit price × per-task consumption ÷ subscription leverage

This leads to four straightforward conclusions:

1. Capability premiums need verifiable benchmark support. Pricing aligned with top-tier offerings is fine, provided that public benchmarks, agent task success rates, and coding benchmarks actually match — and per-task consumption has not spiraled out of control.
2. High-volume users only care about effective unit price. Raising leverage from 8x to 25x cuts costs to roughly one-third. Subscription substance matters far more for reputation than list-price posturing.
3. A credible subscription plan looks roughly like this (illustrative): entry tier at 99 yuan with 2,000–5,000 yuan in nominal credit (20–50x leverage); a higher tier at 699 yuan with tens of thousands of yuan in nominal credit (70x+ leverage). Only structures like this can seriously compete with leading products.
4. Transparency is a hidden product feature. Credit calculation rules, whether reasoning tokens count toward billing, rate limit thresholds, and overage billing methods should all be clearly documented — vague definitions invalidate any cost calculation.

5. A Practical Checklist for Enterprise Model Selection

• Step 1: Build a business benchmark set. Sample 100–500 representative tasks from real workloads, covering simple and hard cases, short and long contexts, single-turn and multi-turn conversations. Do not rely solely on public leaderboards.
• Step 2: Measure the consumption distribution. Record actual input and output (including reasoning) token counts for each task, then calculate P50 and P95. Averages get skewed by long-tail tasks; use P95 for capacity planning.
• Step 3: Estimate the upper bound of cache hit ratio. The higher the share of stable prefixes, the larger the caching benefit. Stable system prompts plus tool definitions often cover the bulk of input tokens.
• Step 4: Unify the calculation script. Put each candidate’s pricing and subscription parameters into the same script, output “cost per thousand tasks” and a monthly budget ceiling, then compare side by side.
• Step 5: Account for hidden costs. Failure retry rates, rate-limit queueing delays, and context bloat in multi-turn conversations all inflate bills over time. Observe them during load testing.
• Step 6: Route by task tier. Send simple tasks to a low-cost smaller model and reserve high-capability models for complex tasks. This often compresses costs significantly without sacrificing experience, though actual gains should be validated with real measurements.

Conclusion

Back to the original question: is 100 yuan per million output tokens expensive? Viewed statically, it may not be unreasonable given the model’s benchmark positioning. Viewed dynamically, the answer depends on three variables that belong to you: your task consumption distribution, your cache hit ratio, and the leverage of the subscription plan you can access. Rather than debating “expensive or not” in the community, spend half a day running the calculation script above on your own business benchmark set. Cost is never just a price tag — it is an engineering problem you need to calculate with your own hands.