MetricaOS

AI Credits vs Tokens: Which Pricing Unit Should Your AI Product Use?

· · Leave a Comment

AI products need a way to answer two very different questions:

How much AI did the customer actually use?

And:

How much of that usage should the customer pay for?

Tokens are often good at answering the first question.

Credits are often better at answering the second.

That distinction matters because AI products frequently make the mistake of treating their underlying infrastructure unit as their customer-facing pricing unit.

If your application consumes 4,800 tokens to complete a task, that does not necessarily mean your customer should see, understand, or pay for exactly 4,800 tokens.

For many AI products, the better architecture is:

Meter the underlying usage in tokens and other raw units. Convert that usage into credits according to your pricing rules.

That gives engineering teams accurate usage data while giving customers a pricing unit that is easier to understand and control.

So should your AI product price in tokens or credits?

The answer depends on what you are selling, who your customers are, and how closely your infrastructure usage maps to customer value.

What are tokens?

Tokens are units used by large language models to process text.

When an application sends text to an LLM, the text is broken into tokens. The model also generates output tokens when it responds.

A typical request might look like:

Input tokens: 4,200

Output tokens: 650

Total tokens: 4,850

Different models and providers may charge different prices for input tokens, output tokens, cached tokens, or other forms of usage.

This makes tokens extremely useful for measuring the underlying consumption of an AI system.

With token metering, an AI product can track usage by dimensions such as:

  • Customer
  • User
  • Model
  • Provider
  • Feature
  • Request
  • Workspace
  • Billing period

That data can then support cost tracking, profitability analysis, quotas, and billing.

But there is a problem.

Tokens are an infrastructure unit, not necessarily a customer-value unit.

What are AI credits?

AI credits are a customer-facing usage unit that represents a defined amount of AI consumption.

Instead of exposing raw token usage, an AI product might say:

Your plan includes 20,000 AI credits per month.

Different product actions can consume different numbers of credits.

For example:

Generate an email: 10 credits

Summarize a document: 50 credits

Analyze a report: 150 credits

Run an AI agent workflow: 500 credits

The customer sees credits.

Behind the scenes, the product may still measure tokens, requests, compute, model cost, or multiple other metrics.

This makes credit-based pricing an abstraction layer between technical consumption and customer pricing.

That abstraction can be extremely valuable for AI products.

Tokens measure infrastructure. Credits can represent product value.

This is the most important distinction.

Suppose your product has two features.

Feature A: Short AI response

Input tokens: 500

Output tokens: 200

Total tokens: 700

Feature B: Research workflow

Input tokens: 8,000

Output tokens: 3,000

Total tokens: 11,000

Charging directly by tokens would make Feature B roughly 16 times more expensive based purely on token consumption.

But perhaps Feature B creates far more customer value. It might replace 30 minutes of manual research while Feature A only rewrites a sentence.

Alternatively, Feature B might involve several model calls, data retrieval, external APIs, storage, and processing that token counts alone do not capture.

A credit system allows the company to price the product action, not just the raw LLM consumption.

For example:

Short AI response: 5 credits

Research workflow: 200 credits

The credit values can incorporate:

  • Token consumption
  • Provider cost
  • Model choice
  • Compute
  • External API cost
  • Product value
  • Desired margin
  • Pricing strategy

This is why tokens and credits should not automatically be treated as interchangeable.

Why tokens are excellent for internal metering

Even if customers never see tokens, AI companies often need to track them internally.

Token data helps answer questions such as:

  • Which customer is generating the most LLM usage?
  • Which model is responsible for most of our spend?
  • Are output tokens increasing?
  • Which features consume the most tokens?
  • What does a particular workflow actually cost us?

A structured AI usage metering system might record:

Customer ID: cus_123

Provider: provider_a

Model: model_x

Feature: document_summary

Input tokens: 4,200

Output tokens: 650

Total tokens: 4,850

Estimated cost: $0.036

This raw usage layer gives teams the precision needed to understand what is happening inside the product.

It also provides the foundation for LLM cost tracking and customer-level profitability analysis.

Without accurate raw usage data, a credit system can become little more than guesswork.

Why exposing tokens to customers can create problems

Token pricing can work well for technical audiences, particularly developers who already understand LLM APIs.

But for many SaaS customers, tokens are difficult to interpret.

Consider a pricing page that says:

Pro plan

5 million tokens per month

A potential customer may immediately wonder:

  • How many documents is that?
  • How many reports can I generate?
  • How many conversations does that give my team?
  • Will one large PDF use half of my allowance?

The number is technically precise but commercially unclear.

Compare that with:

Pro plan

20,000 AI credits per month

If the product also explains that:

Email generation: around 10 credits

Document summary: around 50 credits

Research report: around 200 credits

the customer can connect usage to product actions much more easily.

Credits allow the company to translate infrastructure complexity into something closer to the way customers experience the product.

The strongest architecture often uses both

The tokens-versus-credits decision does not need to be either/or.

For many AI products, the strongest approach is:

Raw usage

↓

Metered usage

↓

Cost calculation

↓

Credit conversion

↓

Customer wallet or allowance

↓

Billing

The product measures the technical reality first.

