LLM cost tracking and attribution

Know which customer, feature and workload burned the AI spend

Record tokens or the per-call cost your application already computes, route it through the customer subscription and meter/product-item keys that identify the usage stream, and keep the evidence outside provider dashboards.

What you get
  • Attribute usage to customer subscriptions and explicit meter/product-item streams
  • Meter tokens, tasks or a cost value your application already computes
  • Keep retries from double-counting the same logical usage event
  • Retain raw events behind the monthly rollup for reconciliation

Attribute at write time

Each customer subscription has its own ingest key, and explicit product-item and meter keys identify the usage stream when there is more than one. A provider total cannot reconstruct customer routing that was never recorded.

Track usage or computed cost

Use token quantities when tokens are the stable signal. If your application already calculates a per-call or per-task cost, meter that numeric value instead and aggregate it independently.

Separate provider spend from customer usage

Provider invoices answer what the vendor charged you. Your own usage stream can answer which customer subscription and configured meter produced the quantity you later reconcile.

Make retries attribution-safe

Generate one idempotency key for each logical usage event and reuse that key only when retrying the same event. Delivery retries should not inflate customer or workload totals.

Keep model migrations explicit

If model or workload separation matters, route those calls to distinct meters or product items. Your application still sends the same usage request shape; only the ingest key changes.

Reconcile from raw evidence

Monthly totals are useful for reporting. Raw accepted events are what you need when a cost spike, customer dispute or routing change has to be explained later.

Implementation pattern

One cost event stays tied to one customer usage stream

The customer subscription, product item and meter are explicit ingest keys. The numeric value can be tokens or a cost value your application computed before sending the event.

If you retry this same logical event, reuse its original idempotency key rather than generating a new one.

curl -X POST 'https://api.usagebox.com/api/v1/usage' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '[{"subscription":"sub_customer-acme-...","product_item":"item_ai-assistant-...","meter":"meter_task-cost-...","value":0.0184}]'

Product boundary

UsageBox does not maintain model price tables for you

UsageBox records the numeric usage or cost values your application sends. Provider prices, cache discounts, negotiated rates and customer pricing remain separate so a changing price table cannot rewrite the historical usage record.

Track here

  • Tokens or computed cost
  • Customer subscriptions
  • Meter/product-item usage streams
  • Raw usage evidence
  • Monthly rollups

Calculate elsewhere

  • Provider list prices
  • Negotiated discounts
  • Cache pricing rules
  • Customer markup
  • Invoices and payments

See the request before you create an account

Choose the usage signal, inspect the exact payload, then create a free key only when the contract fits your integration.