Pillar
LLM pricing tables: keep costs accurate and handle unknown models
Pricing accuracy is a trust layer. If pricing table workflows drift, dashboards lose financial credibility.
What accurate pricing requires
- Versioned model pricing updates with effective dates
- Unknown-model visibility and approval workflow
- Snapshot cost-at-ingest strategy for historical consistency
- Separation of test/demo traffic from production pricing insights
Unknown-model triage workflow
- Flag unknown model requests in monitoring views daily.
- Create pricing request with source and effective date.
- Approve model pricing with owner traceability.
- Verify new ingests are priced without backfilling historical rows.
Pricing change governance
- Never rewrite historical cost snapshots.
- Document pricing source and verification timestamp.
- Keep provider/model mapping rules versioned.
- Run monthly reconciliation checks against provider usage exports.
Minimum pricing table schema (start here)
Pricing accuracy depends on having one authoritative mapping from provider/model identifiers to effective rates.
Keep the schema small, versioned, and owner-reviewed. The goal is auditability as much as cost correctness.
- provider and model identifier (as seen in telemetry)
- effectiveFromUtc (start date for the rate)
- unit rates for input and output usage (and any additional classes you track)
- currency and source reference (URL / invoice export / internal contract)
- createdAtUtc + approvedBy (owner traceability)
Pricing table schema (example fields)
Write the schema explicitly so finance and engineering agree on “what fields exist” and “what gets versioned”.
This also makes unknown-model triage faster because owners know exactly what to fill in.
- provider (openai): primary namespace for model IDs.
- model (gpt-4o-mini): model identifier as seen in telemetry.
- effectiveFromUtc (2026-02-01): when this rate starts applying to new traffic.
- inputRate ($ / 1M tokens): unit rate for input usage.
- outputRate ($ / 1M tokens): unit rate for output usage.
- currency (USD): audit-friendly normalization.
- source (provider pricing page / invoice): evidence for finance and audits.
- approvedBy (name@company.com): owner accountability.
- createdAtUtc (2026-02-15T12:00Z): immutable change log anchor.
Token classes that break naive cost math
Teams often assume all tokens are billed the same way. In practice, providers may expose different usage classes (cached, reasoning, audio, etc.).
The safest approach is to store raw usage fields and map them into normalized fields with documented rules.
- Cached usage: can be priced differently or counted separately depending on provider/product.
- Reasoning usage: may be metered separately from standard input/output tokens.
- Audio usage: may not map cleanly to text token pricing models.
- Missing usage: treat as uncertainty, not zero.
Snapshot pricing at ingest time (for historical consistency)
If you reprice old requests every time a rate changes, your historical charts will rewrite themselves. That breaks trust and makes audits painful.
Snapshot effective rates at ingest time so historical cost is stable, then apply new rates only to new traffic after the effective date.
Reconciliation workflow (monthly, lightweight)
- Export provider usage totals for the month (or billing period).
- Compare totals to your internal aggregates for the same window.
- Investigate deltas: unknown models, missing usage fields, or timezone window mismatches.
- Verify effective dates for any pricing changes in the period.
- Record a reconciliation note with timestamp, owner, and outcome.
Enterprise overrides without corrupting history
Overrides are sometimes necessary (contract pricing, private rates, or internal chargeback rules). The key is to keep overrides versioned and auditable.
Use effective dates, require approval, and keep an immutable change log so finance questions have an answer.
- Create override requests with rationale and evidence.
- Require one pricing owner + one finance reviewer.
- Apply overrides forward-only (do not rewrite history).
- Monitor reconciliation deltas after applying overrides.
Multi-provider mapping tips
- Normalize model identifiers into one catalog view so dashboards remain comparable.
- Keep provider-specific quirks in the mapping layer, not in every query/report.
- Version provider/model mapping rules the same way you version promptVersion deploys.
- Alert on “unknown model” as an operational queue, not a data bug.
What to send (payload example)
{
"externalRequestId": "req_01HZXB6MQZ2WQ9D2KCF9M4V2QY",
"provider": "provider_id",
"model": "model_id",
"endpointTag": "catalog.pricing_reconcile",
"promptVersion": "pricing_v2",
"userId": "tenant_acme_hash",
"inputTokens": 320,
"outputTokens": 120,
"latencyMs": 892,
"status": "success",
"dataMode": "real",
"environment": "prod"
}Common mistakes
- Overwriting historical price snapshots instead of versioning by effective date.
- Ignoring unknown-model rows until dashboards become untrustworthy.
- Missing cached/reasoning token nuances and mispricing requests.
- Mixing test/demo traffic into production pricing reconciliation.
How to verify in Opsmeter Dashboard
- Open Catalog to confirm model mapping and pricing effective dates.
- Check unknown-model visibility and resolve pending pricing rows.
- Spot-check cost snapshots on recent requests to validate ingestion accuracy.
- Reconcile aggregates against provider usage exports for the same window.
Templates
Unknown model triage ticket (template)
# Unknown model pricing request
Provider:
Model identifier (as seen in telemetry):
First seen (UTC):
Volume impact (requests/tokens):
Proposed rates:
- input:
- output:
- other classes (cached/reasoning/audio):
EffectiveFromUtc:
Source link / evidence:
Approver:
Notes:
Related guides
Evaluation resources
For security and procurement reviews, use our trust summary before final tool selection.