To prove that a cache discount was applied correctly, link the individual request ID and timestamp to its reported usage categories, cache telemetry, pricing terms effective at that time, a reproducible charge calculation, and the corresponding billing record. A cache-hit flag alone confirms an operational event—not that the usage qualified for a discount or that the correct rate reached the invoice.
The defensible evidence chain is:
- Identify the request and its execution context.
- Confirm how the provider classified its usage.
- Correlate that classification with cache telemetry.
- Apply the contract or rate card effective at the request time.
- Recalculate the expected charge.
- Reconcile the result with a usage ledger, billing export, and ultimately the invoice.
No single dashboard screenshot, cache-hit field, or aggregate invoice total normally establishes this entire chain. Provider schemas and commercial terms vary, so the audit must use the actual records and pricing rules governing the request.
The short answer: proof requires linked operational and financial records
A cache-discount audit has two related but separate questions:
- Did the system reuse cached content? Operational records may answer this with a hit, miss, partial-hit outcome, cache key, or correlated trace.
- Was the reused content billed at the correct rate? Financial records must show how usage was classified, whether it was eligible for discounted treatment, which rate applied, and where the charge appeared.
The first answer does not prove the second. A request may register a cache hit but fail a provider-specific eligibility condition. A partial match may place only part of the input into a discounted category. Semantic caching in a gateway or serving layer may avoid or transform a downstream request without receiving the same billing treatment as provider-native prompt caching.
Conversely, a billing export may report discounted usage without exposing all of the underlying cache mechanics. That can support financial reconciliation, but engineering teams may still need trace correlation to establish which application request produced the billed record.
A strong audit therefore connects five evidence classes:
- Request identity: a stable request, operation, or trace identifier.
- Execution evidence: timestamp, account or project, endpoint, model/version, route, and relevant cache outcome.
- Usage evidence: total input and output usage plus provider-defined cached, cache-read, cache-write, or uncached categories, where available.
- Commercial evidence: the contract, order form, or rate card effective at the request timestamp.
- Billing evidence: the most granular usage ledger or billing export available, followed by the aggregated invoice and any adjustments.
Exportable source records are generally stronger than screenshots because they retain identifiers, timestamps, dimensions, and machine-readable values. Screenshots may provide useful context, but they rarely preserve enough information for repeatable request-level verification.
Build the minimum evidence chain for the individual request
Begin with a correlation record that allows engineering, FinOps, and finance teams to refer to the same transaction. The exact field names will vary, but the evidence should establish four kinds of context.
Request identity
Capture the request identifier issued by the application, gateway, serving layer, or model provider. If those systems issue different IDs, preserve the mapping among them. A trace ID can also help link application activity to downstream calls, but it should not replace a provider request ID when the provider uses that identifier for billing investigations.
Record the timestamp with sufficient precision and retain the timezone definition. This matters when rate changes, monthly cutoffs, and usage-posting windows occur near a period boundary.
Execution context
Retain the account, organization, subscription, tenant, or project associated with the request, using whichever dimensions the relevant provider recognizes. Also capture the endpoint, selected model and version, and—when routing is involved—the model that actually handled the call rather than only the model originally requested.
This context helps prevent false matches between records that have similar times or token volumes but belong to different projects, routes, or pricing plans.
Usage record
Preserve the reported total input and output usage. Where the billing system provides more detailed classifications, retain categories such as:
- Cached or cache-read input
- Cache-write input
- Uncached input
- Output usage
- Other documented billable units
Do not assume that every system uses these labels or that all categories have different rates. The authoritative billing taxonomy is the one defined by the applicable provider and contract.
Pricing context
Identify the pricing period that includes the request timestamp. Preserve the effective version of the contract, order form, private offer, or rate card—not just the latest public pricing page.
The minimum request-level evidence package should therefore answer: which request ran, when it ran, under which account, against which endpoint and model/version, how usage was classified, and which pricing terms governed that classification.
Separate cache-hit telemetry from billable usage categories
Cache telemetry describes system behavior. Billable usage categories describe financial treatment. These records may be related, but they are not interchangeable.
Operational telemetry may report a hit, miss, or partial hit. Depending on the system, it may also include a cache key, trace reference, matched prefix, reuse event, or another correlation mechanism. Availability and terminology vary. The telemetry should be treated as evidence that cached content affected execution, not as proof of a particular charge.
The billing or usage system may separately divide consumption into cached, cache-read, cache-write, uncached, input, or output units. Those classifications are more directly relevant to the charge because they can be connected to rate terms. However, the auditor must still verify that the classification belongs to the same request and pricing period.
A practical correlation flow is:
- Start with the application request or trace ID.
- Map it to gateway or serving-layer records.
- Identify any downstream provider request IDs.
- Compare cache telemetry with provider-reported usage classifications.
- Map the classified usage to the billing export.
Pay particular attention to the type of caching involved. Provider-native prompt caching may have explicit eligibility and billing rules. Semantic caching may return or construct a response without executing the same downstream request. Serving-layer caches may also alter routing or reduce repeated computation. These approaches can have different economic effects and should not automatically be assigned the same billing treatment.
Token Forge Cloud Managed Model APIs provide model access and usage data, while Token Forge Cloud Private LLM Inference applies workload-aware caching as part of serving-layer optimization. The fields needed for a cache-discount audit should still be confirmed for the selected access and deployment model; the presence of caching or usage data does not by itself establish request-to-invoice discount verification.
Apply the rate terms that were in effect when the request ran
Once usage has been classified, apply the authoritative commercial terms effective at the request timestamp. Pricing and cache treatment can vary by provider, model, endpoint, contract, region, and period.
The relevant rate document should define, where applicable:
- Which requests, inputs, or cache mechanisms are eligible
- Whether cache reads and cache writes receive different treatment
- Which model, endpoint, region, or account restrictions apply
- The unit rates for each recognized usage category
- Rounding rules and minimum billable units
- Exclusions, commitments, tiering, or contract-specific adjustments
- Currency, conversion, tax, credit, and invoice treatment
Preserve a dated or versioned copy of these terms. A current web page is not reliable evidence of the price that governed a historical request if pricing has changed.
Eligibility deserves separate review from arithmetic. Before multiplying usage by a discounted rate, verify that the request satisfied the applicable conditions. Depending on the provider, those conditions might concern how the cache was created, how long it remained valid, what portion of the input matched, or which model and endpoint processed the call. No single set of rules applies across all providers.
Token Forge Cloud Private LLM Inference includes workload-aware caching within its serving-layer control-plane approach. That does not mean every caching event creates a separately billed discount. The economic result depends on deployment architecture, workload behavior, and the commercial terms governing any underlying model or infrastructure consumption.
Recalculate the expected charge and reconcile it to billing records
The calculation should be reproducible by someone who did not prepare the original analysis. Use source-record values, documented rates, and explicit adjustment rules rather than copying a dashboard total into a spreadsheet.
A general calculation structure is:
Expected charge = Σ (provider-classified usage category × applicable category rate) + documented adjustments
Only include categories recognized by the governing terms. For example, cached input, uncached input, output, and cache writes should be separated only if the provider's usage records and pricing agreement treat them separately.
The following table illustrates an evidence package. Every identifier and value is hypothetical and does not represent Token Forge Cloud or any model provider.
| Source | Record identifier | Hypothetical value | Purpose | Reconciliation status |
|---|---|---|---|---|
| Application trace | trace-demo-A | One application operation | Establishes the originating event | Matched |
| Provider usage record | request-demo-B | Cached input = C; uncached input = U; output = O | Establishes provider-classified usage | Matched to trace |
| Versioned contract | rate-card-demo-R | Rates = Rc, Ru, and Ro | Establishes applicable category rates | Effective at request time |
| Billing export | ledger-demo-L | Billed amount = B | Provides the granular financial record | Pending calculation |
| Invoice | invoice-demo-I | Aggregated period total | Confirms final invoiced amount | Matched at period level |
Using those hypothetical variables, calculate:
Expected request charge E = (C × Rc) + (U × Ru) + (O × Ro)
Then apply only the documented rounding, minimums, currency rules, taxes, credits, or other adjustments. Compare E with B, allowing for the billing system's stated precision and posting behavior.
Reconcile in this order:
- Usage record to calculation: confirm that every classified unit appears once in the formula.
- Calculation to billing export: compare the expected amount with the most granular financial record available.
- Billing export to invoice: confirm that the request-level or daily ledger rolls into the correct invoice period and account.
- Invoice to payment records: account for invoice-level taxes, credits, commitments, or currency conversion separately from request consumption.
A matching calculation is persuasive only when its inputs, applicable terms, and billing record can also be validated. If the invoice exposes only an aggregate total, document that limitation instead of presenting an estimated allocation as conclusive request-level proof.
Account for retries, batching, routing, partial matches, and billing adjustments
Apparent discrepancies often arise because an application event is not identical to a billable provider call. Normalize operational and accounting differences before deciding that a discount was omitted.
Retries: A timeout or connection failure may cause another downstream call. Determine whether the first call reached the provider, whether both calls generated usage, and which IDs belong to each attempt. Do not assume every retry is billed—or that an application reports every billable attempt.
Batching: Multiple application operations may be combined into one provider request, or one application batch may produce several downstream calls. Reconcile through batch membership and child request identifiers when those records are available rather than relying only on timestamps.
Routing: A gateway or control plane may send the request to a different model or endpoint. Verify the actual destination and apply its terms. Token Forge Cloud Private LLM Inference uses routing and batching as part of serving-layer optimization, but teams should confirm how relevant operational records map to their own billing sources.
Partial cache matches: A single request may contain both cached and uncached portions when the provider supports that classification. Recalculate each recognized portion independently instead of applying a discounted rate to the entire input.
Streaming: Response chunks are not necessarily separate billable requests. Use the provider's final usage record or documented accounting method rather than counting stream events as billing units.
Asynchronous posting: Usage records and invoices may update on different schedules. Check posting delays, billing cutoffs, late adjustments, and timezone conversions before declaring a variance.
Currency, taxes, and credits: Request-level usage charges may be recorded before currency conversion, tax, contractual credits, commitments, or invoice-level adjustments. Reconcile the pre-adjustment usage amount first, then walk through each financial transformation separately.
These factors should be documented as reconciliation steps, not used to force a match. If the records still disagree after normalization, retain the unresolved variance and escalate it with the source evidence.
Package the audit evidence and escalate unresolved discrepancies
A review-ready package should let another stakeholder reproduce the conclusion without relying on live dashboards or undocumented assumptions.
Use this concise audit checklist:
- [ ] Preserve the application, gateway, serving, and provider request identifiers.
- [ ] Record timestamps with precision and timezone definitions.
- [ ] Confirm the account or project, endpoint, actual model/version, and pricing period.
- [ ] Retain original usage records and all available cache-related classifications.
- [ ] Correlate cache telemetry with financially classified usage without treating them as equivalent.
- [ ] Preserve the contract or rate-card version effective at request time.
- [ ] Document eligibility, rates, rounding, minimums, exclusions, currency, taxes, and credits.
- [ ] Recalculate the expected charge using a saved formula or script.
- [ ] Compare the result with the granular usage ledger before the aggregated invoice.
- [ ] Investigate retries, batches, routes, partial matches, posting delays, and adjustments.
- [ ] Record the variance, reviewer, review date, assumptions, and unresolved limitations.
- [ ] Retain original exportable files alongside working calculations and notes.
If the request cannot be reconciled to aggregated billing, first verify the billing period, account mapping, posting schedule, aggregation level, route, retries, credits, and currency treatment. Then isolate the smallest reproducible discrepancy available.
An escalation package should include:
- Request and trace identifiers
- Timestamp and timezone
- Account, project, endpoint, and model/version
- Original usage and cache records
- Applicable pricing terms and effective dates
- The complete calculation method
- Relevant billing-export or invoice records
- Expected amount, observed amount, and documented variance
- Steps already taken to rule out aggregation or adjustment issues
Ask the provider or billing owner to explain the mapping from classified usage to the billed amount—not simply to confirm that caching occurred. If only aggregate billing is available, describe the outcome as an aggregate reconciliation or estimated allocation rather than request-level proof.
Token Forge Cloud supports managed model access and private LLM inference. Token Forge Cloud Private LLM Inference focuses on serving-layer control through caching, routing, batching, quantization, and GPU scheduling, while Token Forge Cloud Managed Model APIs offers an API-first path with usage data. The audit records available will depend on the selected service, deployment design, and upstream billing systems.
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.