LLM usage metering and billing

Published 1 August 2026

Most teams cannot answer a simple question: which feature, team, or customer caused this LLM bill? Provider invoices group everything into one line item. Metering is the fix. It means recording every request with enough metadata to allocate cost later. Billing is what you do with that data: chargeback to teams, invoicing to customers, or showback to leadership.

This is not theoretical. Companies running multi-tenant AI products need per-customer metering to invoice accurately. Companies running internal AI platforms need per-team metering to allocate budget. Both need the same underlying records.

What to meter

Every LLM request should produce one record with these fields:

Without cache-read and cache-write split, teams miscount savings. Prompt caching reduces input cost, but the cache-read discount only applies to repeated prefixes. If you count cache-read tokens as full savings, you overstate the benefit by 2-3x.

How to collect the data

Three patterns work in production:

Gateway pattern. Route all LLM traffic through a proxy (LiteLLM, Helicone, Langfuse, or a custom gateway). The gateway logs every request with metadata. This is the fastest to deploy and gives you one place to enforce budgets and rate limits. Downside: single point of failure, and you must route all traffic through it.

SDK instrumentation. Use OpenTelemetry auto-instrumentation or a thin wrapper around the provider SDK. Each request emits a span with attributes. This works when you control the application code and want per-request granularity without a gateway. Downside: you must instrument every service, and teams can forget.

Provider log export. Some providers (OpenAI, Anthropic) offer usage APIs or log exports. This is the easiest to set up but gives you daily aggregates, not per-request records. Use this as a reconciliation source, not as primary metering.

The strongest setups use a gateway for enforcement plus SDK instrumentation for redundancy, then reconcile against provider invoices monthly.

Building the billing layer

Once you have daily usage records, the billing layer is a SQL aggregation:

SELECT
  team,
  feature,
  model,
  SUM(input_tokens) AS input_tokens,
  SUM(output_tokens) AS output_tokens,
  SUM(cache_read_tokens) AS cache_read_tokens,
  SUM(cost_estimate) AS total_cost
FROM llm_usage
WHERE date >= '2026-07-01'
GROUP BY team, feature, model
ORDER BY total_cost DESC

From this you can produce three outputs:

Showback. A monthly report per team: "You spent $4,230 on LLMs. $2,100 was support-summarize, $1,400 was agent-research, $730 was eval-suite." No money changes hands, but teams see their footprint. This is the right first step.

Chargeback. The same numbers, but finance actually deducts budget from each team. This requires trust in the data and agreement on allocation rules. Do not start here.

Customer billing. For multi-tenant products: per-tenant usage × your pricing model (per-token, per-request, or subscription overage). This needs the most accurate metering because customers dispute invoices.

Common mistakes

Counting cache-read tokens as savings. A cache-read token costs less than a full input token, but it is not free. The savings are the difference between what you would have paid and what you paid, not the full cache-read volume.

Ignoring retries. A request that retries three times costs 3x the tokens. If your metering only records successful requests, you under-report cost by 10-30% for unreliable endpoints.

Daily aggregates only. Daily totals hide spikes. A single runaway agent loop can burn $500 in an hour and vanish into the daily average. Keep per-request records for at least 30 days, aggregate for reporting.

No reconciliation. Your internal metering will not match provider invoices exactly. Reconcile monthly: internal total vs invoice total. If the gap is >5%, find out why. Common causes: unlogged providers, timestamp skew, or retries counted differently.

Minimum viable setup

You can have showback running in a week:

1. Instrument one service with OpenTelemetry. Emit one span per LLM request with provider, model, input_tokens, output_tokens, feature, team.
2. Ship spans to ClickHouse or BigQuery. A simple table with the fields above is enough.
3. Write a daily aggregation query. Run it as a scheduled job.
4. Publish a monthly report. Email it to team leads.

Do not build a custom dashboard before you have the data flowing. A CSV export emailed monthly is better than a beautiful dashboard with no data.

Related

• AI chargeback and showback - moving cost to owners once you trust the numbers.
• LLM cost attribution - the broader attribution framework.
• Prompt caching explained - why cache-read tokens need separate accounting.
• Agent spend guardrails - preventing runaway spend once you can meter it.

Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →

Back to research