AI metering measures how much AI your application consumes and who consumed it. It captures units such as input tokens, output tokens, tool calls, and audio seconds, then aggregates them by customer, feature, or workflow. Those measurements support AI cost tracking, usage allowances, and usage-based billing.
What is AI metering?
AI metering is the collection and aggregation of usage events from AI workloads. Each event answers four questions: what resource was used, how much was consumed, when it happened, and which customer or workload it belongs to.
For a simple chatbot, LLM metering might record input and output tokens for each response. For an AI agent, the same customer request can include several model calls, paid searches, and MCP tool invocations. A useful meter preserves those individual events while linking them to one execution.
Teams searching for AI usage metering, LLM token metering, or AI consumption tracking often share the same practical problem: a provider total does not explain which customers and features generated the usage.
What should you meter in an AI application?
Choose units that match actual consumption. Keep incompatible units separate; adding tokens to audio seconds does not produce a meaningful usage total.
| Resource | Usage to capture | Why it matters |
|---|---|---|
| LLM inference | Input, output, and cache-related token categories; provider and model | Different categories can have different rates |
| Agent and MCP tools | Tool identity, invocation count, direct fee, execution ID | Token counts miss paid tools and multi-step work |
| Voice AI | Audio units and connected telephony duration | Speech and carrier consumption may be billed separately |
| Images and other media | Count, size, quality, duration, or provider-specific unit | A request count alone may not explain cost |
| Product outcomes | Reports generated, tickets resolved, or completed workflows | Connects resource consumption to the unit customers value |
Record failures and retries too. An unsuccessful customer request can still incur provider charges. For agent-specific attribution, see our MCP cost tracking guide; for audio workloads, see voice AI unit economics.
AI metering vs. cost tracking vs. usage-based billing
Choosing a customer-facing unit? Read AI Usage-Based Billing: Tokens, Credits, or Outcomes? for a comparison of pricing models and worked billing examples.
These functions share data but answer different questions. Metering asks how much was consumed. Cost tracking applies your supplier rates. Customer billing applies your selling prices and contract terms.
- Metering: this tenant consumed 2 million input tokens and 400,000 output tokens.
- Cost tracking: those units cost your business a calculated amount under the applicable provider rates.
- Billing: the tenant owes a charge under its subscription, credits, or usage pricing agreement.
You can meter tokens internally while charging customers per report. You can also meter every request while offering a flat monthly subscription. The important link is between the customer-facing unit and its actual cost-to-serve.
A token meter alone does not provide an invoicing system. For an example of usage aggregation, OpenMeter’s metering documentation describes summing token quantities from usage events. Billing adds the commercial rules on top of those measurements.
How to implement AI metering
1. Define customer and execution boundaries
Choose a stable internal tenant ID and generate an execution ID for each user task. Pass both through asynchronous jobs, model calls, and tools. Keep production and test usage separate. Prefer internal IDs over customer emails or prompt contents.
2. Capture actual consumption at each call
Use provider-reported usage when available. An estimate from the user’s prompt can miss system instructions, retrieved context, output, and reasoning work. For streaming requests, collect the final usage information when provided; if a connection ends before usage arrives, mark it incomplete and reconcile it later.
3. Normalize without losing provider details
Preserve provider, model, timestamp, raw unit categories, status, and application context. Providers may report cached or reasoning tokens differently. Make categories mutually exclusive before pricing them so cached tokens are not charged twice. Store the original usage details for investigation.
4. Make event delivery retry-safe
Assign a stable event ID before delivery and deduplicate repeated submissions. A retry of telemetry delivery should keep the same event ID; a new model attempt should receive a new event ID because it may consume additional resources. Buffer events durably when losing usage would affect invoices.
5. Apply versioned rates
Keep measured quantities separate from prices. Resolve rates using the provider, model, usage category, contract, and effective date. Preserve an explicit unpriced state when a rate is missing. Unknown cost is not zero cost.
6. Aggregate and reconcile
Sum each usage unit by tenant and billing window, with a documented timezone and policy for late events. Compare calculated supplier costs with provider usage exports or invoices. Investigate differences from missing events, credits, rounding, or rate changes before relying on totals for customer billing.
7. Connect measurements to decisions
Use customer and feature totals to identify expensive workflows, review allowances, or investigate retries. If you need hard quotas, design a separate enforcement path that accounts for concurrent requests and in-flight usage; a delayed analytics total cannot guarantee a spending cap.
AI token metering: a worked cost example
Assume one customer generates 1,000 reports in a month. Across all attempts, including retries, the meter records the following consumption. These are illustrative rates, not a provider price quote. Token categories here do not overlap.
| Metered usage | Example supplier rate | Cost |
|---|---|---|
| 2,000,000 uncached input tokens | $2 per million | $4.00 |
| 500,000 cache-read tokens | $0.50 per million | $0.25 |
| 400,000 output tokens | $8 per million | $3.20 |
| 1,000 paid tool calls | $0.005 per call | $5.00 |
| Total measured AI cost | $12.45 |
$12.45 ÷ 1,000 = $0.01245
If each completed report earns $0.05, revenue is $50 and the amount remaining after these measured AI costs is $37.55, or 75.1% of revenue. That is not fully loaded gross margin: hosting, support, payment fees, and other relevant delivery costs still need to be included.
This example shows why counting only tokens can mislead pricing decisions. The tool calls contribute $5 of the $12.45 measured cost. It also shows why cost per successful outcome should include the consumption of unsuccessful attempts in the same cohort.
How to choose AI metering software
Start with your decision: internal cost visibility, customer billing, or real-time usage enforcement. Evaluate the capabilities required for that decision with a representative workflow.
- Coverage: can it capture your models, tools, and non-token usage?
- Attribution: can you inspect usage by customer, feature, and execution?
- Correctness: how does it handle duplicate delivery, delayed events, missing usage, and corrections?
- Pricing: can it distinguish contract rates, catalog rates, and customer selling prices?
- Reconciliation: can you trace an aggregate back to its underlying events?
- Integration: how will measured usage reach your billing or entitlement system?
A useful evaluation includes a successful call, a charged failure, a retry, a cached request, and a paid tool call. Verify the totals and customer attribution before expanding instrumentation.
Start tracking AI usage and customer costs with Ganivra
Ganivra connects model and MCP consumption to customers, features, workflows, and executions. Its telemetry API accepts token usage and additional usage details, and resolves costs from provider-reported amounts, workspace contract rates, or its versioned catalog.
Start with one workflow: attach customer and execution identifiers, send model and tool events, and inspect the resulting cost breakdown. The Ganivra integration guide covers the event contract and SDK setup. Use the resulting attribution to understand the cost behind your pricing; customer invoicing and real-time enforcement require their own billing and application logic.
Frequently asked questions about AI metering
What is AI metering?
AI metering records and aggregates the resources an AI application consumes, such as tokens, model requests, tool calls, images, or audio seconds. Attaching customer and workflow identifiers makes that usage useful for cost attribution, allowances, and billing.
How is AI metering different from AI billing?
Metering measures usage. Rating applies a price to that usage. Billing applies the customer contract, allowances, credits, and adjustments to produce a charge. Your provider cost and your customer selling price are separate rates.
Is counting tokens enough for AI usage metering?
Only when tokens cover all the resources you need to measure. Agents may also consume paid tools, retrieval, audio, or infrastructure. Track those units separately and connect them to the same execution.
How do you track AI usage by customer?
Attach a stable internal customer or tenant ID to each usage event at the application boundary. Preserve it across model calls, tool calls, retries, and background jobs, then aggregate usage by customer and time period.
Can AI metering support flat-rate subscriptions?
Yes. Metering shows the cost of serving each subscriber even when the customer pays a fixed amount. That data can inform included allowances, overage policies, and feature pricing.
Put AI usage in context
See what each customer and workflow costs.
Connect AI consumption to the product decisions behind your unit economics.