LLM Inference Pricing Explained: Price Tiers, Unit Task Cost, and Subscription Plan Value

Why a Reasoning Model Price Increase Isn’t a Simple Price Hike

In the latest round of LLM inference API price adjustments, output prices rose noticeably over the previous generation, input prices climbed as well, and cache-hit pricing stayed relatively low. This is easy to read as a simple “price hike,” but from an engineering perspective it looks more like a repricing that follows a shift in the model’s capability positioning.

Traditional chat models are typically optimized for low latency and high concurrency, with short inference paths and controllable per-task consumption. Newer strong reasoning models introduce longer chains of thought, self-checking, multi-step verification, and backtracking search to achieve higher accuracy on math, code, and complex logic tasks. The direct consequence is a sharp increase in the number of tokens generated per request, especially on the output side. The price increase largely reflects higher underlying compute consumption rather than a purely commercial markup.

If you compare only headline prices, you may conclude that a model is “five times more expensive.” But if you compare cost per task, the conclusion can be completely different. For example, an older model might output an average of 2,000 tokens to complete a code debugging task, while a new model might need 8,000 tokens for the same task. Even a modest per-token price increase would then be amplified at the task level. Conversely, if the new model’s higher first-pass success rate eliminates retries, the actual cost may go down.

So evaluating whether a price adjustment is reasonable requires adding a “per-task consumption” dimension. The formula can be simplified as:

Per-task cost = input tokens × input unit price
             + output tokens × output unit price
             + cache-miss tokens × cache-miss unit price

Looking only at unit prices while ignoring token distribution is the main source of misjudgment.

How Input, Output, and Cache-Hit Pricing Differ

Inference API pricing is usually split into three tiers: input price, output price, and cache-hit price. Each has a different cost basis, and their adjustment magnitudes often differ.

The input price corresponds to compute in the prefill stage. The model must read the entire context at once and compute attention matrices. Longer inputs mean higher time-to-first-token and greater memory usage. For long-document analysis, codebase comprehension, and multi-turn conversation replay, input cost is far from negligible.

The output price corresponds to the token-by-token decoding stage. Generating each token requires a KV cache access plus a forward pass. Strong reasoning models often multiply output volume, so output prices are typically far higher than input prices — one reason output saw the largest increase in this round of adjustments.

The cache-hit price is an easily underestimated metric. In multi-turn conversations or shared-system-prompt scenarios, tokens with identical prefixes can reuse previously computed KV caches, eliminating redundant prefill. Cache-hit prices are therefore often only a tiny fraction of input prices — for instance, if the input price is ¥20 per million tokens, the cache-hit price might be as low as ¥1 per million tokens.

Used well, caching can dramatically reduce the cost of long-conversation applications. When designing an application, placing stable content first — system instructions, tool descriptions, few-shot examples — and variable content last improves the cache-hit rate. Conversely, if every request puts a timestamp or random value at the front, the cache will almost never hit and costs multiply.

Here is a prompt layout that favors cache hits:

[System instructions: fixed]
[Tool descriptions: fixed]
[Few-shot examples: fixed]
[User context: variable]
[Current question: variable]

Putting the “current question” or “current time” at the beginning breaks prefix consistency. For high-frequency call scenarios, raising the cache-hit rate from 10% to 70% can cut costs by more than half.

Subscription Quotas Are the Real Price

Many developers overlook one point: headline prices are “retail prices,” while the effective quota inside a subscription plan is the real cost of usage.

Mainstream international inference services typically use subscription models — for example, tens of dollars per month in exchange for quota worth hundreds or even thousands of dollars at pay-as-you-go rates. The amplification multiplier can exceed 20x. In other words, subscribers effectively pay only a small fraction of list price.

Some other providers also offer subscription plans, but with multipliers of only a few times up to roughly ten times. This creates a counterintuitive effect: per-token prices may look cheaper on the surface, yet after factoring in the plan multiplier, the real usable quota is smaller.

Suppose there are two providers:

Provider A:
Output price: ¥100 per million tokens
Monthly plan: ¥199, with ¥2,000 of usable quota
Amplification: about 10x
Provider B:
Output price: ¥400 per million tokens
Monthly plan: ¥200, with ¥8,000 of usable quota
Amplification: about 40x

Judging by unit price alone, A looks cheaper. Judging by real usable quota, B’s actual cost may be only a quarter of A’s.

