TPI Methodology

The TPI reports the geometric mean of blended prices across all index members, expressed in $/M tokens. Blended price = input × 0.7 + output × 0.3. The 70/30 ratio reflects a generalised production workload — most LLM tasks are input-heavy, with prompts, context, and retrieved documents typically exceeding the length of the model's response. The ratio is fixed and does not vary by model, ensuring the index measures price movement rather than workload assumptions.

Cache hit pricing is excluded from the blended price calculation by design. Including it would require assuming a cache hit rate — an assumption that varies widely by workload and would make the index harder to reproduce independently. The TPI is a posted price reference. The Simulator models cache savings separately, where you can apply your own assumptions.

All index members are equally weighted in the geometric mean. New models join at their actual market price — jumps in the index reflect real market events, not methodology changes.

The TPI tracks published API pricing — not what organisations actually pay. Realised costs are typically lower because of:

• Enterprise discounts negotiated with providers
• Prompt engineering and prompt compression that reduce input tokens
• Prompt caching on repeated context
• Model routing that sends simpler requests to cheaper models
• Batch processing for non-urgent workloads
• Infrastructure choices — committed spend, dedicated capacity, or private deployment

Treat the TPI as a posted price reference for the public market, not a forecast of your organisation's bill.

Different model families use different tokenizers, which means the same input text produces different token counts across providers. OpenAI's tokenizer is generally most efficient for English text; some other tokenizers can be 10-25% less efficient on equivalent content. This means strict per-million-token comparisons across providers slightly favour models with less efficient tokenizers.

The TPI accepts this limitation deliberately. Adjusting for tokenizer efficiency would require choosing a representative workload, and any choice (English chat, code, Chinese summarisation, long-context retrieval) introduces its own biases. The TPI measures published list prices in the unit providers themselves use. Buyers running production workloads can use the Simulator to model their specific token consumption against their specific workload.

For workload-equivalent comparisons, several third-party tools publish tokenizer efficiency benchmarks that surface these differences directly. The TPI is complementary to those benchmarks, not a replacement.