Navigating LLM API Price Hikes: A Guide to Calculating Real Token Costs

1. The “Price Hike” Controversy

Recently, a newly released large language model announced its updated API pricing: approximately 20 RMB per million input tokens, 100 RMB per million output tokens, and 1 RMB per million cached tokens—an overall increase of about 5x compared to the previous generation. The community immediately split into two opposing camps regarding whether it is “expensive”:

• The “Not Expensive” Camp: Compared horizontally with leading international flagship models, this unit price sits in the middle or even on the lower end. Furthermore, the model ranks highly on public evaluation leaderboards, making it “expensive for a good reason.”
• The “Very Expensive” Camp: If you convert the quota of subscription plans into equivalent API bills, the “quota multiplier” of leading international models typically exceeds 20x, whereas this new model’s multiplier is significantly lower. Combined with community tests showing its average token consumption per Agent task approaches that of flagship models, the real out-of-pocket cost for heavy users could be several times higher.

Both sides cite “prices” but reach completely opposite conclusions. The issue isn’t intuition; it’s the metric standard: unit price is just one coefficient in the cost formula. The real bill is determined by “unit price × per-task consumption × task volume.” Staring only at the price list will never clarify this account. Let’s break down the math.

2. Decoding the Price List: Technical Drivers Behind Three Unit Prices

The three numbers on the price list aren’t arbitrary; they reflect the actual cost structure of inference services:

1. Input Tokens (Prefill Phase): The model performs a parallel forward pass on the entire context. The computational volume scales nearly linearly with sequence length, and the unit cost is the lowest, hence the lowest unit price.
2. Output Tokens (Decoding Phase): Autoregressive generation must proceed token by token. Generating each token requires carrying the entire KV cache for another forward pass. This phase is constrained by memory bandwidth and is the throughput bottleneck. The industry standard sets the output unit price at 3x to 10x the input price, so a 5x ratio (input 20, output 100) isn’t inherently abnormal. What truly matters is the overall upward shift in absolute values—the cost for the exact same conversation has directly become about 5x that of the previous generation.
3. Cache Hits: For recurring long prefixes (system prompts, reference documents, multi-turn history), the inference service can reuse the KV cache. Hit portions only incur minimal storage and scheduling fees, which is the basis for the 1 RMB-tier pricing. This has direct architectural implications: placing stable content at the beginning of the context is the primary method to reduce long-context task costs.

3. Beyond Unit Price: Task-Level Consumption is the Biggest Variable

Per-task cost can be formulated as:

Task Cost = Σ per turn( New Input Tokens × Input Unit Price
              + Cached Tokens × Cache Unit Price
              + Output Tokens × Output Unit Price )

Every variable in this formula fluctuates drastically based on the task type:

• Simple Q&A: Hundreds of tokens for both input and output; cost is negligible.
• Long Document Analysis: Starts with tens of thousands of input tokens; a stable prefix maximizes cache discounts, while per-turn context changes render caching useless.
• Deep Reasoning Mode: The model first generates a long reasoning chain before delivering the conclusion. The output volume might be multiples of the visible answer, and the output unit price is precisely the most expensive tier.
• Agent / Multi-turn Tool Calling: Each round returns tool execution results, expanding both input and output simultaneously. Per-task consumption can reach tens of times that of a normal conversation.

This explains the contradiction in the first section: even if Model A’s unit price is lower than Model B’s, if A’s consumption volume (especially output) is significantly higher for the same task, its per-task cost will actually be more expensive. Therefore, the correct approach for cross-model price comparison is “task alignment”—measuring actual consumption on identical task sets rather than directly comparing numbers on a price list.

4. Subscription Plan “Multipliers”: Calculating Real Out-of-Pocket Cost

To evaluate subscription plans, introduce an intuitive metric:

Quota Multiplier = Equivalent API Bill of Plan Quota ÷ Plan Price

Using circulated community data as an example: leading international models’ monthly subscriptions (equivalent to the lower-hundreds RMB tier) generally yield an equivalent API bill of 20x or more the selling price. A new model’s equivalent tier, however, yields a multiplier of about 6x to 14x. A 3x difference in the multiplier means heavy users running identical workloads might see a monthly cost difference of an order of magnitude. Some argue that: truly competitive pricing means bringing the out-of-pocket cost for heavy users to the same order of magnitude as leading solutions, rather than just looking “good” on a price list.

