Monitor LLM Token Usage and Cost by User or Feature

Updated 8 November 2026 · Standard formula, shown below

Monitoring LLM token usage and cost by user or feature shows which people, teams, or product functions drive model consumption. You will need access to your application’s model calls and a place to store usage records; with consistent identifiers, you can build reports, set budgets, and investigate unexpected spend.

What You’ll Need

Access to the code or service that sends requests to your language model provider, or to an existing gateway or observability platform.
A reliable user identifier and a feature name for each request. Use internal IDs rather than email addresses or other personal data where possible.
A database, analytics warehouse, or monitoring system to store request-level records and summarize them.
Current model pricing information for each model and any separate input, output, cached-token, or other billable categories.
Permission to review provider usage reports and your organization’s data-retention and privacy requirements.

Step-by-Step

Choose the dimensions you need to report. Decide whether you need cost by individual user, team, feature, model, environment, or some combination. Define feature names in advance—for example, summarize_document or draft_reply—and keep the list stable. Avoid relying on free-text labels that vary between calls.
Assign identifiers where requests enter your application. At the point a user starts an LLM-powered action, attach an internal user ID and a feature ID to the request context. If a request runs without a signed-in user, record an explicit value such as system or anonymous. Do not infer a user from a prompt or log personal information unnecessarily.
Capture usage returned by the provider. After each completed model call, read the provider’s usage fields, such as input and output tokens. Capture cached or reasoning-token counts separately if the provider reports them and they affect billing. Field names and definitions differ by provider and API; use that provider’s documentation. Do not estimate token counts from character length when actual usage is available.
Record one event per billable call. Store a unique request or operation ID, timestamp, user ID, feature ID, model identifier, token counts by category, and status. Include the provider’s returned cost if available, or preserve the counts and model data needed to calculate it later. Record retries as separate calls, linked to the original operation, so their usage is not hidden.
Calculate cost using the correct rate card. For each model and billing category, multiply the token count by the applicable price per token, converting from a per-million-token rate when necessary. Add the categories together. Keep rates versioned with effective dates, since prices and billing rules can change. If provider-reported costs are available, compare them with your calculation rather than assuming the two methods use identical rules.
Validate the data against provider reports. Compare totals for the same time period, models, and account. Account for differences such as time zones, delayed reporting, cached tokens, failed requests, batch processing, or other billable services. A mismatch is a prompt to investigate definitions and coverage, not a reason to adjust records until they appear to agree.
Build useful views and alerts. Create daily and monthly totals grouped by user and feature, with filters for model, date range, and environment. Show both token counts and cost, and display unknown or unassigned identifiers separately. Alert on unusual increases or configurable budget thresholds; make clear whether alerts are based on estimates or reconciled provider charges.
Test the full path before relying on reports. Send a small number of test requests through each feature, including a failed request and a retry if those occur in production. Confirm that each event has the right user and feature, usage is recorded once per actual call, and the report groups the totals correctly. Then document how teams should name new features and who maintains model pricing.

Common Mistakes

Using the wrong token count: Input and output tokens may have different prices. Treating total tokens as one category can misstate cost.
Counting application actions instead of model calls: One user action may trigger multiple calls, while retries may incur additional usage. Track each provider call and link related calls together.
Mixing model or pricing versions: A model name alone may not fully identify the applicable rate or billing behavior. Preserve the model identifier and rate version used for each cost calculation.
Leaving attribution until reporting: If the user or feature context is lost before the call is logged, it may be impossible to assign usage accurately later.
Assuming dashboards equal invoices: Internal estimates and provider billing reports may use different timing, adjustments, or billable categories. Label estimates and reconcile them regularly.
Logging sensitive content: Token accounting usually needs IDs, counts, and metadata—not full prompts or responses. Avoid retaining content unless there is a clear, approved need.

Tips

Use a shared request context so user, feature, environment, and trace identifiers follow calls through queues and background jobs.
Keep a stable feature taxonomy and add a catch-all for missing attribution. Review that catch-all often; it can expose instrumentation gaps.
Store raw usage events as well as daily summaries. Raw events make it possible to correct calculations or investigate a spike without losing detail.
Separate development, staging, and production usage so experiments do not obscure customer-facing trends.
Set budgets at the level teams can act on, and notify the responsible owner with enough context to investigate the increase.
Restrict access to user-level reports and choose retention periods appropriate to operational needs and applicable organizational policies.

Troubleshooting

Usage appears as zero or is missing: Check whether the API response includes usage for the request type you are using, and whether your code saves it after successful calls. Some streaming integrations need to collect a final usage event or enable a provider-supported usage option. Confirm that failed calls and asynchronous jobs are handled deliberately.

Costs differ from the provider dashboard: Align the date range and time zone, then compare by model and token category. Check for delayed provider reporting, cached-token treatment, retries, batch requests, and any billable features outside the token totals. Verify the rate and its effective date.

Events have no user or feature: Trace the request from the user action to the model call. Background workers often need identifiers passed explicitly in the job payload. Add validation or a visible “unassigned” group rather than silently dropping those events.

Totals are duplicated: Look for logging both in a shared client and in a feature-specific wrapper, or for retry middleware that records the same response more than once. Use a unique call ID and make event ingestion idempotent where possible.

A cost spike has no obvious cause: Break the interval down by model, feature, user, and call count. Check for a deployment, changed prompt or output limits, loops, increased retries, or a shift to a more expensive model. Fix the source first, then verify the next reporting interval.

Frequently Asked Questions

Can I track cost by user if the provider does not support user-level billing?
Yes. Record your own user ID with each request and calculate or report usage internally. The provider’s account-level bill remains the source for billed totals.

Should I store prompts and responses to measure tokens?
Usually not. Prefer usage metadata returned by the provider. Store content only when there is a separate, justified need and an approved handling policy.

How should I handle requests that use several models?
Record each model call as its own event, with the same parent operation ID. Summing the linked calls gives the total cost of the user-facing action.

How often should I reconcile costs?
Check regularly—often daily for operational monitoring—and compare billing totals on the provider’s reporting schedule. Provider data may arrive later than your application events.

What if the provider does not return token usage?
Check its documentation for usage reporting options. If you must estimate, use a compatible tokenizer for that model, label the result as an estimate, and reconcile against provider data when available.

Is token count enough to explain a cost increase?
No. Cost can also vary with model, input versus output mix, cached usage, pricing changes, and other billable categories. Track those dimensions alongside totals.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.