Then a pricing layer determines how that usage should translate into customer consumption.

For example:

Usage event

Input tokens: 4,200

Output tokens: 650

Provider: Provider A

Model: Model X

Customer: cus_123

The pricing engine might then evaluate a rule:

If:

Provider = Provider A

Model = Model X

Event type = completion

Then:

Calculate underlying model cost

Apply pricing/margin rule

Convert usage into credits

Deduct credits from customer balance

This separation is important.

Metering describes what happened. Pricing decides what that event is worth commercially.

Not every credit needs to equal a fixed number of tokens

One tempting approach is:

1 credit = 1,000 tokens

That is simple, but it can become restrictive.

Different models may have dramatically different costs. Input and output tokens may be priced differently. Image generation, transcription, embeddings, agents, and external tools may not fit naturally into a token-only system.

Instead, credits can be calculated differently depending on the event.

For example:

Cheap model request:

1,000 tokens = 1 credit

Premium model request:

1,000 tokens = 8 credits

Image generation:

1 image = 30 credits

Agent workflow:

1 execution = 100 credits

The customer still interacts with one consistent currency: credits.

Internally, the product can meter completely different underlying usage types.

This makes credits particularly useful for products that combine several AI providers, models, and modalities.

Credits also make provider changes easier

Imagine your product prices directly in tokens.

You initially use Model A.

Six months later, you move one workflow to Model B because it provides better quality or lower cost.

The customer may now consume a completely different number of tokens for the same product outcome.

If your pricing is tightly coupled to token usage, changes to your AI stack can unexpectedly change what customers pay.

Credits introduce a buffer between infrastructure and pricing.

Your customer can still pay:

Document analysis: 50 credits

while the implementation behind that feature changes.

This allows the engineering team to optimize providers and models without constantly redesigning the customer-facing pricing model.

Credits are not automatically better

Credits also create their own problems.

The biggest one is opacity.

If customers cannot understand how credits are consumed, the pricing system can feel arbitrary.

A customer who sees:

You used 3,800 credits today.

may reasonably ask:

On what?

A good credit system therefore needs visibility.

Customers should be able to understand:

  • Current credit balance
  • Credits consumed
  • Usage history
  • Which actions consumed credits
  • When credits reset
  • Whether unused credits roll over
  • What happens when the balance reaches zero
  • Whether overages are allowed

The credit abstraction should simplify pricing, not hide it.

Credits need a reliable wallet and ledger

Once credits become part of your pricing model, they should be treated as a real accounting unit inside the product.

A customer may receive credits through:

  • Subscription allowances
  • Purchases
  • Promotions
  • Adjustments
  • Refunds

And credits may be consumed through different product events.

A reliable system should maintain an immutable transaction history rather than simply updating a balance.

For example:

+20,000   Monthly subscription allocation

-50       Document summary

-200      Research workflow

-10       Email generation

+500      Promotional credit

The resulting balance can then be reproduced from the underlying transactions.

This is especially important when credits are connected to invoices, customer disputes, usage limits, or enterprise contracts.

Credits and subscription plans

Credits work particularly well with hybrid subscription models.

For example:

StarterProBusiness
$49/month$199/month$599/month
5,000 credits included25,000 credits included100,000 credits included

The company then needs to decide what happens when customers approach or exhaust their allowance.

Possible policies include:

  • Hard stop
  • Upgrade required
  • Purchase additional credits
  • Automatic overage
  • Soft limit with alerts
  • Temporary grace usage

This is where usage quotas become important.

A pricing model is not complete merely because the company defines the number of included credits. It also needs clear enforcement behavior.

Should unused credits roll over?

This is another product decision that token pricing alone does not solve.

Suppose a customer receives:

20,000 credits per month

and uses only 12,000.

Should the remaining 8,000 disappear?

Or should they carry forward?

Both approaches can work.

No rollover creates predictable monthly allowances and limits accumulated liability.

Rollover credits can make customers feel that they are receiving more value and may work especially well when usage is irregular.

The important point is that the policy should be intentional and visible.

What about overages?

Credits can also support usage-based billing.

For example:

Pro plan: $199/month

Included:

25,000 credits

Additional usage:

$10 per 5,000 credits

This creates a hybrid model:

Subscription + included usage + overage

The base subscription provides predictable recurring revenue.

Credits define the included consumption.

Overages allow revenue to increase with unusually heavy usage.

For AI products with variable infrastructure costs, this can be substantially safer than unlimited usage.

Tokens can still be the better customer-facing unit

There are cases where customers should see tokens.

This is especially true for developer infrastructure products.

If your users are developers building directly on top of APIs or models, they may already think in terms of:

  • Input tokens
  • Output tokens
  • Cached tokens
  • Requests
  • Model rates

In that situation, hiding everything behind credits may actually make the pricing less transparent.

A developer platform may be better served by something like:

Input tokens: $X per million

Output tokens: $Y per million

The rule of thumb is simple:

If your customers think about the infrastructure, tokens may make sense.

If your customers think about product outcomes, credits are often easier.

How to decide between credits and tokens

Consider four questions.

1. Who is your customer?

Technical infrastructure buyer?

Tokens may be perfectly understandable.

