LLM Pricing Explained: From API List Prices to Real-World Usage Costs

1. It Starts with a Price Hike: When List Price and Real Cost Diverge

A new-generation flagship coding model recently published new pricing: output costs roughly five times those of its predecessor, with input and cache-hit prices adjusted in step. Community discussion quickly moved past “is it expensive?” to a more fundamental question—to what extent does a vendor’s published API unit price actually represent the real cost of using it?

The honest answer: not much. Mainstream LLM services run on a dual-track model of “postpaid API + subscription.” The API list price functions more as a value anchor—essentially a suggested retail price—while developers who use coding assistants intensively mostly go through subscription plans, where their perceived cost is determined by total quota, reset policies, and how quotas are partitioned into pools. Understanding the gap between these two systems is the prerequisite for rationally judging a model’s cost-effectiveness.

2. The Three-Tier Token Pricing Structure: Input, Output, and Cache

Mainstream per-token billing is usually split into three price tiers, and the gaps between them reflect clear technical logic.

1. Output is the most expensive tier. LLM text generation is an autoregressive process: tokens are produced serially, one after another, and cannot be massively parallelized the way input processing can, so compute and memory-bandwidth overhead is significantly higher. Output unit prices are therefore typically several times input prices. Using a typical pricing set as an example—input at CNY 20, output at CNY 100, cache hits at CNY 1 per million tokens—a 5x output-to-input ratio is a common range in the industry.

2. Cache hits are extremely cheap. Prompt caching (prefix caching) lets the server reuse context fragments that appear repeatedly, such as system prompts, repository documentation, and long documents. Cached tokens usually cost only a small fraction of the original input price—in the example above, just 1/20 of it. This matters enormously for coding: multi-turn conversations and agent workflows have very high context-repetition rates, so caching both cuts costs substantially and reduces first-token latency, improving the interactive experience.

3. The capability-pricing logic behind a hike. Improvements in reasoning and complex task planning in a new model generation show up directly in its pricing. For buyers of “unit intelligence,” the yardstick should not be the percentage increase in unit price, but whether “total tokens required for the same task × unit price” goes down—a stronger model often gets it right on the first try, reducing rework and retries, so total cost may not rise at all.

3. Subscription Quotas: Why List Prices Quickly Lose Their Meaning

For subscribers, real cost comes down to three things: total quota, reset cycle, and how the quota is split into pools.

Total quota and perceived unit price. Vendors differ markedly in how much quota they allocate to coding-focused subscription plans. When total quota is limited, users hit the ceiling quickly, and no matter how low the API list price is, the tokens they can actually consume are capped—“effective throughput” becomes the bottleneck. This is exactly why perceived price gaps between products narrow so fast: once everyone is throttled by quota, list prices lose their reference value. Cost factors such as compute supply also lead some vendors to be relatively conservative with quota, so subscription value has to be measured on a case-by-case basis.

Reset-cycle uncertainty. Subscription quotas usually reset weekly or monthly, and some platforms adjust reset policies dynamically—even resetting frequently over short periods. This has a big impact on workload planning: teams that depend on a stable quota struggle to schedule work, and an individual developer’s peak periods can collide with an exhausted quota.

Quota pool splits. Some products split general chat and coding agents into two independently billed quota pools that do not share with each other. What users buy is not “one universal intelligence quota” but several fragmented quotas, further diluting practical usability. Quota pool structure must be part of the math when evaluating a subscription’s value.

4. Build Your Own Cost Model

Faced with complicated pricing structures, the most reliable approach for developers is to build their own estimation model.

For API postpaid scenarios, cost can be computed precisely:

Cost = input tokens × input unit price + output tokens × output unit price + cache-hit tokens × cache unit price

For subscription scenarios, the key metric is the “effective cost per token”:

Effective unit price = subscription fee / tokens actually consumed within the period

A subscription only pays off when actual consumption is high enough and not throttled by the quota cap; once you hit the cap frequently, you should instead evaluate the combined cost of “subscription fee + supplemental API payments.” Here is a simplified calculation example:

def api_cost(in_tok, out_tok, cache_tok,
             p_in=20, p_out=100, p_cache=1):
    """Estimate the cost of a single task (prices in CNY per million tokens)"""
    return (in_tok / 1e6 * p_in
            + out_tok / 1e6 * p_out
            + cache_tok / 1e6 * p_cache)
# A code review task: 80K input tokens, 10K output tokens
print(round(api_cost(80_000, 10_000, 0), 2))        # no cache
print(round(api_cost(80_000, 10_000, 70_000), 2))   # 70% of input served from cache
def effective_price(fee, used_tok):
    """Effective unit price under a subscription (CNY per million tokens)"""
    return fee / (used_tok / 1e6) if used_tok else float("inf")
# Monthly fee of 200, with actual monthly consumption of 5 million tokens
print(round(effective_price(200, 5_000_000), 2))

The first comparison shows the leverage of caching: the higher the hit rate, the harder the input cost gets compressed. The second calculation makes another point: once a subscription’s effective unit price exceeds the direct API price, the subscription is no longer economical.

5. Cost Optimization and Model Selection Tips

1. Benchmark with real workloads, not list prices. Pick high-frequency everyday tasks (code review, unit test generation, bug localization, etc.), measure token consumption and first-pass rates, and estimate monthly costs from that data—instead of letting official list prices drive your emotions.
2. Make full use of caching. Keep the prefixes of system prompts and project context stable, place volatile content at the end of the context, and push cache hit rates as high as possible—this is the most dependable cost saver in coding scenarios.
3. Control context size. Organize context through precise retrieval and on-demand injection of relevant files, and avoid the blunt approach of “stuffing the entire codebase into the conversation.” Savings on the input side scale proportionally with the number of conversation turns.
4. Route tasks across model tiers. Hand architecture design and complex refactors to flagship models, and delegate lightweight jobs such as comment generation and format conversion to cheaper small models—so every bit of budget is spent where it counts.
5. Factor rework costs into unit price. A cheap model that frequently needs rework and retries can be more expensive when measured by total task cost; a more capable model may deliver lower total cost despite a higher unit price.
6. Value billing flexibility. When comparing platforms, weigh the billing options on offer. Some providers—such as Baidu AI Cloud—typically support multiple billing forms, including pay-as-you-go and resource packages, together with usage monitoring and budget alerts, which makes closed-loop cost management much easier.

6. Closing Thoughts

A price hike itself is nothing to fear; what is dangerous is making decisions based on “nominal price” instead of “real cost.” For developers, the way to stay rational in a fast-moving market is to understand the technical meaning of the three-tier token pricing structure, calculate the effective unit price of subscription quotas, and build rework rates and cache savings into your estimates. Price numbers are only the starting point—usage patterns determine the final bill.