Principle:Helicone Helicone Cost Rate Lookup
| Knowledge Sources | |
|---|---|
| Domains | Cost Calculation, LLM Observability, Pricing Registry |
| Last Updated | 2026-02-14 00:00 GMT |
Overview
Resolving per-token cost rates for a given model and provider combination from a structured pricing registry.
Description
Before computing the total dollar cost of an LLM request, the system must determine the per-token rates that apply. Each provider maintains different pricing for different models, and the same model name may have different rates depending on whether it is accessed through the native provider, Azure, or a third-party gateway. Cost Rate Lookup is the process of finding the correct rate entry given a (provider, model) pair.
The lookup involves two stages. First, the correct provider entry is located in the provider registry -- either by exact provider name match or by testing the provider string against the registered URL patterns. Second, within that provider's cost table, the model name is matched against model identifiers using one of three matching operators: equals (exact case-insensitive match), startsWith (model name prefix match), or includes (substring match). This flexible matching handles model versioning (e.g., gpt-4o-2024-08-06 matching a gpt-4o prefix) and aliasing patterns.
The rate entry itself contains per-token costs for prompt tokens, completion tokens, and optional specialized rates for cache write tokens, cache read tokens, audio tokens (input and output), per-image charges, per-call charges, and Anthropic-specific cache creation tiers (5-minute and 1-hour).
Usage
Use this pattern when:
- You have a provider name and model identifier and need to know what each token costs.
- Implementing cost estimation before making an LLM call.
- Building dashboards that display per-model pricing information.
- The cost computation stage needs rate inputs to multiply against token counts.
Theoretical Basis
Cost Rate Lookup implements a two-level associative lookup. The first level maps providers to cost tables (a form of dictionary/map access). The second level performs pattern matching within the cost table using three matching strategies (equals, startsWith, includes), ordered from most specific to most general. This is conceptually a linear scan with polymorphic matching predicates.
The design separates rate definition (static data in provider-specific cost files) from rate resolution (the lookup logic), following the Separation of Concerns principle. Rate definitions can be updated independently per provider without changing the lookup algorithm.