Business user?

Credits or product-specific units may be clearer.

2. Does token usage closely represent customer value?

If more tokens consistently mean more customer value, token pricing may work.

If token consumption varies dramatically for similar outcomes, credits provide more control.

3. Does your product use multiple models or usage types?

If your product combines LLM tokens, image generation, transcription, workflows, APIs, and compute, one credit currency can simplify the experience.

4. Do you want pricing independent from your AI infrastructure?

If you expect to change providers, models, routing, or workflows frequently, credits create useful separation between your technical architecture and commercial model.

The margin question matters more than the unit

Ultimately, neither credits nor tokens solve pricing by themselves.

A company can sell credits and still lose money.

A company can price directly in tokens and still build a profitable product.

The important question is:

Does the amount customers pay increase appropriately as the cost and value of their usage increase?

That requires understanding cost per customer and accurately attributing costs to the customers and features responsible for creating them.

Our guide to AI Cost Attribution explains how to connect model spend to those product dimensions.

Once you understand customer-level usage and cost, you can decide how aggressively credits should be consumed, how large plan allowances should be, and when overages become necessary.

How MetricaOS connects tokens, credits, and billing

MetricaOS separates usage measurement from monetization.

AI teams can ingest structured usage events containing metrics such as input tokens, output tokens, cached tokens, total tokens, latency, cost, provider, model, customer, user, and other product context.

Teams can then define credit rules that determine which usage metrics should consume credits and under what conditions.

Provider pricing and margin rules can be used alongside those events, while customer wallets track balances and credit transactions.

Subscription plans can define:

  • Credits included per billing period
  • Billing cycle
  • Hard credit limits
  • Credit rollover
  • Overage behavior

This allows an AI company to keep the technical layer accurate while building a customer-facing pricing model around credits.

The result is a clearer separation:

Tokens tell you what was consumed.

Costs tell you what that consumption cost you.

Credits tell the customer how much priced usage they consumed.

Billing determines what they ultimately owe.

That separation is one of the foundations of sustainable AI monetization.

Credits vs tokens: the practical answer

If you are building an AI infrastructure product for developers, exposing tokens may be the simplest and most transparent option.

If you are building an AI SaaS product around customer workflows and outcomes, credits are often easier for customers to understand and give the business more flexibility.

But in many cases, the best answer is:

Use tokens internally. Use credits externally.

Measure the real underlying consumption with precision.

Then translate that consumption into a pricing unit designed around your customers, your product, and your margins.

Because your billing unit does not have to be the same as your infrastructure unit.

AI Cost Attribution

· · Leave a Comment

What is AI cost attribution?

AI cost attribution is the process of assigning AI-related costs to the customers, users, features, models, or workflows responsible for generating them.

An AI company may know that it spent $10,000 on model providers during a month. Cost attribution explains where that $10,000 came from.

For example:

Customer A: $1,800

Customer B: $420

Customer C: $95

Document analysis: $4,200

AI assistant: $3,100

Report generation: $2,700

Instead of seeing only total provider spend, the company can understand which parts of the product are creating cost.

AI usage metering provides the underlying usage data needed to make this attribution possible.

Why AI cost attribution matters

AI products often have variable costs. Every model request, document analysis, generated response, agent action, or AI workflow can increase the cost of serving a customer.

Two customers paying the same subscription price may therefore have completely different economics.

For example:

Customer A

Revenue: $199/month

AI cost: $24/month

Customer B

Revenue: $199/month

AI cost: $260/month

Without customer-level attribution, both accounts appear to generate the same revenue.

With attribution, it becomes clear that Customer B may be unprofitable.

Cost per customer helps teams measure this relationship between customer usage, cost, and revenue more directly.

What can AI costs be attributed to?

Most AI products should attribute costs across several dimensions.

Customer

Customer-level attribution shows how much each account costs to serve.

This can reveal heavy users, unprofitable accounts, and customers that may need higher plans, overages, or enterprise pricing.

Feature

Feature-level attribution shows which parts of the product create the most AI spend.

For example:

Document summaries: $2,100

AI search: $1,400

Agent workflows: $5,800

Email generation: $700

This helps product teams understand whether expensive features are delivering enough value to justify their cost.

Model and provider

Different models can have very different cost structures.

Model-level attribution helps teams identify whether expensive models are being used where cheaper alternatives could perform adequately.

User or workspace

For B2B products, costs may also need to be attributed to individual users, teams, projects, or workspaces.

This is particularly useful for enterprise usage reporting and departmental usage controls.

Workflow

Some AI features make several model or tool calls behind the scenes.

Workflow-level attribution combines these related costs so teams can understand what a complete product action actually costs.

How does AI cost attribution work?

AI cost attribution starts when the product records a usage event.

A simplified event might contain:

Customer: cus_123

Feature: document_analysis

Model: premium_model

Input tokens: 4,200

Output tokens: 650

Estimated cost: $0.036

The usage data explains what happened.

The customer and feature identifiers explain where the cost belongs.

The estimated cost explains the financial impact.

Token metering is commonly used to capture the input and output token consumption behind LLM requests.

LLM cost tracking then connects that usage to the corresponding model cost.

