Low-Cost LLM Plan Economics: Reverse-Engineering Billing and Cache Costs

Large-model commercial pricing is evolving from token-based API billing toward subscription plans. Plans are user-friendly: the monthly fee is fixed and the quota is easy to see. At the same time, they introduce a black box: when you send a request, you do not know exactly how much quota it consumes.

On the surface, monthly fees for plans from different providers may look similar, but the actual token volume they can support may differ by several times. Industry third-party teams have conducted systematic tests and reverse-engineered hidden billing systems. They found that, during the same period, equivalent unit prices across flagship subscriptions could differ by several times. Some lightweight plans focused on cost-effectiveness have pushed equivalent prices to a fraction of flagship plans, or even directly challenged traditional flagship plans.

Where does this pricing confidence come from? The answer lies in three things: the billing structure of token types, cost dilution from caching technology, and the design of plan quotas.

1. The Starting Point: Why Plan Pricing Is Hard to Interpret

A plan quota is often shown as a remaining percentage or a vague credit value, without directly publishing the deduction rate for each token category. To reconstruct the real deduction rates, the core idea is to control variables: make each request consume a large amount of only one token category, then observe changes in the quota percentage.

1.1 Isolate Tests by Token Type

LLM billing generally involves four token categories: cache-hit input, uncached input including cache writes, and model output. Measurement requires separate request patterns:

• Measure cache hits: first write a large fixed context, then repeatedly send requests with the same prefix so that most input tokens hit the cache.
• Measure uncached input: change the content on every request and deliberately avoid the cache.
• Measure output: ask the model for long responses so that output tokens become the main consumption.
• Measure cache writes: send a new long context and capture the premium charged during the first write.

1.2 Use Integer Jumps to Improve Measurement Precision

Quota interfaces usually show only an integer percentage, so a single request may not visibly change the number. The solution is to run many requests continuously, record the cumulative token consumption when the quota jumps from 17% to 18%, from 18% to 19%, and so on, then average across multiple complete intervals. This smooths out random error and produces a stable slope for “how much quota is consumed per million tokens of a given category.”

# Pseudocode: measure the quota consumption slope for one token category
def measure_rate(token_kind):
    spend, prev_pct = 0, quota_used_percent()
    while not enough_samples():
        send_request(token_kind)      # construct a request that mostly consumes this token kind
        spend += tokens_of_last_request()
        cur_pct = quota_used_percent()
        if cur_pct > prev_pct:        # integer percentage has jumped
            record(prev_pct, cur_pct, spend)
            prev_pct, spend = cur_pct, 0
    return average_tokens_per_percent()

1.3 Weight by Real Workloads

After measuring the four deduction rates, weight them by the share of each token category in a real workload. For example, in a coding Agent scenario, input is often dominated by cache hits, while output accounts for a very small share. This lets you infer how many tokens a plan can theoretically support. The real value of this methodology is that it translates marketing language into comparable engineering numbers.

2. Why Do the Four Token Categories Have Different Costs?

Why can “one token” have deduction rates that differ by an order of magnitude? The answer is the real cost structure of inference serving.

2.1 Cache Hits: Computation That Is Nearly Reused

Mainstream inference frameworks implement prefix KV caching. If multiple requests share the same prefix—system prompts, long documents, or conversation history—the server can reuse the attention key-values that have already been computed and calculate only the incremental part. This avoids the prefill computation for the entire prefix. As a result, the marginal cost of cache-hit input is very low, and its billed unit price is often only a fraction of uncached input.

2.2 Uncached Input and Cache Writes: Paying a “Prefill Tax” Once

When new content enters the model, it requires a full prefill computation and generation of KV cache. The first write is itself a complete computation and also consumes GPU memory and storage. Many pricing systems therefore reflect this cost in a higher unit price for cache writes or a premium for uncached input.

2.3 Output: Serial Token-by-Token Decoding

Output tokens must be generated one after another and cannot be parallelized at the same scale as input. During decoding, compute utilization is lower, latency is sensitive, and resources must be reserved for each concurrent connection. As a result, output tokens are the most expensive category in almost every pricing system.

Once this structure is clear, it becomes obvious that a plan with a very high “theoretical equivalent token volume” is essentially putting most of its weight on the cheapest token category.

