Task-Based Pricing for LLMs: Is It Actually More Expensive?

1. Why a “Doubled List Price” Does Not Equal “Doubled Cost”

A recent round of price adjustments for high-end reasoning models has sparked widespread discussion. On the surface, one model’s output price rose from a lower level in the previous generation to 100 yuan per million tokens — a multi-fold increase. Input pricing also climbed to 20 yuan per million tokens, while cache hits remained at 1 yuan per million tokens. Many people’s first reaction is “it’s more expensive now,” but if you shift your perspective from “per-token price” to “cost per completed task,” the conclusion may be entirely different.

The key difference is that the new generation of reasoning models no longer relies on users repeatedly supplementing prompts to gradually approach a result. Instead, they complete longer reasoning chains, more self-verification, and more complete solution output in a single response. In other words, the token structure of a single task has changed: fewer input rounds, longer output, and higher cache reuse rates.

Therefore, when evaluating cost, you must break it down into three variables:

Cost per task = input tokens × input price
              + output tokens × output price
              + cache-hit tokens × cache price

If you only look at the output price increase while ignoring the reduction in input rounds and the improvement in cache hit rates, it is easy to reach an incorrect conclusion of “cost explosion.”

2. Task Completion Cost Is What Developers Actually Care About

In real development scenarios, delivering a functional module is usually not as simple as “calling an API once.” Take code generation tasks as an example. A traditional workflow might look like this:

First call:  Provide a preliminary solution, output 400 tokens
Second call: Add constraints, output 600 tokens
Third call:  Fix edge cases, output 800 tokens
Fourth call: Generate test code, output 500 tokens

A high-end reasoning model might only need:

First call: Complete solution + edge case handling + test suggestions, output 3,200 tokens

Under the traditional per-call billing mindset, the second approach does have a longer single output, but the total output volume is not necessarily higher. Under task-based pricing, the former may actually be more expensive, because repeatedly inputting the same context generates substantial duplicate input fees — and the engineer’s waiting time and interaction costs are also higher.

Based on existing test data, a high-end reasoning model costs about $0.94 on average to complete a standard task, a comparable closed-source model costs about $1.04, and another high-priced closed-source model reaches around $2. This shows that in terms of “completing a task,” the actual cost of the new generation of reasoning models is not as extreme as it might seem.

3. Price Divergence Within the Open-Weight Camp Deserves More Attention

What is truly concerning is the divergence within the open-weight camp. For the same task, the cost gap between different open-weight models can reach dozens of times:

Model A (high-end reasoning): ~$0.94 per task
Model B (balanced):           ~$0.32 per task
Model C (lightweight):        ~$0.04 per task

The lightweight model recently underwent a permanent price reduction, with input pricing dropping to 3 yuan per million tokens and output pricing to 6 yuan per million tokens. If you compare that to the high-end reasoning model’s 100 yuan output price, the gap exceeds 16 times.

But this comparison has an easily overlooked problem: they are not models at the same capability level. The lightweight model has a significant gap compared to the high-end reasoning model in complex reasoning, long-chain planning, and code generation quality. If a developer uses a lightweight model for tasks that require deep reasoning, they may end up with repeated retries because the results don’t meet requirements — and the cumulative cost may actually be higher.

4. Cache Hit Rates Are Changing the Pricing Game

The cache-hit price of just 1 yuan per million tokens is essentially designed to encourage developers to optimize their context management strategies. In multi-turn conversations, long document processing, codebase analysis, and similar scenarios, a large portion of input content is repeated. If developers can effectively leverage caching, overall costs can drop significantly.

Consider a typical enterprise knowledge base Q&A scenario:

Scenario: Each query carries the full system prompt + knowledge base summary + conversation history
System prompt:        2,000 tokens
Knowledge base summary: 8,000 tokens
Conversation history:  ~4,000 tokens on average
New question:          ~200 tokens on average
Total input: ~14,200 tokens per turn

If the system prompt and knowledge base summary hit the cache:

Cache hits: 10,000 tokens → extremely low cost
Actually billed input: 4,200 tokens → billed at 20 yuan per million tokens

With cache hits, the per-turn input cost is only about 30% of what it would be without caching. For enterprise applications that require large amounts of context, this is more meaningful than simply comparing unit prices.

5. How to Build Your Own Cost Evaluation Model

Developers should not rely on vendor-published unit prices to make decisions. Instead, build an evaluation framework that fits your own business scenarios.

Step 1: Define the task type. Is it code generation, document summarization, data analysis, or a conversational system? Different tasks have very different requirements for model capabilities.

Step 2: Design a standard test set. Prepare 10 to 20 representative real-world tasks and record the success criteria for each. For example, code tasks should pass test cases, and document tasks should cover all key information points.

Step 3: Measure cost per task. Separately count input tokens, output tokens, and cache-hit tokens, and record the number of call rounds needed to complete the task.

Step 4: Add a quality dimension. If a low-price model needs two attempts to reach the quality that a high-price model achieves in one attempt, the actual cost should be multiplied by a retry coefficient.

Step 5: Evaluate comprehensively. Calculate the cost per unit of quality across multiple models, not just the price per token.

6. Practical Advice for Developers

Taken together, this round of price adjustments sends a clear signal: model pricing is transitioning from “billing by volume” to “billing by value.” For developers, this means adjusting your cost optimization strategy.

Recommendation 1: Re-examine how you decompose tasks. If you used to break complex tasks into multiple small steps and call them separately, now you can try letting a high-end model complete a larger-grained task in one pass, reducing intermediate rounds.

Recommendation 2: Prioritize cache optimization. In your code implementation, try to keep the system prompt stable and avoid frequent modifications that invalidate the cache. For long document scenarios, consider caching documents in segments so that only the changed portions are re-billed.

Recommendation 3: Build a tiered calling strategy. For simple tasks, continue using lightweight models; for complex reasoning tasks, switch to high-end models. Don’t try to solve everything with a single model.

Recommendation 4: Focus on total cost of ownership. This includes API fees, engineer debugging time, launch cycles, and maintenance costs. Pursuing the lowest unit price at all costs may lead to higher expenses elsewhere.

The evolution of LLM pricing systems is still ongoing — from per-token billing to task-based pricing, and eventually to outcome-based pricing. Developers need to continuously update their evaluation methods to make the most appropriate technology selection decisions at each stage.