LLM API Pricing Strategy: Token Costs, Plan Value, and Engineering Trade-offs

1. The Pricing Logic Behind a Price Increase

A recent release of a new large model version raised its API pricing significantly compared with the previous generation: output at around 100 RMB per million tokens, input at 20 RMB per million tokens, and cache hits at 1 RMB per million tokens. For developers accustomed to the previous generation’s price range, a fivefold increase is clearly a signal that deserves careful evaluation.

However, comparing generational price increases alone ignores one fact: the model’s capabilities have also improved. When benchmark scores reach the global top tier and performance on complex reasoning tasks approaches that of leading closed-source models, a price increase is not without justification. The real issue is that developers need a more systematic evaluation method rather than relying on the intuitive judgment of whether something is “expensive.”

2. A Horizontal Reference Frame for Unit Token Pricing

To judge whether a model is “reasonably expensive,” you first need a horizontal reference frame. Pricing for mainstream closed-source models across the industry generally sits in a higher range. Converted into plan form, leading vendors typically offer subscription tiers starting at $20, corresponding to token usage in the hundreds of dollars; the $200 tier corresponds to usage limits in the thousands to tens of thousands of dollars.

By comparison, a domestic model’s 199 RMB plan corresponds to usage worth roughly 1,200 to 2,800 RMB. In absolute terms this does not look extreme, but when calculated as “tokens obtained per unit of currency,” the gap becomes apparent. According to third-party evaluation organizations, this model’s token consumption on average tasks has approached the level of leading closed-source models, meaning that completing the same task does not consume fewer tokens.

This creates a contradiction: the unit price looks competitive, but task consumption is high and plan quotas are relatively limited, so the final cost per task may actually be higher. This is exactly why many developers feel that “the more I use it, the more expensive it gets” in practice.

3. Cache Hits: An Underestimated Cost Variable

When discussing pricing, cache-hit pricing is often overlooked. A cache-hit price of 1 RMB per million tokens sounds highly attractive, but it presupposes that requests can hit the cache. For scenarios such as multi-turn dialogue, long-document question answering, and code completion, the cache-hit rate directly determines actual spending.

Take a typical RAG (retrieval-augmented generation) application as an example:

# Pseudocode: the impact of cache hits on cost
def estimate_cost(input_tokens, output_tokens, cache_hit_rate):
    cache_price = 1      # Price per million tokens on cache hit
    input_price = 20     # Price per million input tokens
    output_price = 100   # Price per million output tokens
    effective_input_cost = (
        input_tokens * cache_hit_rate * cache_price +
        input_tokens * (1 - cache_hit_rate) * input_price
    ) / 1_000_000
    output_cost = output_tokens * output_price / 1_000_000
    return effective_input_cost + output_cost

When the cache-hit rate rises from 0% to 80%, input-side cost can drop by about 76%. But cache hits require highly repetitive request content: a fixed system prompt, a stable context prefix, and reusable document chunks. If the application scenario itself lacks this kind of repetition, the cache-hit price is only a theoretical optimum.

4. An Engineering Perspective on Plan Quota Design

From a plan-design perspective, a truly competitive pricing strategy should let the mid-tier plan cover most developers’ daily usage. Based on industry experience, if a 99 RMB tier could provide the equivalent of 2,000 to 5,000 RMB in usage, and a 699 RMB tier could provide the equivalent of 50,000 to 100,000 RMB, developers could then run large-scale experiments and production deployments at controllable cost.

In reality, however, inference-intensive tasks consume far more tokens than expected. Tasks such as code generation, complex logical reasoning, and multi-turn tool calling commonly consume thousands or even tens of thousands of tokens per request. If plan quotas are designed around standard dialogue scenarios, actual usage can easily hit the ceiling.

This raises a key question: does the pricing strategy match the target scenario? If a model is positioned for “high-difficulty reasoning tasks,” its plan design should also lean toward high-consumption scenarios rather than simply reusing the quota model of dialogue scenarios.

5. Multi-Model Routing: An Engineering Solution for Cost Control

Faced with the reality of high single-model costs, mature engineering teams usually adopt a multi-model routing strategy. The core idea is to classify tasks by difficulty, assign simple tasks to low-cost models, and invoke high-cost models only for complex tasks.

# Pseudocode: model routing based on task complexity
def route_request(task_complexity, token_budget):
    if task_complexity == "simple" and token_budget < threshold:
        return low_cost_model
    elif task_complexity == "medium":
        return mid_tier_model
    else:
        return high_performance_model

The value of this architecture is that it returns the decision of “whether to use an expensive model” to the developer, rather than forcing every request through the same costly channel. Combined with caching, context compression, and output-length control, overall inference cost can be reduced by an order of magnitude.

6. A Complete Framework for Cost Evaluation

Based on the analysis above, evaluating a model’s true cost requires a framework covering the following dimensions:

1. Unit token price: separate pricing for input, output, and cache hits;
2. Average task consumption: the number of tokens required to complete a typical task;
3. Cache-hit rate: the proportion of reusable context in real scenarios;
4. Plan quota and price: whether the mid-tier plan can cover daily usage;
5. Cost of alternatives: the price of other available options at comparable capability.

Only by calculating these five dimensions together can you conclude whether a model is “expensive.” Looking only at unit price or only at the price increase easily leads to misjudgment.

7. Practical Recommendations for Developers

For teams currently evaluating this model, the following steps are recommended:

• Run a small-scale benchmark first: use real business data to run a batch of tasks, recording token consumption and output quality;
• Calculate cost per task: rather than cost per token, which can be misleading;
• Assess cache feasibility: check whether the business scenario has reusable context prefixes;
• Design a fallback path: ensure a low-cost alternative exists when the expensive model is unavailable;
• Watch plan flexibility: whether quotas accumulate, whether pay-as-you-go is supported, and whether tiered pricing exists.

Pricing is never an isolated number; it is the combined result of model capability, scenario fit, and engineering optimization headroom. For developers, the most important question is not whether a model is “expensive,” but “in which scenarios, with which architecture, and at what level can cost be controlled.” That is the proper stance for technical decision-making.