When cache writes and cache reads have different prices, record them as separate usage categories with independent quantities, billing units, unit prices, and subtotals. Do not combine them into generic input tokens or a single cache-token total. Keep uncached input and output separate as well whenever the provider prices those categories independently.
The Short Answer: Record Cache Writes and Reads Separately
A useful cost model should preserve each independently priced dimension. At minimum, that often means maintaining distinct records for:
- Uncached input
- Output
- Cache write
- Cache read
- Any other provider-defined, separately priced usage
The basic calculations are:
``text cache_write_cost = cache_write_units × applicable_write_rate cache_read_cost = cache_read_units × applicable_read_rate ``
If a rate is quoted per thousand or per million units, first convert the usage quantity to the same denominator:
``text category_cost = (quantity ÷ rate_denominator) × unit_price ``
The request or billing-period total is then:
``text total_cost = uncached_input_cost + output_cost + cache_write_cost + cache_read_cost + other_separately_priced_costs ``
This separation matters because two categories can contain the same type of technical unit—such as tokens—without having the same billing treatment. A cache-read token should not automatically be treated as an ordinary input token, and a cache write should not be merged with a cache read merely because both relate to prompt caching.
This accounting approach is a practical recommendation rather than a universal provider billing standard. Provider terminology, units, cache eligibility rules, lifetimes, and pricing formulas can differ by provider and model. Verify the mapping used in a production system against the applicable provider documentation and commercial terms.
A Normalized Schema for Cache Usage and Cost
A normalized schema gives finance, engineering, and operations teams stable internal categories while retaining enough context to trace each value back to its source. The most reliable pattern is one record per independently priced usage category rather than one wide total with ambiguous token counts.
Required usage, pricing, and context fields
A normalized usage record should generally include the following fields:
| Field | Purpose |
|---|---|
usage_type | Stable internal category such as uncached_input, output, cache_write, or cache_read |
quantity | Measured amount assigned to the category |
billing_unit | Unit used for pricing, such as tokens, requests, or another provider-defined measure |
rate_denominator | Scale to which the price applies, such as per thousand or per million units |
unit_price | Applicable price for the category and denominator |
currency | Currency associated with the rate and subtotal |
subtotal | Calculated cost for this category |
provider | Provider responsible for the usage definition and price |
model | Model or model version associated with the usage |
observed_at | Time at which the usage occurred or was reported |
pricing_version | Rate-card version, effective date, or another historical price reference |
request_id or billing_period | Context connecting the record to a request, workload, invoice period, or internal allocation |
raw_usage_reference | Link, identifier, or embedded source fields used to produce the normalized record |
The quantity and price should be stored separately rather than retaining only the calculated subtotal. This allows teams to inspect the arithmetic, apply corrected mappings, or recalculate historical costs when a rate was entered incorrectly.
Currency should also be explicit. A bare value such as 0.50 is not sufficiently defined unless the record identifies the currency, denominator, usage category, and applicable pricing period.
Rates should be versioned instead of overwritten. If a provider changes a price—or a negotiated commercial rate becomes effective on a particular date—the historical usage record should remain associated with the rate that applied at that time. Public and negotiated rates may differ, so the price source or agreement reference can be useful context.
Example normalized usage table
The following table illustrates how one request could be represented. The rates and quantities are entirely hypothetical and do not represent pricing from Token Forge Cloud or any model provider.
| Usage type | Quantity | Billing basis | Hypothetical unit price | Subtotal |
|---|---|---|---|---|
| Uncached input | 200,000 tokens | Per 1,000,000 tokens | $2.00 | $0.40 |
| Output | 50,000 tokens | Per 1,000,000 tokens | $8.00 | $0.40 |
| Cache write | 100,000 tokens | Per 1,000,000 tokens | $3.00 | $0.30 |
| Cache read | 600,000 tokens | Per 1,000,000 tokens | $0.50 | $0.30 |
| Total | $1.40 |
For the hypothetical cache-write row:
``text (100,000 ÷ 1,000,000) × $3.00 = $0.30 ``
For the hypothetical cache-read row:
``text (600,000 ÷ 1,000,000) × $0.50 = $0.30 ``
This example demonstrates why quantity alone is not a sufficient basis for comparison. Cache-read usage is larger than cache-write usage in the example, but the two subtotals are equal because the hypothetical rates differ. Combining both into 700,000 cache tokens would discard the information required to reproduce the calculation.
In an implementation, each row should also carry the provider, model, currency, observation time, rate version, and request or billing-period identifiers. Depending on the data platform, these may be columns in the same table or keys linked to a separate pricing record.
Granular records can inform several operational questions:
- Cost attribution: Which application, team, customer, or workflow generated each category of usage?
- Cache evaluation: How much measured usage is associated with cache creation compared with reuse?
- Routing analysis: How would provider or model routing choices change the applicable category mix and rate structure?
- Enterprise reporting: Can finance and operations explain changes in total inference spend using stable usage categories?
These records are decision inputs rather than proof that a particular caching or routing policy will reduce costs. Workload behavior, model requirements, latency targets, cache eligibility, and provider rules all affect realized economics.
Preserve Provider Fields While Normalizing Names and Units
Normalization should create consistency without erasing source meaning. Retain the raw provider usage payload—or at least the relevant original fields—beside the normalized record. This makes it possible to investigate differences among internal calculations, usage reports, and invoice periods without relying on a mapping that may later change.
A practical data flow is:
- Store the raw response or usage event without changing its field names.
- Identify the provider, model, request, timestamp, and billing context.
- Map each provider field to a controlled internal usage category.
- Convert the quantity only when the source unit and target unit are compatible.
- Apply the rate that was effective for the relevant model, category, and time.
- Store the normalized record, calculation inputs, subtotal, and source reference.
Map provider terminology to internal usage types
Providers may use different labels for technically or commercially related concepts. An internal mapping layer can translate those labels into stable names such as cache_write and cache_read, but it should also preserve the original label.
For example, a mapping record might contain:
``text raw_field_name: <provider-supplied label> normalized_type: cache_read mapping_version: 2026-01 provider: <provider identifier> model: <model identifier> ``
The normalized category should represent the field's documented billable meaning, not merely a similar-sounding term. A provider-reported count may describe cache creation, eligible cached input, retrieved cached input, or another measurement. Those concepts should not be treated as interchangeable until their definitions have been checked.
Mapping rules may need to vary by both provider and model. They may also need effective dates if a provider changes its response schema or billing treatment. Versioning the mapping protects historical records from being silently reinterpreted under a newer definition.
Data state is equally important. These values should remain distinct:
- Zero: The category was reported and its measured quantity was zero.
- Null: The field exists, but no usable value was supplied.
- Missing: The expected field was absent from the source event.
- Unreported or unsupported: The source does not expose that category in the available usage data.
An unavailable cache value should not be converted silently to zero. Zero implies measured absence; null or missing means the system does not have enough information to make that statement. Preserving this distinction improves exception handling and prevents incomplete records from appearing complete.
Convert billing units without changing billable meaning
Unit normalization is valid only when it preserves the provider's billing definition. Converting a price from “per million tokens” to “per token” is straightforward arithmetic. Converting a provider-specific cache event into tokens may not be valid unless the provider defines that relationship.
Before applying a conversion, confirm:
- The source quantity's technical and billing definition
- Whether the quantity is already included in another reported category
- The denominator used by the applicable rate
- The currency and rounding rules
- The model and pricing period to which the rate applies
Avoid assuming that every token reported in an API response is independently billable. Some fields may be informational, nested within totals, or subject to provider-specific eligibility rules. Summing a parent total and its component fields can create double counting if their relationship is not understood.
Rounding policy should be explicit as well. A system might calculate high-precision subtotals per request and round only at aggregation, while an invoice may apply rounding at another level. Keeping unrounded calculations, displayed values, and invoice-period totals distinguishable can make reconciliation more informative.
A concise reconciliation review should cover:
- Provider and model identity
- Raw-to-normalized category mapping
- Quantity, billing unit, and rate denominator
- Currency and applicable rate effective date
- Arithmetic and rounding policy
- Duplicate or overlapping usage categories
- Zero, null, missing, and unreported states
- Alignment between request timestamps and invoice periods
- Comparison with the retained raw usage fields
This process does not guarantee an exact invoice match because providers may apply aggregation, credits, minimums, adjustments, taxes, or other commercial rules outside request-level usage. It does, however, create a traceable basis for investigating differences.
Applying Granular Metering to LLM Inference Operations
Cache metering becomes more useful when it is connected to serving decisions rather than treated only as a billing export. Token Forge Cloud focuses on LLM inference cost control at the serving layer through caching, routing, batching, quantization, and GPU scheduling. For teams designing a private inference control plane, distinct usage categories can provide clearer inputs for evaluating how workload behavior relates to serving policy.
Token Forge Cloud Managed Model APIs provides an API-first path for teams seeking model access and usage data, with a path into private deployment as workloads become predictable. When evaluating any API or private deployment architecture, teams should determine whether the available telemetry is granular enough for their own attribution, reporting, and cost-analysis requirements.
This guide recommends the cache-write and cache-read schema as an implementation pattern; it does not describe a specific Token Forge Cloud billing or telemetry interface. Its purpose is to help technical and financial teams define the data they need before selecting providers, building normalization pipelines, or comparing managed API access with private model serving.
Next Step
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.