How to Calculate a Blended Token Price for LLM APIs

In LLM API billing, costs are commonly divided into three token categories: cached-context reads, uncached new input, and model-generated output. Many teams focus only on an “input price” or “output price,” overlooking the fact that cache-hit rates can be very high in real workloads. As a result, model selection decisions can differ substantially from the month-end bill.

The basic method for controlling costs is to weight the prices of these three categories by their actual usage proportions and calculate a blended token price that can be compared across options.

Why List Prices Are Not Enough

An LLM request is not simply “a piece of text at a fixed price.” If a platform has already cached the relevant context, subsequent requests may be billed at a lower cache-read rate. If the cache does not apply, the tokens are charged at the full input rate. Generated responses are billed entirely at the output rate.

In conversational applications, retrieval-augmented generation (RAG), and code completion workflows, system prompts, knowledge snippets, and multi-turn conversation history are often submitted repeatedly. Cache-hit rates can exceed 70%. Comparing providers by simply adding input and output rates can therefore systematically overestimate or underestimate the cost of certain pricing structures.

A blended token price provides a reproducible formula for reducing three price columns from different providers or service tiers into one comparable unit, typically cost per million tokens. Combined with workload-specific cache assumptions, it becomes a cost metric that can be ranked, reviewed, and audited. It does not replace contract terms, but it helps avoid the mismatch of choosing the lowest list price and receiving the highest bill.

What the Three Price Categories Mean

Read price (cache hit): The rate charged for reading a cached prefix or context. It is usually substantially lower than the uncached input rate. This is particularly relevant for products with stable system prompts, fixed tool definitions, or long multi-turn sessions.

Input price (cache miss): The rate for newly submitted tokens, including documents uploaded for the first time, changing user questions, and dynamic retrieval results. Depending on the service tier, it may fall between the read and output rates or be close to the output rate.

Output price: The rate for content generated by the model. It is often the highest rate because computation and bandwidth are concentrated during generation. Long responses, chain-of-thought processing, and code generation can significantly increase its contribution to total cost.

Use a consistent unit, such as cost per million tokens, so that prices can be aligned with usage monitoring. If official pricing is quoted per thousand tokens or per request, convert it before applying weights to avoid mixing units.

Recommended Blended Price Formula

When detailed usage logs are unavailable, an initial ranking can use a set of estimated weights:

Blended token price = 0.8 × read price + 0.1 × input price + 0.1 × output price

This assumes that 80% of billed tokens are cache hits, 10% are new input, and 10% are output. It is not an industry standard. It is only an approximation for workloads where prompts and knowledge sources are relatively stable and responses are reasonably constrained. The weights must be explainable and replaceable; they should not be treated as permanent assumptions.

The general formula is:

Blended token price = α × read price + β × input price + γ × output price

Where:

α + β + γ = 1

All three values should be calculated from actual traffic:

• α: cached token count / total billed token count
• β: uncached input token count / total billed token count
• γ: output token count / total billed token count

Once logs are available, replace the default 0.8/0.1/0.1 weights with measured values immediately. A chat assistant, customer-service quality review workflow, and batch summarization pipeline can have α and γ values that differ by an order of magnitude. Applying one shared set of weights will distort the ranking.

Calibrating Weights from Logs

Measure stable traffic for at least one week, separated by application and environment.

1. Retrieve input_tokens, cached_tokens, and output_tokens for each request from the gateway or SDK.
2. Define read tokens as cached_tokens, and input tokens as input_tokens − cached_tokens. If the API already exposes separate fields, use them directly.
3. Aggregate the three token categories by day, calculate α, β, and γ, and observe their variation. If weekends and weekdays differ materially, create separate weight sets for each scenario.
4. Put extremely long contexts, such as tiers above hundreds of thousands of tokens, into separate buckets because some products change pricing after a context-length threshold.
5. If pricing differs between peak and off-peak periods, do not use a simple arithmetic average of prices. Weight each price by its corresponding traffic share first, then calculate the all-day blended price.

If cache-related fields are unavailable, use the proportion of repeated identical prefixes as a conservative estimate. Clearly label the uncertainty in the conclusion rather than presenting an estimate as an exact ranking.

Using the Metric for Selection and Cost Reviews

For cross-provider comparisons, compare only blended token prices calculated with the same weights and the same units. Always retain the separate read, input, and output price columns as well. This prevents a seemingly low blended price from becoming expensive when output length increases.

For internal cost reviews, multiply the blended token price by token usage in millions to estimate the expected cost, then reconcile that estimate with the invoice. Differences commonly come from cache misses, retries and streaming charges, hidden chain-of-thought tokens, or tool-calling round trips that are billed twice. Breaking the variance back into the three token categories is usually more effective than looking only at the total amount.

Common architectural methods for lowering the blended price include:

• Keeping system prompts stable so they can be cached
• Deduplicating and truncating retrieval results
• Controlling output length and sampling behavior
• Placing unchanged tool definitions in a cacheable prefix
• Shifting calls outside peak periods when time-based pricing exists

These measures change α, β, and γ directly. In many cases, they are more effective than switching to a service tier with a lower list price.

Formula Limits and Compliance Considerations

A blended token price is a cost model, not a quality or compliance score. Latency, availability, content safety, data residency, and context-window limits must be evaluated separately.

Do not use unverified public reference prices in formal rankings. If any of the read, input, or output price columns are missing, mark the option as non-comparable rather than filling the gap with zero or an assumption.

Avoid publishing comparison tables that identify third-party model brands or product tiers. Internally, teams can use anonymized tiers, such as a “long-context tier” or “low-latency tier,” together with their own monitoring data. Procurement contracts and official billing terms remain authoritative; the blended price is only an internal estimation tool.

Implementation Checklist

• Have all three prices been converted to the same unit, such as cost per million tokens?
• Are the weights based on workload logs rather than the default 0.8/0.1/0.1 assumption?
• Are time-based prices and context-length tiers calculated separately?
• Has the difference between estimated cost and the invoice been attributed to caching and output behavior?
• Does each optimization action record its impact on α, β, and γ for the next review?

Using this approach, teams can turn subjective judgments about which option is cheaper into an auditable cost model. The same numbers can then support cost control, capacity planning, and architecture trade-offs.