Cost attribution adds another layer by connecting the cost to the relevant customer, feature, workspace, or workflow.

AI cost attribution vs LLM cost tracking

The terms are closely related but describe different parts of the process.

LLM cost tracking answers:

How much did our model usage cost?

AI cost attribution answers:

Who or what generated that cost?

For example:

LLM cost tracking:

Total model cost = $8,000

AI cost attribution:

Customer A = $1,200

Customer B = $600

Document analysis = $3,400

AI assistant = $2,100

Other features = $2,500

Cost tracking gives visibility into spend. Attribution gives that spend business context.

For a deeper explanation, see AI Cost Attribution: How to Know Which Customers and Features Drive Your LLM Spend.

AI cost attribution and pricing

Cost attribution becomes especially valuable when designing AI pricing.

If one feature consistently creates a large share of model spend, a company may decide to:

  • Increase its credit cost
  • Restrict it to higher plans
  • Add a usage quota
  • Charge overages
  • Use a cheaper model
  • Optimize the workflow

Usage quotas can prevent unusually heavy consumption from creating uncontrolled cost.

Usage-based billing can also allow revenue to increase when customer consumption increases.

The important distinction is that cost attribution measures what usage costs the company, while billing determines what the customer should actually pay.

Not every cost-generating event needs to be billable.

Common AI cost attribution mistakes

One common mistake is tracking only the monthly provider invoice. It tells the company total spend but not which customers or features generated it.

Another is recording tokens without customer or feature identifiers. Once that context is missing, reliably reconstructing it later can be difficult.

Teams may also rely too heavily on averages. An average customer cost of $20 can hide a small group of customers costing hundreds of dollars each.

Another mistake is mixing internal activity with customer usage. Development, testing, demos, and administrative usage should be identified separately.

Finally, cost and billable usage should not be treated as the same thing. Free trials, failed requests, promotional credits, and internal operations can create real cost without being charged to customers.

How MetricaOS helps

MetricaOS helps AI product teams connect usage and cost to customers, users, features, models, providers, and workflows.

This gives teams visibility beyond the provider invoice and helps them understand where AI spend actually originates.

With customer and feature-level cost attribution, AI companies can identify expensive usage, evaluate margins, improve pricing, set better limits, and make more informed product decisions.

For AI products, knowing total model spend is useful. Knowing exactly what created that spend is far more actionable.

AI Cost Attribution: How to Know Which Customers and Features Drive Your LLM Spend

· · Leave a Comment

AI companies often know how much they spend on model providers every month.

They may see a bill for $2,000, $20,000, or $200,000. But that number alone does not explain where the cost came from.

It does not tell the team:

  • Which customers generated the most cost
  • Which features are expensive to operate
  • Which models are driving spend
  • Which workflows are profitable
  • Whether a pricing plan still protects margin

This is the problem AI cost attribution solves.

AI cost attribution connects model and infrastructure costs to the product activity responsible for creating them. It turns a provider invoice into actionable customer, feature, model, and workflow-level information.

Without it, AI teams can see total spend but cannot reliably explain it.

What is AI cost attribution?

AI cost attribution is the process of assigning AI-related costs to the customers, users, workspaces, features, models, or workflows that generated them.

For example, a provider bill may show:

Total monthly LLM spend: $18,500

AI cost attribution adds product context:

Customer A: $3,200
Customer B: $1,450
Customer C: $120
Document analysis feature: $8,700
AI assistant feature: $5,300
Report generation feature: $4,500

The total spend has not changed. But the company can now understand who and what created it.

Cost attribution depends on reliable AI usage metering. The product must first record usage with enough context to connect every relevant event to a customer, feature, model, and cost.

Why provider invoices are not enough

Model-provider invoices are useful for accounting, but they are usually too broad for product and pricing decisions.

They may show total usage by model, project, API key, or account. But they do not automatically understand the internal structure of your product.

The provider usually does not know:

  • Which of your customers initiated a request
  • Which product feature generated it
  • Whether the request was part of a free trial
  • Whether it should consume customer credits
  • Whether it was a retry or duplicate
  • Whether the request was internal or customer-facing
  • Which subscription plan the customer uses

That context exists inside your application.

A provider can tell you what was consumed. Your product must explain why it was consumed and who was responsible.

This is why LLM cost tracking needs to happen at the product level rather than only at the provider-account level.

What should AI costs be attributed to?

The right attribution dimensions depend on how your product is structured. Most AI products should start with a few core dimensions.

Customer

Customer-level attribution answers:

How much did this customer cost us to serve?

This is one of the most commercially useful views because it connects usage directly to revenue and margin.

If a customer pays $199 per month but creates $280 in model cost, the problem is not visible from subscription revenue alone.

Tracking cost per customer helps teams identify expensive accounts, evaluate plan profitability, and decide when pricing or usage controls need to change.

User or workspace

In B2B products, one customer account may contain many users, teams, projects, or workspaces.

Workspace-level attribution can reveal that one department creates most of the account’s usage while others use very little.

This information can support:

  • Workspace quotas
  • Departmental chargebacks
  • Admin usage reports
  • Seat-and-usage pricing
  • Enterprise contract discussions

