AI products have a hidden measurement problem.
A user clicks a button, asks a question, summarizes a document, generates a report, or runs an AI workflow. The product feels simple from the outside.
But behind that action, something measurable is happening.
The product may send a prompt to a language model. It may include conversation history, retrieved context, documents, system instructions, or customer data. The model may generate a response. That response may trigger another model call, a tool call, or a follow-up workflow.
Every one of those steps can consume tokens.
And those tokens create cost.
This is why token metering matters.
Token metering is the process of tracking how many input and output tokens are consumed by users, customers, features, models, and workflows inside an AI product.
For early prototypes, token usage may feel like a technical detail. But once real customers start using the product, token metering becomes a business requirement. It helps teams understand cost, enforce limits, design credits, monitor usage, and prepare for usage-based billing.
Without token metering, AI usage becomes difficult to explain.
You may know that your provider bill is increasing. But you may not know which customer caused it, which feature created it, or whether your pricing model can support it.
What is token metering?
Token metering is the process of measuring and recording token consumption in an AI product.
In large language models, text is processed as tokens. A token can be a word, part of a word, punctuation mark, or other text unit depending on the tokenizer used by the model.
When a user sends a request to an AI feature, the request usually consumes two types of tokens:
Input tokens
Output tokens
Input tokens are the tokens sent into the model. These can include the user prompt, system prompt, conversation history, retrieved context, document content, or tool instructions.
Output tokens are the tokens generated by the model in response.
For example, if a user asks an AI assistant to summarize a document, the usage may look like this:
Input tokens: 4,200
Output tokens: 650
Total tokens: 4,850
A token metering system records this usage and connects it to the right customer, user, feature, model, provider, and timestamp.
That data can then be used for dashboards, cost attribution, quotas, credits, billing, and margin analysis.
Token metering is one part of AI usage metering. AI usage metering can include many kinds of usage, such as API calls, credits, images generated, documents processed, minutes transcribed, or agent runs. Token metering focuses specifically on LLM token consumption.
Why token metering matters for AI products
Token metering matters because LLM usage has a direct cost.
In traditional SaaS, product usage does not always map directly to a unit cost. A customer can log in, create projects, invite team members, or use features without creating a large incremental cost every time.
AI products are different.
Every model request can create provider cost or infrastructure cost. That cost may vary depending on:
Model used
Input length
Output length
Context window size
Number of model calls
Provider pricing
Workflow complexity
Use of retries or fallback models
This means two customers on the same plan can have completely different cost profiles.
One customer may use a few short AI replies per month. Another may upload long documents, generate large reports, and run multi-step workflows every day.
If both customers pay the same subscription fee, but one consumes far more tokens, the business may lose margin without realizing it.
Token metering helps AI teams answer questions like:
- Which customers consume the most tokens?
- Which features generate the highest token usage?
- Which models are most expensive in practice?
- Are free trial users creating too much cost?
- Which plan limits are being reached?
- Should usage be priced with tokens, credits, or quotas?
Without token metering, these questions become guesswork.
Token metering by customer
The most important rule in token metering is simple:
Token usage should be tied to the customer who caused it.
It is not enough to know that your product used 50 million tokens this month. You need to know which customers, workspaces, teams, or tenants created that usage.
For a B2B AI product, customer-level token tracking is essential because billing and profitability usually happen at the account level.
For example:
| Customer A | Customer B |
| Monthly revenue: $99 Token cost: $8 | Monthly revenue: $99 Token cost: $120 |
Both customers may look the same in a subscription billing system. But from a margin perspective, they are very different.
Customer B may be a great customer if pricing and packaging are designed properly. But if the product offers unlimited usage or poorly designed credits, that customer may become unprofitable.
This is why token usage should be connected to:
Customer ID
Workspace ID
Tenant ID
Subscription plan
Billing status
Usage quota
Credit balance
For AI SaaS teams, customer-level token metering is the bridge between technical usage and business decisions.
Token metering by user and workspace
In many AI products, a single customer account has multiple users.
For example, a company may have 50 employees using the same AI support tool, research assistant, document automation platform, or sales AI product.
If token usage is only tracked at the customer level, the product team may know which account is consuming tokens, but not which users or teams are driving that usage.
User-level and workspace-level token metering can help answer questions like:
- Which users are consuming the most AI?
- Which team inside the customer account is driving cost?
- Is one user accidentally triggering expensive workflows?
- Should admins see usage by team or department?
- Should usage limits apply per user, workspace, or customer?
This is especially useful when customers ask for usage reports.
A customer may not just want to know:
Your company used 500,000 tokens this month.
They may want to know:
Sales team: 220,000 tokens
Support team: 180,000 tokens
Operations team: 100,000 tokens
This level of visibility makes usage dashboards more useful and helps customers understand how AI is being consumed inside their organization.
Token metering by feature
Token metering should also track which product feature created the usage.
This is one of the most useful views for product and engineering teams.
For example, an AI product may have several features:
- AI chat assistant
- Document summarization
- AI report generation
- Customer support reply drafting
- Data extraction
- Agent workflow automation
Each feature may have a different token profile.
A chat assistant may create many small requests. A document summarization feature may create fewer but much larger requests. A report generation feature may have high output token usage. An agent workflow may trigger multiple model calls behind one user action.
If token usage is tracked by feature, the team can see which parts of the product are expensive to operate.
Example:
Document summarization: 42% of token usage
AI chat assistant: 25% of token usage
Report generation: 21% of token usage
Agent workflows: 12% of token usage
This helps teams decide:
- Which features need usage limits?
- Which features should consume more credits?
- Which workflows should use cheaper models?
- Which features are valuable but expensive?
- Which features are hurting margin?
Feature-level token metering is also useful for pricing.
If one feature costs much more to operate than another, both should not necessarily consume the same number of credits.
This is where credit-based pricing becomes important. Credits can simplify pricing for customers, while token metering helps the company understand the real cost behind those credits.
Token metering by model and provider
Many AI products use more than one model or provider.
A product may use one model for chat, another for summarization, another for classification, and another for fallback. It may also use different providers depending on customer requirements, cost, latency, or performance.
For example:
OpenAI for high-quality generation
Anthropic for long-context reasoning
Azure OpenAI for enterprise customers
Open-source models for lower-cost workflows
Embedding models for retrieval
Token metering should track the model and provider used for each request.
This helps answer questions like:
- Which provider is driving most of our cost?
- Which model is used most often?
- Which model has the highest cost per customer?
- Are expensive models being used for low-value tasks?
- Can some workflows move to cheaper models?
Without model-level token tracking, teams may only see total provider spend. That is not enough.
A good token metering system should capture fields like:
provider
model
input_tokens
output_tokens
estimated_cost
request_type
feature
customer_id
This creates a clear picture of how model usage maps to customer behavior and product cost.
Input tokens vs output tokens
Token metering should separate input tokens and output tokens.
Total tokens are useful, but they are not enough.
Input and output tokens often have different cost structures. Many model providers price them differently, and some workflows are more input-heavy while others are more output-heavy.
For example:
Document analysis:
High input tokens
Lower output tokens
Report generation:
Moderate input tokens
High output tokens
Chat assistant:
Input and output both vary with conversation history
If a product only tracks total tokens, it may miss important cost patterns.
A feature that sends very large documents to a model has a different cost profile from a feature that generates long reports. Both may have high total token usage, but the reason for that usage is different.
Separating input and output tokens helps teams optimize prompts, context size, response length, and model selection.
It also helps with pricing design.
If output tokens are more expensive, long-form generation features may need different limits or credit costs than short-response features.
What should a token usage event include?
A token usage event is a structured record of token consumption.
A simple event may look like this:
{
"event_type": "llm_request_completed",
"customer_id": "cus_123",
"user_id": "user_456",
"workspace_id": "workspace_789",
"feature": "document_summary",
"provider": "openai",
"model": "gpt-4.1",
"input_tokens": 4200,
"output_tokens": 650,
"total_tokens": 4850,
"estimated_cost_usd": 0.036,
"billable": true,
"timestamp": "2026-07-09T10:30:00Z"
}
The exact fields depend on the product, but a good token metering event should usually include:
- Customer identifier
- User identifier
- Workspace or tenant identifier
- Feature or workflow name
- Provider
- Model
- Input tokens
- Output tokens
- Total tokens
- Estimated cost
- Billable status
- Timestamp
- Environment
- Request ID or idempotency key
The request ID or idempotency key is especially important for avoiding duplicate counting when requests are retried.
Raw token usage vs billable token usage
Not all token usage should be billable.
This is an important distinction.
A product may generate token usage from:
Customer actions
Internal testing
Demos
Admin workflows
Failed requests
Retried requests
Free trial users
Promotional credits
Background jobs
System evaluations
Some of this usage should count toward customer billing. Some should not.
This is why AI teams should separate:
Raw usage
Metered usage
Billable usage
Invoiced usage
Raw usage is every model call or token-consuming event.
Metered usage is usage that has been captured and attributed to the correct customer, user, feature, or workflow.
Billable usage is the portion of usage that should count toward credits, quotas, or invoices.
Invoiced usage is the final usage that appears in a billing system after adjustments, discounts, exclusions, or credits.
This distinction matters because billing directly from raw logs can create mistakes.
For example, if a failed request is retried three times, should the customer be charged for all attempts or only the successful final result?
The answer depends on the product and billing policy. But the metering system needs enough data to make that decision.
This is why usage-based billing should be built on a reliable metering layer, not just raw provider data.
Token metering and credit-based pricing
Many AI products do not show token usage directly to customers.
Instead, they use credits.
This is often a good decision.
Most business users do not want to think about input tokens, output tokens, provider pricing, or model-specific cost. They want a simpler usage unit.
For example:
You have 10,000 AI credits this month.
Different actions may consume different numbers of credits:
Short AI reply: 5 credits
Document summary: 50 credits
Long report generation: 200 credits
AI workflow run: 500 credits
Behind the scenes, token metering helps calculate how those credits should work.
A product team may decide credit costs based on:
Average token usage
Model cost
Feature complexity
Customer value
Desired gross margin
Plan type
This is why credits and tokens are not opposites.
Tokens are often the internal measurement unit. Credits are often the customer-facing packaging unit.
Good credit-based pricing usually depends on reliable token metering underneath.
Token metering and quotas
Token metering also supports quotas and limits.
A quota defines how much usage is included in a plan.
For example:
Starter plan: 100,000 tokens/month
Pro plan: 1 million tokens/month
Business plan: 10 million tokens/month
Or, if the product uses credits:
Starter plan: 2,000 credits/month
Pro plan: 20,000 credits/month
Business plan: 100,000 credits/month
Token metering helps the system know how much usage has been consumed and how much remains.
Quotas can be enforced in different ways:
Hard limits
Soft limits
Usage alerts
Overage billing
Throttling
Upgrade prompts
For early AI products, even basic quota visibility can be valuable.
It helps teams avoid unexpected provider bills, protect free trials, and design better pricing plans.
Common token metering mistakes
Many teams start token metering too late.
At first, it feels easier to rely on provider dashboards. But provider dashboards usually show total usage and spend. They do not always connect usage cleanly to your customers, features, plans, or internal workflows.
Another common mistake is tracking tokens without customer attribution.
Knowing that your product used 10 million tokens is useful. Knowing that one customer used 6 million of those tokens is much more useful.
Teams also sometimes ignore output tokens. This can create inaccurate cost analysis, especially for products that generate long reports, documents, summaries, or chat responses.
Another mistake is mixing internal usage with customer usage. Development, testing, demos, and admin actions can create real token cost. If these are not separated, customer profitability analysis becomes unreliable.
A more serious mistake is double-counting retries. If a request fails and is retried, the metering system should be clear about what gets counted and what becomes billable.
Finally, some teams jump into billing before they trust their token data. That can create customer disputes later.
If customers are charged based on usage, the underlying usage data must be accurate and explainable.
When should AI teams add token metering?
AI teams should add token metering before usage becomes difficult to reconstruct.
You do not need a perfect metering system on day one. But you should start capturing the basics early.
At minimum, track:
Customer ID
User ID
Feature
Provider
Model
Input tokens
Output tokens
Estimated cost
Timestamp
Billable status
This gives you enough history to understand usage patterns later.
Waiting too long creates problems.
If you launch pricing, credits, quotas, or overages without historical token data, you may design plans based on guesses. You may not know how much usage normal customers consume, how expensive heavy users are, or which features create the most cost.
Early token metering gives you the data needed to price with more confidence.
Token metering is not just a developer task
It is easy to think token metering belongs only to engineering.
But token metering affects several teams.
For founders, it helps answer whether the business model is sustainable.
For product teams, it shows which features drive cost and usage.
For engineering teams, it helps optimize prompts, models, and workflows.
For finance teams, it connects provider costs to customer revenue.
For customer success teams, it supports usage conversations with customers.
Token metering is technical infrastructure, but the value is business visibility.
That is why it should not be treated as an afterthought.
How MetricaOS helps
MetricaOS helps AI product teams track usage across customers, users, features, models, and providers.
For token metering, MetricaOS gives teams a clearer view of how LLM usage maps to customer behavior, product features, and cost.
Instead of relying only on provider dashboards, teams can use MetricaOS to understand:
- Which customers consume the most tokens
- Which features create the most AI cost
- Which models are driving usage
- How usage connects to credits, quotas, and billing
- Whether customers are profitable at current pricing
For AI products, token metering is not just about counting tokens. It is about understanding consumption before pricing, billing, and margins become messy.
Comments 0