COST ESTIMATION · 2026-08-06

How Provider Pricing Models Differ: Per-Token, Per-Request, and Per-Character

A comparison of the different billing unit structures LLM and AI API providers use, and why the billing unit itself, not just the rate, matters for accurate cost comparison.

Most large language model APIs bill per token, but that is not universal across the broader AI API landscape, and even within token-based pricing there are meaningful structural differences between providers that affect how a fair cost comparison should be built. Understanding the billing unit itself is a prerequisite to comparing rates meaningfully.

Per-Token Pricing and Its Variants

The dominant model among major LLM providers is per-token pricing with separate rates for input and output tokens, as covered in depth elsewhere in this series. Within this model, providers differ in how they price additional dimensions such as cached tokens, batch processing, and sometimes different rates by context window length tier, meaning two providers both described as per-token can still have meaningfully different effective cost structures for the same workload.

When comparing per-token providers, build your comparison around your actual workload's input-output ratio, cache-hit potential, and batch-eligibility rather than comparing headline input and output rates in isolation, since the effective blended rate for your specific usage pattern can rank providers differently than the sticker price alone would suggest.

Per-Character and Per-Request Pricing

Some AI APIs, particularly certain speech, translation, and specialized services adjacent to core LLM APIs, bill per character or per request rather than per token, which requires an entirely different unit conversion when building a blended cost estimate for a pipeline that combines an LLM call with one of these adjacent services.

Per-request flat pricing, where a fixed fee applies regardless of content length within some bound, can be advantageous for workloads with consistently long inputs relative to the flat fee, but disadvantageous for workloads with typically short, simple requests that would cost less under a granular per-token model, so this pricing structure rewards understanding your own typical request size distribution before assuming it is more or less cost-effective.

Committed-Use and Volume Discount Structures

Beyond the base per-unit rate, many providers offer volume-based discount tiers or committed-use pricing arrangements, where committing to a minimum spend or usage volume over a period unlocks a reduced effective rate compared to standard pay-as-you-go pricing, similar in spirit to reserved capacity pricing common in traditional cloud infrastructure.

Evaluate committed-use arrangements only once you have a reasonably confident usage forecast, since committing to a volume you do not reliably reach can result in paying for unused capacity, which can easily erase the discount's benefit; this is closely related to the forecasting discipline covered in the dedicated cost forecasting article.

Building an Apples-to-Apples Comparison

When comparing providers with different billing structures for the same workload, convert everything to a common unit, typically an estimated cost per completed task or cost per unit of business value, such as cost per resolved ticket or cost per processed document, rather than attempting to compare raw per-token, per-character, or per-request rates directly against each other.

Document the specific assumptions behind any cross-provider or cross-pricing-model comparison, including the workload characteristics used, since a comparison valid for one input-output ratio or request size distribution may not hold for a different workload, and an undocumented comparison risks being reused inappropriately for a different decision later.

Key takeaways

Bottom line

The billing unit itself, not just the headline rate, shapes how a fair cost comparison should be built, and conflating different pricing structures is a common source of misleading provider comparisons. Anchoring every comparison to your actual workload and a common outcome-based unit avoids that trap.

Try the free calculator

Put this framework into practice: model your own token volume against Claude, GPT and Gemini pricing side by side.

Related reading