Feature

Feature-level attribution answers:

Which AI features create the most cost?

A product may offer document summarization, content generation, search, transcription, data extraction, and agent workflows. These features can have very different cost profiles.

For example:

Document summarization: $4,800
Agent workflows: $9,600
AI search: $1,300
Email generation: $700

A feature with high adoption may still be unattractive if it creates disproportionate cost without supporting retention, upgrades, or revenue.

Feature-level attribution helps product teams decide where to optimize, restrict, redesign, or charge more.

Model and provider

Different models may have different cost, speed, quality, and context requirements.

Model-level attribution helps teams understand:

  • Which models drive the most spend
  • Whether premium models are used unnecessarily
  • Whether cheaper models can handle certain tasks
  • Whether routing logic is working
  • How provider changes affect margins

Two features may process similar usage volumes but create very different costs because they use different models.

Workflow or operation

Some AI actions require only one model request. Others may trigger multiple steps.

An agent workflow might:

  1. Retrieve stored information
  2. Call a language model
  3. Use an external tool
  4. Call the model again
  5. Generate a final response

Looking at only the final model call would understate the true cost of the workflow.

Workflow-level attribution combines all related costs into a single product action that the business can understand.

What data does AI cost attribution require?

Cost attribution starts with a well-structured usage event.

A basic event might look like this:

{

  "event_type": "llm_request_completed",

  "customer_id": "cus_123",

  "user_id": "user_456",

  "workspace_id": "workspace_789",

  "feature": "document_analysis",

  "workflow_id": "workflow_987",

  "provider": "model_provider",

  "model": "premium-language-model",

  "input_tokens": 4200,

  "output_tokens": 650,

  "estimated_cost_usd": 0.036,

  "billable": true,

  "timestamp": "2026-07-19T10:30:00Z"

}

The token values explain how much language-model usage occurred.

The customer, workspace, feature, and workflow fields explain where that usage belongs.

The estimated cost explains the financial impact.

Without those attribution fields, the company may know that 4,850 tokens were consumed but not which customer or feature consumed them.

For a deeper explanation of the usage layer, see Token Metering for AI Products.

How AI cost is calculated

For token-priced models, a simplified request-cost calculation may look like this:

Input cost = input tokens × input token rate

Output cost = output tokens × output token rate

Request cost = input cost + output cost

The product can then aggregate request costs by customer, feature, model, or billing period.

Customer cost = sum of all attributed customer events

Feature cost = sum of all attributed feature events

Workflow cost = sum of all events within the workflow

But not every AI cost is token-based.

Depending on the product, cost attribution may also include:

  • Embedding generation
  • Image generation
  • Audio transcription
  • Text-to-speech
  • Reranking
  • External tools
  • Vector database usage
  • File processing
  • Compute
  • Storage
  • Third-party APIs

A reliable system should support the usage units that matter to the product rather than assuming every AI event is identical.

Estimated cost vs finalized cost

Real-time cost attribution often uses estimated cost.

When a request finishes, the product records the usage and applies the relevant provider rate. This allows dashboards, alerts, credits, and limits to update immediately.

However, final provider charges may occasionally differ because of discounts, committed-use agreements, caching, batch pricing, regional pricing, or pricing changes.

It is therefore useful to distinguish between:

  • Estimated cost: calculated when the usage event occurs
  • Finalized cost: reconciled against confirmed provider billing data

For many product decisions, a reliable estimate is enough. But financial reconciliation may require a separate finalization process.

Teams should also store the pricing version or rate used for each calculation. Otherwise, a future pricing change could incorrectly alter historical cost.

Raw usage, attributed cost, and billable usage

These concepts are related, but they should not be treated as the same thing.

Raw usage

Raw usage describes what technically happened.

4,200 input tokens

650 output tokens

One model request

Attributed cost

Attributed cost connects that usage to the responsible product dimensions.

Customer: cus_123

Feature: document_analysis

Estimated cost: $0.036

Billable usage

Billable usage determines what should count toward the customer’s plan, credits, overage, or invoice.

A request may create real cost without being billable. Examples include:

  • Free trial usage
  • Internal testing
  • Failed requests
  • Customer support credits
  • Promotional usage
  • Product-generated background tasks

This distinction matters because cost and billing are not identical.

A company must understand the cost of all relevant usage, even when it chooses not to charge the customer for that usage.

Accurate attribution creates the foundation for usage-based billing, but billing rules should remain a separate business layer.

How AI cost attribution protects margins

AI cost attribution makes gross-margin problems visible before they become severe.

Imagine a product with a $99 monthly plan and 1,000 customers.

The company may initially see:

Monthly recurring revenue: $99,000

Monthly model spend: $24,000

At an aggregate level, the economics may appear acceptable.

But customer-level attribution could reveal:

700 customers cost less than $10 each

220 customers cost between $10 and $50 each

70 customers cost between $50 and $100 each

10 customers cost more than $500 each

A small number of customers may be responsible for a large share of total spend.

Without attribution, those customers remain hidden inside an average.