This is why any discussion of “expensive or not” must first agree on the comparison basis. For light users who never exhaust a plan, headline prices matter more; for heavy users, the plan multiplier is the deciding factor.

Another common mistake is comparing “price per million tokens” while ignoring how many tokens different models need to finish a task. Take a model with an output price of ¥100 per million tokens that consumes an average of 20,000 tokens per task, versus a model priced at ¥400 per million tokens that consumes 3,000 tokens per task:

Model 1: 100 × 0.02 = ¥2 per task
Model 2: 400 × 0.003 = ¥1.2 per task

The model that looks four times more expensive is actually cheaper per task. Comparing unit prices alone is meaningless; you need an end-to-end evaluation that combines task quality with token consumption.

How to Judge Whether a Plan Delivers Productivity Value

For developers and enterprise users, deciding whether a model service is worth using long term should not rest on marketing claims about “global rankings” or per-token price comparisons. Instead, build a quantitative evaluation framework for your own scenarios.

First, build a task sample set. Select 50 to 200 real tasks covering the most common types in your daily usage — code generation, document summarization, multi-turn tool calling, data extraction, and so on. Keep the set stable so you can compare results repeatedly over time.

Second, record each task’s average input tokens, output tokens, cache-hit tokens, and success rate. Pay special attention to the output token distribution, because strong reasoning models may produce several times more output than standard models on certain tasks.

Third, calculate end-to-end cost using the formula above, adding retry costs. If a cheap model has a low success rate and needs three attempts to complete a task, its real cost is tripled. Conversely, an expensive model that passes on the first try may still have a lower total cost despite its higher unit price.

Fourth, evaluate how well the plan multiplier matches your usage. If you consistently consume ¥3,000 of quota per month, a ¥199 plan offering ¥2,000 of quota forces pay-as-you-go top-ups, while a ¥299 plan offering ¥10,000 of quota costs only ¥100 more but can yield far lower total spending.

Fifth, measure how caching strategy affects cost. Within your own application architecture, simulate strategies such as system prompt reuse, conversation history replay, and fixed few-shot examples, and test the cache-hit rate under each. For long-conversation applications, every 10-percentage-point improvement in the cache-hit rate can translate into significant savings.

Take a customer service system as an example. Suppose each request carries 8,000 input tokens, of which about 6,000 — system instructions and knowledge base content — are fixed. Without prompt ordering optimization, the cache-hit rate is only 5%; after moving system instructions to the front, it rises to 70%. At an input price of ¥20 per million tokens and a cache-hit price of ¥1 per million tokens:

Per-turn input cost before optimization:
8000 × 20 / 1000000 = ¥0.16
Per-turn input cost after optimization:
6000 × 1 / 1000000 + 2000 × 20 / 1000000
= 0.006 + 0.04
= ¥0.046

Per-turn cost drops by about 71%. For a system handling 100,000 turns per day, that means more than ¥10,000 saved daily — far outweighing the impact of a unit price increase.

The Product Logic Behind High Reasoning Model Prices

From a business perspective, raising output prices for strong reasoning models also serves to filter use cases. If output prices were too low, large volumes of unnecessary high-consumption work would flood in — repeatedly generating verbose explanations, running continuous low-value reasoning — wasting resources. A moderately higher output price nudges developers to optimize prompts, caching strategies, and task design, steering compute toward scenarios that genuinely need deep reasoning.

A high-price strategy is sustainable, however, only if the model’s success rate on complex tasks is genuinely and significantly higher than that of cheaper alternatives. Otherwise, the price increase simply pushes developers toward cheaper standard models used on demand, or toward hybrid routing strategies.

A common enterprise architecture looks like this:

Simple tasks → lightweight model
Complex reasoning → strong reasoning model
Long-document parsing → long-context model

By routing tasks appropriately and reserving the strong reasoning model for steps that truly require high accuracy, overall cost stays under control. A strong reasoning model has productivity value only when its success-rate improvement covers its price premium — not merely when it “scores well on benchmarks.”

So rather than rushing to judge whether this round of reasoning model price increases is reasonable, focus on three questions: Do plan quotas match the needs of heavy users? Are cache hits easy to achieve? Is real per-task cost under control? If all three hold, even doubled prices can be worth paying. If only list prices rise while plan quotas stay unchanged, the real burden on high-frequency users has genuinely increased.