Deep Dive into LLM Pricing: Unit Price, Prompt Caching, and Subscription Tiers

I. Background: The Debate Over “Is It Too Expensive?”

Recently, a newly released flagship large language model (LLM) increased its output price to roughly five times that of its predecessor, with input and cache-hit prices rising simultaneously. The community immediately engaged in a heated debate over whether this pricing is justified. Supporters argue that the model’s capabilities have leaped forward and its benchmark rankings are high, making the premium reasonable. Critics counter with comparisons to previous generations and competitors, arguing that the price-to-performance ratio has significantly regressed.

Both perspectives only capture a slice of the reality. Looking solely at the unit price per million tokens, or a single benchmark leaderboard, is insufficient to answer whether it is “too expensive.” The real question to ask is: For your specific business workload, what is the total cost to complete a unit task? Furthermore, with the same budget, how much actual usage can you get under different vendors’ subscription systems?

This article attempts to transform this emotional debate into a mathematical problem that can be precisely solved.

II. Understanding the Billing Structure: Why Input, Output, and Caching Vary Significantly

1. Output is More Expensive Than Input Due to Architecture

LLM inference is divided into two phases: prefill (processing the input) and decode (generating the output). The prefill phase allows for parallel computation, resulting in high GPU utilization. The decode phase is autoregressive; generating each token requires reading the continuously growing KV cache completely. This is a classic memory-bound scenario with low compute yield per unit of power. Therefore, the output unit price is typically several times that of the input. This is not arbitrary pricing but a reflection of the cost structure.

2. Cache Hit Prices are Low Because Repeated Computation is Saved

Prompt Caching allows the server to reuse the already computed KV cache for identical prefixes. Stable content such as system prompts, long documents, and few-shot examples can hit the cache across multiple calls, skipping the repeated prefill computation. As a result, the price for the cached portion is often just a fraction of the original price. For developers, this means how you structure your prompts directly impacts your bill: a structure with a stable prefix and dynamic suffix is naturally more cost-effective.

3. Don’t Ignore the “Hidden Tokens” of Reasoning Models

A new generation of models focused on deep reasoning generates a large number of thinking process tokens before providing the final answer, and these tokens are billed as well. A single call that appears to output only a few hundred tokens might actually consume thousands or even tens of thousands of tokens. The more a model “loves to think,” the greater the weight of the output unit price in the total cost—which is why output-side price hikes are felt more acutely by heavy users.

III. Turning Pricing into a Formula: Cost Estimation is Calculable

The cost of a single API call can be written as:

Per-call cost = (Input tokens × Input unit price + Cached tokens × Cache unit price + Output tokens × Output unit price) / 10⁶

Where unit prices are calculated as “Currency / Million tokens.” Based on this, we can write a simple estimation script:

def monthly_cost(calls_per_day, input_tk, cached_tk, output_tk,
                 p_in, p_cache, p_out):
    """p_* are unit prices, in: Currency/Million tokens (values below are illustrative)"""
    per_call = (input_tk * p_in
                + cached_tk * p_cache
                + output_tk * p_out) / 1_000_000
    return per_call * calls_per_day * 30
# Illustrative scenario: An Agent application, 20k input tokens per call (16k hit cache), 4k output
cost = monthly_cost(
    calls_per_day=500,
    input_tk=20_000, cached_tk=16_000, output_tk=4_000,
    p_in=2.0, p_cache=0.2, p_out=8.0,
)
print(f"Monthly cost approx {cost:,.0f}")   # Approx 1,128

From this formula, several key conclusions can be directly drawn:

• Doubling the unit price does not mean doubling the total cost. If the new model has a higher first-time success rate, requires fewer retries and rework, or its stronger instruction adherence allows you to cut out large chunks of few-shot examples, the total cost per unit task might actually decrease.
• Cache hit rate is a leverage point. In the example above, if the cache hit rate drops from 80% to 0%, the monthly cost will rise significantly. Conversely, pushing the hit rate above 90% effectively hedges against input-side price increases.
• Agent scenarios have a cost amplification effect. Multi-turn tool calls mean carrying the system prompt and historical context in every turn. Cache design and context management strategies directly dictate the slope of your billing curve.