With attribution, the team can consider:

  • Moving heavy users to higher plans
  • Introducing overage charges
  • Reducing included usage
  • Applying usage quotas
  • Offering prepaid credit packages
  • Optimizing expensive workflows
  • Routing requests to more suitable models
  • Creating enterprise contracts for high-volume accounts

The goal is not simply to reduce usage. The goal is to ensure usage and revenue grow sustainably together.

How cost attribution improves pricing

AI pricing is difficult when teams do not know what their product costs at the customer and feature level.

Cost attribution provides evidence for pricing decisions.

For example, it can help a company determine:

  • How much usage each plan can include
  • Whether credits accurately reflect cost
  • Which features should be premium
  • Whether overage rates protect margin
  • Which customers need custom pricing
  • Whether an unlimited plan is sustainable

For products using credit-based pricing, attribution helps ensure credit consumption reflects the underlying economics.

A simple action may consume five credits, while an expensive workflow consumes 500. The difference should be based on real usage and cost rather than guesswork.

The broader pricing process is covered in Usage-Based Billing for AI Products.

How product teams use cost attribution

AI cost attribution is not only a finance function.

Product teams

Product teams can compare feature adoption with feature cost. A widely used feature may justify its cost, while an expensive low-value feature may need redesign.

Engineering teams

Engineering teams can find inefficient prompts, oversized context windows, unnecessary retries, expensive model choices, and workflows that trigger too many calls.

Finance teams

Finance teams can forecast model spend, monitor margins, reconcile provider charges, and understand cost growth.

Sales teams

Sales teams can identify accounts that need enterprise pricing or custom usage commitments.

Customer-success teams

Customer-success teams can warn customers about unusual usage, explain quota consumption, and recommend a more suitable plan.

A shared attribution layer gives these teams a consistent view of usage and cost.

Example: attributing cost across customers and features

Imagine an AI research platform with three main features:

Document summary

Question answering

Automated research report

At the end of the month, total AI spend is $12,000.

Feature-level attribution shows:

Document summary: $2,100

Question answering: $3,400

Automated research report: $6,500

Customer-level attribution shows:

Customer A: $2,800

Customer B: $1,900

Customer C: $220

All other customers: $7,080

The team then discovers that Customer A runs automated research reports at a very high volume.

Customer A pays $499 per month but creates $2,800 in AI cost.

The company now has several options:

  • Add a report quota
  • Charge per additional report
  • Increase the report’s credit cost
  • Move the customer to an enterprise contract
  • Optimize the workflow
  • Use a cheaper model for intermediate steps

Before attribution, the problem was hidden inside a $12,000 provider bill.

After attribution, the company knows exactly where to act.

Common AI cost-attribution mistakes

Tracking only total provider spend

Total spend is useful for accounting but insufficient for customer, pricing, and product decisions.

Omitting customer and feature identifiers

Tokens without product context cannot be reliably assigned later. Important attribution fields should be recorded when the event occurs.

Using only average cost per customer

Averages can hide expensive outliers. Individual customer-level cost is often more useful.

Ignoring failed requests and retries

Retries can create additional cost. Teams need clear rules for recording, deduplicating, and billing them.

Mixing internal and customer usage

Development, testing, demos, and administrative usage should be labelled separately.

Assuming all tokens have the same cost

Input and output pricing may differ, and different models may have different rates. Cost calculations should use the correct model and pricing version.

Treating attributed cost as automatically billable

Some usage creates cost but should not be charged to the customer. Cost attribution and billing logic should remain distinct.

How to implement AI cost attribution

A practical implementation can be built in stages.

1. Define the attribution dimensions

Start with the dimensions required for business decisions:

Customer

User or workspace

Feature

Model

Provider

Workflow

2. Record structured usage events

Capture usage when it happens. Do not rely only on reconstructing it later from application logs.

3. Calculate request-level cost

Apply the correct pricing rules based on provider, model, usage type, and pricing version.

4. Aggregate cost

Create customer, feature, model, and workflow-level views.

5. Separate cost from billing

Record what the usage cost the company, then separately decide whether it consumes credits, counts toward a quota, or becomes billable.

6. Add alerts and controls

Notify teams when a customer, feature, or workflow crosses a meaningful cost threshold.

7. Review pricing and product decisions

Use the attribution data to adjust plans, limits, credit values, routing, and feature design.

How MetricaOS helps

MetricaOS helps AI product teams connect usage events to customers, users, workspaces, features, models, providers, and estimated costs.

Instead of stopping at a monthly provider bill, teams can understand:

  • Which customers generate AI cost
  • Which features consume the most resources
  • How model usage affects customer-level margins
  • How credits and quotas map to actual consumption
  • Which usage should become billable

MetricaOS provides the metering foundation needed to move from raw AI activity to cost visibility, pricing controls, and sustainable monetization.

For AI products, tracking total spend is only the beginning.

The more important question is:

Which customers, features, and workflows created that spend – and did the revenue justify it?

Cost per Customer

· · Leave a Comment

What is cost per customer?

Cost per customer is the amount a company spends to serve an individual customer over a specific period.

In AI products, this usually includes the cost of model usage, tokens, AI requests, file processing, infrastructure, storage, and other product resources consumed by that customer.

For example, an AI SaaS company may have three customers on the same $99/month plan:

Customer A costs $12/month to serve
Customer B costs $38/month to serve
Customer C costs $145/month to serve

Even though all three customers pay the same price, they do not create the same cost.

This is why cost per customer is especially important for AI products. AI usage can vary heavily between customers, even when they are on the same plan.

Why cost per customer matters for AI products

AI products often have variable costs. Every prompt, response, summary, document analysis, workflow, or agent action may create real provider cost.

If a company only looks at total monthly AI spend, it may miss which customers are profitable and which customers are creating margin pressure.

For example:

Monthly subscription revenue from a customer: $99

Monthly LLM cost from that customer: $140

Gross margin before other costs: negative

That customer may look healthy from a revenue perspective, but they are actually unprofitable.

Tracking cost per customer helps AI teams answer questions like:

  • Which customers are the most expensive to serve?
  • Which customers are profitable?
  • Which plans are underpriced?
  • Which features create the most cost?
  • Should heavy users be moved to a higher plan?
  • Should usage quotas or overages be added?

This is closely related to LLM cost tracking, because teams need to understand model spend before they can calculate customer-level cost.

What should be included in cost per customer?

For AI products, cost per customer should include the product costs that increase with customer usage.

Common cost components include:

LLM provider cost

Input token cost

Output token cost

Embedding cost

Image generation cost

Speech-to-text or transcription cost

AI workflow execution cost

Vector database usage

Storage

Compute

API usage

The most important cost component is usually LLM or model provider cost, especially for products built on OpenAI, Anthropic, Google, Azure OpenAI, or other AI providers.

But cost per customer should not only track the provider bill. It should connect that cost to product context, such as the customer, user, workspace, feature, model, and billing period.

That usually requires AI usage metering and token metering at the product level.

Cost per customer and token usage

In many AI products, cost per customer is calculated from token usage.

A simple usage event may show:

Customer: cus_123

Feature: document_summary

Input tokens: 4,200

Output tokens: 650

Model: gpt-4.1

Estimated cost: $0.036

One event may look small. But across thousands of requests, the total cost can become meaningful.

For example:

Customer: cus_123

Monthly requests: 18,000

Total tokens: 52 million

Estimated LLM cost: $410

Plan revenue: $299

In this case, the customer may be using the product heavily enough to create negative margin.

This is why token metering is important. It gives the raw usage data needed to calculate customer-level cost.

Cost per customer vs average cost per customer

Cost per customer looks at the cost of serving each individual customer.

Average cost per customer looks at total cost divided across all customers.

For example:

Total monthly AI cost: $10,000

Total customers: 500

Average cost per customer: $20

That average may look healthy.

But the individual breakdown may show something very different:

100 customers cost less than $5 each

350 customers cost around $20 each

50 customers cost more than $100 each

The average hides the problem.

For AI products, individual customer-level cost is often more useful than average cost because usage patterns are uneven. A few heavy customers can create a large portion of total AI spend.

How cost per customer affects pricing

Cost per customer helps teams design better pricing.

If customers on a plan consistently cost more than expected, the company may need to adjust the plan structure.

Possible changes include:

  • Lower included usage
  • Add usage quotas
  • Introduce overage billing
  • Move heavy users to higher plans
  • Change credit consumption rates
  • Use cheaper models for some actions
  • Limit expensive workflows

For products using credit-based pricing, cost per customer helps validate whether credit allowances are sustainable.

For example, if a Pro plan includes 20,000 credits, the team needs to know whether those credits usually cost $5, $50, or $500 to deliver.

Cost per customer also supports usage-based billing, because billing rules should reflect the real cost of customer consumption.

Example of cost per customer

Imagine an AI legal document product with three pricing plans.

Starter: $49/month

Pro: $199/month

Business: $599/month

A customer on the Pro plan uploads long legal documents and runs high-volume analysis every day.

At the end of the month, the product team sees:

Subscription revenue: $199

LLM cost: $260

Storage and processing cost: $35

Total cost to serve: $295

That customer costs more to serve than they pay.

The company may need to add a usage quota, move the customer to a higher plan, charge for additional usage, or optimize the feature to use a lower-cost model.

Without customer-level cost tracking, this issue may remain hidden inside the total provider bill.

Common mistakes with cost per customer

A common mistake is only tracking total AI spend. Total spend shows how much the company paid, but not which customers created the cost.

Another mistake is using averages too early. Average cost per customer may look fine while a small group of heavy users is unprofitable.

Some teams also track usage but do not convert it into cost. Usage data is useful, but pricing and margin decisions need cost data too.

Another mistake is not separating billable usage from internal usage. Testing, demos, admin actions, and development traffic should not be mixed with customer cost.

Finally, some teams ignore cost per customer until pricing breaks. By then, customers may already be used to generous limits, unlimited plans, or underpriced AI features.

How MetricaOS helps

MetricaOS helps AI product teams track usage and cost at the customer level.

With MetricaOS, teams can connect usage events to customers, users, features, models, tokens, credits, quotas, and estimated cost.

This helps AI companies understand which customers are profitable, which features create cost, and where pricing needs to change.

For AI products, cost per customer is not just a finance metric. It is a product, pricing, and margin metric.