3. The Gap Between Theoretical Values and Real Usage

A common theoretical calculation makes assumptions such as: for every 1 million tokens processed, about 970,000 are cache hits, about 25,000 are uncached input, and only about 5,000 are output. In other words, it assumes an extremely friendly coding scenario: large contexts are reused repeatedly and almost no new content is generated.

Real usage is not so ideal:

• Task switching breaks the cache: moving from one module to another or changing the conversation topic invalidates the carefully maintained prefix, and the next round of requests falls back entirely to uncached input.
• Caches have a lifecycle: server-side caches usually have a time window or capacity limit. Returning the next day or being evicted during peak periods can cause hit rates to drop sharply.
• Output share is underestimated: when writing code or refactoring, output is far more than 0.5%; in debugging loops, the model must generate large blocks of code and explanations every round.

This is like an electric vehicle rated at 500 kilometers of range—that is a theoretical value measured under continuous no-load driving, low speed limits, and good aerodynamics. In daily commuting with air conditioning and highway driving, reaching 60% to 70% may already be good. If you directly convert theoretical values into “cost per million tokens,” the result will be systematically low, and selection decisions based on it will inevitably run into problems.

4. The Basis for Low-Cost Plans: Three Technical Supports

Returning to the core question: why do some providers dare to push the equivalent price of lightweight plans into the same range as traditional flagship plans? The confidence comes from at least three areas.

1. Cache reuse dilutes marginal costs. Coding workloads naturally have high cache-hit rates: system prompts are fixed, and codebase context is referenced repeatedly. Providers know that most tokens in a plan will be consumed in the low-cost form of cache hits, so they can price according to a low-cost structure. This also explains why reverse-engineering often shows that the gap between lightweight and flagship plans in “cache-hit deduction rate” is much smaller than the gap in “output deduction rate.”

2. Continuous optimization on the inference side. General techniques such as batch scheduling, operator fusion, quantization, speculative decoding, and sparse attention are continuously reducing inference cost per token. Larger service providers have higher GPU utilization and lower unit costs, leaving more room for price reductions. Lightweight models have fewer parameters and make trade-offs in context and capability, so their serving costs are naturally lower.

3. Optimistic tilt in quota design. Plan quotas are essentially statistical multiplexing: providers estimate monthly consumption based on typical user profiles and leave room for overselling. If the pricing assumptions lean toward high cache hits and low output, the theoretical capacity numbers will look very attractive. A small number of heavy users who break the assumptions are absorbed by the overall pool.

5. How Developers Should Evaluate the Real Value of a Plan

Rather than trusting theoretical numbers on a marketing page, it is better to build your own evaluation framework.

1. Profile your own workload first: use logs to measure the real token structure—cache-hit rate, input-to-output ratio, and context reuse patterns. For the same monthly fee, someone writing small scripts and someone maintaining a large codebase may see actual capacity differ by an order of magnitude.

2. Run your own reverse-engineering experiment: follow the isolation measurement approach described above, control variables, and average across multiple intervals. In an afternoon, you can measure the four deduction rates of a plan you already have.

3. Build a sensitivity model: do not calculate only a single point. Calculate a curve. How does the equivalent cost change when the cache-hit rate drops from 95% to 70%? What happens when the output share rises from 1% to 10%?

def effective_cost(hit_ratio, out_ratio, price):
    fresh_ratio = 1 - hit_ratio - out_ratio
    return (hit_ratio * price["cache_read"]
            + fresh_ratio * price["fresh"]
            + out_ratio * price["output"])

1. Look beyond price: context length limits, cache retention time, concurrency and rate-limiting policies, and model capability tiers all affect the real value of a plan. Price is only one side of the equation.

6. Conclusion

The price differences among LLM plans appear to be market strategy, but at the底层 they are driven by cost structure: caching technology changes the marginal cost distribution of tokens, inference optimization determines the lower bound of unit cost, and quota design determines the distance between theoretical and actual values. For developers, the important thing is not a ready-made conclusion about “which provider is cheaper,” but mastering the methods of reverse-engineering and modeling. Once you understand the token structure of your own workload, any pricing system becomes transparent to you. The same methodology applies regardless of which LLM platform you ultimately choose, such as Baidu AI Cloud.