IV. Subscription Tiers: The “Hidden Exchange Rate” in Subscriptions

A highly informative observation from community discussions is that API unit pricing is only half the story; the “usage multiplier” of subscription tiers is the key factor determining the actual experienced cost.

Define a simple metric:

Usage multiplier k = Equivalent API usage value provided by the tier / Subscription monthly fee

According to community observations, subscription products from some leading global vendors have long provided equivalent API usage worth dozens of times the subscription fee, effectively granting deep discounts to users via the subscription model. In contrast, multipliers from vendors in other markets are generally an order of magnitude lower. This leads to a counterintuitive conclusion: Even if two vendors have the exact same API unit price, the actual usage cost at the one with the higher multiplier could be just a fraction of the other’s.

Why are vendors willing to offer such margins? The logic is not mysterious:

1. Complementary Load Profiles. Subscription users are typically light-to-medium, tidal users. Vendors can use idle compute capacity to serve them, where the marginal cost is far below the sticker price.
2. Cash Flow and Stickiness. Fixed monthly fees bring predictable revenue while raising the user’s switching costs.
3. Competitive Weapon. When capabilities are comparable, the multiplier is the most intuitive expression of price-to-performance ratio.

The actionable advice for users is straightforward: Take your task profile, calculate the monthly consumption using the API price list, and divide it by the candidate subscription’s monthly fee to get “your true multiplier.” Also, note that subscriptions usually come with rate limits, concurrency caps, and fair use policies. Heavy Agent workloads might hit these ceilings, requiring a fallback to API billing.

V. An Actionable Five-Step Evaluation Framework

1. Profile your tasks. Measure the input/output token distribution, cache hit rate, daily calls, and peak concurrency of typical tasks. This step determines the accuracy of all subsequent estimates.
2. Calculate the API baseline. Use the formula in Section III to estimate monthly API costs as a unified baseline for comparison.
3. Convert subscription multipliers. Translate candidate subscription tiers into “your multiplier” rather than directly citing the vendor’s advertised general multiplier.
4. Adjust for hidden costs. Failed retries, evaluation and regression testing consumption, scheduling overhead from multi-model orchestration, and integration or migration engineering costs typically add a 10% to 30% coefficient to the bill.
5. Calibrate with a small-traffic pilot. Run a gray-box test for a week or two, backfill the estimation model with the actual bill, and then decide whether to scale up. Mainstream cloud vendors’ model service consoles (such as Baidu AI Cloud) generally provide usage statistics and billing details. For self-built infrastructure, you can log the token count of each call via gateway logs to align estimated values with actual ones.

VI. Six Practical Recommendations for Developers and Enterprises

1. Don’t make decisions based on a single benchmark. Leaderboard rankings reflect relative performance on benchmark tests, which may not be relevant to your task distribution. Paying a premium for capabilities you won’t use is the most common waste.
2. Treat cache hit rate as a first-class optimization. Stable prefixes, document partition reuse, and session-level cache design often yield cost-reduction benefits far greater than haggling over price.
3. Establish model routing. Route simple tasks to smaller models or lower-priced tiers, and only route complex tasks to flagship tiers. A hybrid strategy can often compress overall costs by an order of magnitude.
4. Set budgets and alerts. Set token budgets for each application and configure usage alerts to prevent runaway Agents from burning through your bill in endless loops overnight.
5. Pay attention to model lifecycles. While flagships raise prices, previous generation models usually drop in price or move to lower tiers. Cost-sensitive workloads can remain on older versions, waiting for the right price-to-performance window.
6. Compare horizontally using “cost per unit task.” For example, “cost per completed code review” or “cost per processed support ticket.” This is much closer to the real business experience than a per-million-token unit price.

VII. Conclusion

Returning to the original question: Is a model that raises its price five times actually expensive? The answer is: Without a task profile, this question has no answer. Billing structure, caching strategy, task distribution, subscription multipliers, hidden costs—put these variables into a single framework, and the debate over “expensive or not” turns from a shouting match into an applied math problem where everyone can calculate their own answer. Pricing changes are an expression of a vendor’s cost structure and market positioning, but whether it is “worth it” always depends solely on your specific workload.