LLM Cost Tracking

· · Leave a Comment

What is LLM cost tracking?

LLM cost tracking is the process of measuring how much an AI product spends on large language model usage.

In AI products, every model request can create cost. A user may send a prompt, generate a response, summarize a document, analyze a file, run an AI workflow, or trigger an agent. Each of these actions may consume input tokens, output tokens, or other model-related resources.

LLM cost tracking helps product and engineering teams understand where that cost is coming from.

For example, instead of only seeing a monthly provider bill, a team can answer:

  • Which customers are generating the most LLM cost?
  • Which features are the most expensive to run?
  • Which model is driving the highest spend?
  • How much does each AI workflow cost?
  • Is usage growing faster than revenue?

This is closely connected to AI usage metering, because teams need accurate usage data before they can understand cost clearly.

Why LLM cost tracking matters

Traditional SaaS products usually have relatively stable software costs. AI products are different.

When an AI product uses OpenAI, Anthropic, Google, Azure OpenAI, or other model providers, product usage can directly increase the company’s cost. A single customer using long prompts, large documents, frequent generations, or expensive models can create much higher cost than another customer on the same plan.

Without LLM cost tracking, teams may only notice the problem when the monthly provider invoice arrives.

That is too late.

LLM cost tracking helps teams protect margin, design better pricing, set usage limits, and understand whether specific customers or features are profitable. It also helps teams avoid offering “unlimited AI” without knowing the real cost behind that promise.

For AI products using usage-based billing, LLM cost tracking is especially important because pricing needs to be connected to actual consumption.

What should LLM cost tracking measure?

LLM cost tracking should not stop at total monthly spend.

A useful cost tracking setup should break cost down by the dimensions that matter to the business.

Common dimensions include:

Customer
User
Workspace or team
Feature
Model
Provider
Token usage
Request type
Workflow
Billing period

For example, a product team may want to know that Customer A spent $42 in model cost this month, mostly through the document analysis feature, using a higher-cost model.

That is much more useful than simply knowing the company spent $3,000 on LLM usage this month.

Good cost tracking connects model usage to product context.

LLM cost tracking and token metering

Most LLM cost tracking depends on token metering.

Tokens are the basic unit many language models use to calculate usage. Input tokens come from the prompt, context, uploaded text, or conversation history. Output tokens come from the model’s response.

A simple model request may include:

Input tokens: 3,000

Output tokens: 600

Model: gpt-4.1

Customer: cus_123

Feature: contract_summary

Estimated cost: $0.027

Token metering tells the team how much usage happened. LLM cost tracking converts that usage into cost.

Even if customers do not see tokens directly, the company still needs to understand token-level cost internally. This is especially important when using credit-based pricing, because credits need to map back to real cost in a sustainable way.

LLM cost tracking vs AI usage metering

LLM cost tracking and AI usage metering are related, but they are not exactly the same.

AI usage metering tracks what customers consume.

LLM cost tracking focuses on what that consumption costs the company.

For example, AI usage metering may record:

Customer A generated 10,000 AI summaries this month.

LLM cost tracking adds:

Those summaries created $380 in model cost.

Both are needed.

Usage data helps teams understand product activity. Cost data helps teams understand margin. Together, they help AI companies decide how to price plans, set usage quotas, control abuse, and decide when customers should upgrade.

Example of LLM cost tracking

Imagine an AI support product with three AI features:

Reply generation

Ticket summarization

Customer sentiment analysis

At the end of the month, the provider bill shows:

Total LLM spend: $5,000

That number alone is not enough.

With LLM cost tracking, the team may discover:

Reply generation: $1,200

Ticket summarization: $2,900

Customer sentiment analysis: $900

Then they may go deeper:

Customer A: $800

Customer B: $120

Customer C: $40

This changes how the team thinks about pricing.

If Customer A is paying $99/month but creating $800 in model cost, that customer is unprofitable. The company may need better limits, higher pricing, overages, or a different plan structure.

This is why LLM cost tracking supports both product decisions and billing decisions.

Common mistakes with LLM cost tracking

A common mistake is only looking at the provider invoice.

Provider invoices show total spend, but they usually do not explain which customer, feature, or workflow created the cost. This makes it hard to protect margin.

Another mistake is tracking tokens without converting them into cost. Token usage is useful, but business teams also need to understand money.

Some teams also forget to track model-level cost. If one feature uses a cheaper model and another uses a premium model, total token usage alone may not tell the full story.

Another mistake is not separating internal usage from customer usage. Testing, demos, admin activity, and development traffic should be separated from billable customer usage.

Finally, some teams start cost tracking too late. By the time AI usage grows, it becomes harder to reconstruct historical cost accurately.

How MetricaOS helps

MetricaOS helps AI product teams track usage and cost across customers, users, features, models, and providers.

For LLM cost tracking, MetricaOS gives teams a structured way to connect AI usage events to estimated cost, customer attribution, credits, quotas, and billing logic.

This helps teams move beyond provider invoices and understand the real economics of their AI product.

For AI companies, LLM cost tracking is not just an accounting task. It is the foundation for sustainable pricing, margin protection, and smarter product decisions.