However, the multiplier isn’t everything. Three correction factors must be applied:

1. Usage Density: Estimate your monthly consumption converted to an API bill. If it’s lower than the plan’s price, buying a subscription is a loss; multiplier dividends only benefit heavy, consistent users.
2. Rate Limits and Concurrency: Subscriptions typically come with rate limits. Automated pipeline scenarios might result in “cheap on paper, slow to deliver.” Rate limits must be converted into time costs.
3. Quality Correction: See the next section.

5. Bringing Benchmarks into the Equation: Cost per Unit of Intelligence

“High ranking on the leaderboard, therefore expensive for a good reason”—this statement is only half right. Leaderboards answer worthiness (is the capability sufficient), not expensiveness (is the cost to meet the standard low enough). A more rigorous metric is:

Cost per Unit of Intelligence = Total Spend ÷ Number of Qualified Tasks

Note the denominator is “number of qualified tasks,” not “total tasks.” A stronger model might pass on the first try, while a cheaper model might require multiple retries or even carry hidden errors into rework processes, resulting in higher implicit costs. Therefore, a complete evaluation is always two steps:

• Step 1: Test the pass rate on your own test set; eliminate models that don’t meet the standard.
• Step 2: Compare per-task costs among qualified models.

Skipping step 1 and comparing prices directly misjudges “cheap but unusable” as high cost-performance. Skipping step 2 and looking only at benchmark scores might lead to paying a premium for capabilities you don’t need.

6. Enterprise Implementation: An Executable Evaluation and Cost-Reduction Workflow

1. Build a Business Benchmark Set: Extract 50 to 200 tasks with standard answers from real business operations, covering typical scenarios and extreme length distributions to form an internal evaluation set.
2. Dual-Metric Recording: For each candidate model, simultaneously record “whether it meets the standard” and “actual token consumption” to obtain quality and cost distributions, rather than a single score.
3. Cost Attribution and Monitoring: Tag each API call with application, tenant, and feature labels. Leverage general logging and monitoring/alerting capabilities commonly provided by cloud platforms (such as corresponding product categories on Baidu AI Cloud) to complete usage collection, dimension-based aggregation, and budget alerts, ensuring every cent is traceable to a specific feature.
4. Engineering Consumption Reduction: Place stable prefixes at the top to maximize cache discounts, trim irrelevant context, control output length, use structured outputs to constrain redundant text, and apply application-level caching for reusable results.
5. Hybrid Routing: Route based on task difficulty—direct simple tasks like extraction and classification to low-cost smaller models, and complex reasoning to flagship models. This can significantly dilute overall costs.

Accompanying minimal cost estimation script:

PRICING = {                    # RMB / token
    "input":  20 / 1e6,        # New input
    "output": 100 / 1e6,       # Output
    "cached": 1 / 1e6,         # Cache hit input
}
def task_cost(input_tokens: int, output_tokens: int,
              cache_hit_ratio: float = 0.0) -> float:
    """Cost per call (RMB); sum for each turn in multi-turn tasks"""
    cached = input_tokens * cache_hit_ratio
    return (input_tokens - cached) * PRICING["input"] \
         + cached * PRICING["cached"] \
         + output_tokens * PRICING["output"]
def plan_multiplier(plan_price: float, equivalent_bill: float) -> float:
    """Quota multiplier = Equivalent API bill / Plan price, used to compare subscription plans horizontally"""
    return round(equivalent_bill / plan_price, 1)
# Example: Single task with 30k input (60% cache hit), 8k output
print(task_cost(30_000, 8_000, 0.6))   # ≈ 1.06 RMB/task

By replaying your team’s API call logs from the past month using this method, you can estimate the monthly bill for each candidate solution and combine it with quality test results to make a selection decision.

7. Conclusion

Whether something is “expensive” is never a question that can be answered simply by looking at a price list. By breaking down and calculating four variables—the technical drivers of the three unit prices, real task-level consumption, subscription quota multipliers, and cost per unit of intelligence—combined with your own benchmark sets and usage monitoring, any price hike or new pricing model can yield a credible, quantified conclusion within a day or two. For developers and enterprise users, rather than debating face-value numbers, it is better to integrate token costs into an engineering metrics system alongside latency and quality, continuously measuring and optimizing. This is the long-term approach to handling frequent changes in model pricing.