AI pricing conversations often begin with the unit.
Should we charge per token?
Per request?
Per generation?
Per workflow?
Should we use credits?
Should customers receive a monthly quota?
These are useful questions.
But they may come too early.
Before deciding which unit should appear in a pricing model, there is a more fundamental distinction worth making:
Should the thing a customer values, the thing a product commercially allocates, and the thing infrastructure actually consumes be represented by the same unit?
For some products, they may align reasonably well.
For others, forcing them into the same abstraction can make both pricing and infrastructure harder to reason about.
Consider an AI research agent.
A customer asks:
Research this company and produce a report.
From the customer's perspective, the interaction is straightforward.
Request
↓
Research
↓
Completed Report
The customer wants the report.
The product might represent that task commercially as:
1 Report
↓
10 Credits
But the infrastructure may experience something very different:
Research Request
↓
Context Retrieval
↓
Model Call
↓
Search
↓
Tool Calls
↓
External API
↓
Model Call
↓
Tool Failure
↓
Retry
↓
Validation
↓
Storage
↓
Completed Report
One customer-visible outcome.
One commercial deduction.
Many underlying execution events.
All three describe the same product interaction.
But they describe different realities.
That gives us a useful mental model:
Value Unit ≠ Commercial Unit ≠ Economic Unit
Not because these units must always be different.
But because there is no reason to assume they must always be the same.
One Number Is Trying to Do Too Many Jobs
When teams debate pricing units, several concerns often become compressed into one question.
What will customers understand?
What should the product sell?
What should the customer be allowed to consume?
What should the backend meter?
What actually drives infrastructure cost?
What protects margins?
Those questions are related.
They are not identical.
Suppose our research agent exposes its underlying token consumption directly to the customer.
That creates a close relationship between infrastructure consumption and commercial consumption.
For some products, that may be appropriate.
But the customer may not care whether a report required 18,000 or 42,000 tokens.
They care whether the research was useful.
Now suppose the product instead charges ten credits per report.
The customer gets a more predictable commercial abstraction.
But ten credits do not tell the company what producing the report actually cost.
The credit solves one problem.
The execution data solves another.
And the completed report represents something else again: the value the customer came to the product to receive.
Trying to make one unit perfectly represent all three can create unnecessary coupling.
A change in model architecture can change token consumption without changing customer value.
A change in commercial packaging can change how many credits a workflow consumes without changing its infrastructure cost.
A more complex research request can increase execution cost without changing either the customer's visible outcome or the commercial deduction.
The system therefore contains three separate questions:
What does the customer value?
↓
What does the product commercially allow?
↓
What does execution actually consume?
Understanding the distinction between them makes the rest of the pricing conversation easier to reason about.
Unit #1 — What Does the Customer Think They're Buying?
Start with the customer.
A user rarely opens an AI product because they want to consume tokens.
They usually want something to happen.
Analyze this contract.
Resolve this ticket.
Research this company.
Process this document.
Generate this report.
For our research agent, the customer wants:
1 Completed Research Report
We can think of that as the Value Unit.
The Value Unit describes the thing the customer perceives as useful.
It is not necessarily the unit the company should charge for.
It is not necessarily something that can even be measured precisely.
Its purpose in this framework is simpler:
What is the customer actually trying to get from the product?
For a research agent, a completed report may be a reasonable answer.
For a support automation product, it might be a resolved conversation.
For document processing, it might be a correctly processed document.
But outcome-like units do not work cleanly for every AI product.
A coding assistant may contribute value continuously across dozens of interactions.
A creative tool may support exploration rather than produce one objectively successful outcome.
A conversational assistant may create value throughout a session without any single event representing completion.
So the Value Unit should not automatically become a pricing unit.
And it should not be interpreted as an argument for outcome-based pricing.
It is simply the customer side of the system.
The distinction matters because infrastructure and customers often describe the same product in completely different language.
Infrastructure sees execution.
The customer sees value.
Unit #2 — What Does the Product Commercially Allow?
Now suppose the research agent is sold through a credit-based plan.
The customer receives a monthly allowance.
A completed research workflow consumes:
10 Credits
Those credits are not the research itself.
They are not tokens.
They are not necessarily a direct representation of infrastructure cost.
They are a Commercial Unit.
Commercial Units are abstractions used to translate a commercial agreement into product behavior.
Depending on the product, they might be:
- Credits
- Runs
- Quotas
- Included usage
- Prepaid balances
- Entitlements
Their role is different from the Value Unit.
They can help answer questions such as:
What has the customer purchased?
How much are they allowed to use?
What should happen when the allowance is exhausted?
Which capabilities are currently available?
This is why credits can be useful without needing to represent underlying infrastructure cost exactly.
A credit may provide predictable packaging.
It may create a spending boundary.
It may make allowance easier for customers to understand.
It may give the runtime something concrete to authorize against.
None of that requires one credit to map permanently to a specific number of tokens or a fixed amount of provider spend.
That separation can be valuable because implementation changes.
Models change.
Providers change.
Prompts change.
Workflows change.
If the customer-facing commercial abstraction is tightly coupled to every internal implementation detail, infrastructure changes can leak directly into the pricing experience.
But abstraction does not eliminate economics.
If ten credits allow an execution that consistently costs more than the commercial model can support, calling it ten credits does not make the problem disappear.
The Commercial Unit governs allowance.
It does not, by itself, explain cost-to-serve.
Unit #3 — What Did Execution Actually Consume?
Now look beneath the ten-credit deduction.
The research report may have required:
Context Retrieval
↓
Model Inference
↓
Search
↓
Tool Calls
↓
External API
↓
Retry
↓
Additional Inference
↓
Validation
↓
Storage
These operations belong to the economic side of execution.
They consume resources.
Some create direct variable costs.
Some use shared infrastructure.
Some occur only on exception paths.
Some may be difficult to attribute precisely to a single workflow.
Together, they help describe the Economic Unit side of the system: what producing the customer-visible result actually consumed.
For the same research report, that may include:
- Model and token cost
- Retrieval
- Tool execution
- External API usage
- Retries and failed attempts
- Compute
- Storage
- Validation or evaluation overhead
Unlike a credit, there may not be one neat Economic Unit.
The economic layer may be composed of several cost drivers that need to be understood together.
That is especially relevant for AI products because execution paths can vary.
Two requests for the same feature do not necessarily perform the same work.
One report may require a short context, a few searches and a straightforward model path.
Another may require more retrieval, several tools, additional inference and a retry.
The customer may still receive:
1 Research Report
The commercial system may still deduct:
10 Credits
But underneath those two identical abstractions, the execution economics can be different.
And that gives us the first important consequence of separating the three units:
Same Value Unit
1 Research Report
↓
Same Commercial Unit
10 Credits
↓
Different Economic Reality
Different execution paths
Different resource consumption
Different cost-to-serve
The variance itself is not necessarily a problem.
The problem begins when the business cannot see or explain it.
Same Outcome. Same Credits. Different Economics.
Now we can put the three units together.
Two customers use the same AI research agent. Both ask for a company analysis, both receive a completed research report, and both consume 10 credits from their plan.
From the customer's perspective, the transaction looks identical. From the commercial system's perspective, it is identical too.
The execution paths, however, may tell a different story.
Customer A
Value Unit
1 completed research report
Commercial Unit
10 credits
Execution
├── Short context
├── 2 retrieval operations
├── 2 model calls
├── 1 tool call
├── No retries
└── Validation
Customer B
Value Unit
1 completed research report
Commercial Unit
10 credits
Execution
├── Long context
├── 6 retrieval operations
├── 4 model calls
├── Multiple tool calls
├── 1 external API
├── 1 failed tool call
├── 1 retry
└── Validation
Customer A and Customer B received the same customer-visible unit of value. The commercial system also treated them identically: each workflow consumed 10 credits.
But producing those reports required different amounts of work.
Customer B's report may have consumed more tokens, more retrieval capacity, more third-party services and an additional execution attempt. Depending on the underlying cost structure, the difference in cost-to-serve could be meaningful.
This creates a simple but important relationship:
Same customer value. Same commercial consumption. Different economics.
That does not mean Customer B is a bad customer. Higher execution cost may be perfectly justified by higher revenue, stronger retention, greater strategic value or simply the economics of the plan as a whole.
Nor does it mean every report needs a different credit price. Exposing every variation in infrastructure cost to the customer could make the product unnecessarily difficult to understand.
The problem is not that execution costs vary.
The problem is not understanding that variance.
If the business cannot connect commercial consumption with the execution behind it, several different economic profiles can collapse into the same dashboard number:
Customer A Customer B
────────────────────────────────────────────
1 report 1 report
10 credits 10 credits
$X cost-to-serve $Y cost-to-serve
Healthy margin? Healthy margin?
At small scale, those differences may not matter much. As usage grows and workflows become more complex, however, the distribution can become more important than the average.
A plan may look healthy overall while containing a small set of customers or execution paths with very different economics. Conversely, an expensive customer may still be highly profitable because the commercial relationship more than compensates for the additional cost.
This is why usage volume alone is not enough to describe customer profitability. What matters is the relationship between what the customer pays, what the commercial model allows, and what the runtime actually consumes to deliver the value.
Tokens Are an Infrastructure Unit, Not a Customer Outcome
Token measurement remains essential.
Tokens help engineering teams understand model consumption, compare providers, investigate execution behavior and estimate an important component of variable cost. For some AI products, token consumption may even explain most of the marginal cost of serving a request.
The distinction is not that tokens are the wrong unit. It is that they answer a specific question:
What did model execution consume?
Our research-agent customer is asking a different question:
Did I get the research report I came here for?
And the commercial system may be asking another:
Was this customer allowed to consume the 10 credits required for this workflow?
These three questions can coexist:
| Perspective | Question |
|---|---|
| Infrastructure | What did execution consume? |
| Commercial | What was the customer allowed to use? |
| Customer | Did I get what I came here for? |
The mistake is not measuring tokens. The mistake is assuming that because tokens are measurable, they must also be the best abstraction for customer value or commercial packaging.
Sometimes they may be.
An API product sold to developers, for example, may have customers who already understand and accept consumption-based infrastructure units. In other products, exposing the implementation directly may create complexity without adding useful information.
The important thing is to make the choice deliberately rather than assuming one unit has to serve every layer.
Why Separating the Units Can Improve Pricing Predictability
Return to the research agent.
The customer wants a report. Internally, producing that report may involve different models, varying context sizes, changing providers, retries, retrieval operations and external tools.
If every internal variation were reflected directly in the customer-facing price, understanding the cost of a report could become difficult.
Imagine a user having to reason about:
Input tokens
+ Output tokens
+ Retrieval operations
+ Tool calls
+ External API usage
+ Retry consumption
+ Model routing
= Final price
For some infrastructure products, that level of granularity is appropriate. For a customer buying a research outcome, it may not be.
A Commercial Unit can create a boundary between those two worlds.
Customer
↓
1 Research Report
↓
10 Credits
────────────────────
Commercial Boundary
────────────────────
↓
Models
Retrieval
Tools
Retries
APIs
Compute
↓
Variable Execution Cost
The customer interacts with a relatively stable commercial abstraction. Internally, the company can still observe the more granular economic reality required to understand cost-to-serve.
This separation can also give engineering teams room to change implementation without necessarily changing the customer's mental model every time.
A workflow might move to a different model. Retrieval could become more efficient. A provider could change. A tool could be replaced. An optimization might reduce the number of model calls required to produce the same report.
If the customer continues receiving the same value and the commercial model remains sustainable, those implementation details do not necessarily need to become pricing events.
This leads to a principle I find useful:
Your customer shouldn't need to understand your AI economics. Your runtime does.
But abstraction does not eliminate economic risk.
If the product sells ten credits for an amount that consistently fails to cover the execution they authorize, predictable pricing has simply hidden an unsustainable cost structure.
The business still needs to understand the relationship between its commercial abstraction and the economics underneath it.
So separating the units is not about hiding cost. It is about allowing each layer to use the abstraction appropriate to its responsibility while preserving visibility across the system.
The Three Units Create Three Different Questions
We can now reduce the framework to three layers.
| Layer | Unit | Question |
|---|---|---|
| Value | Outcome / Job | What does the customer value? |
| Commercial | Credits / Runs / Quota | What is the customer allowed to consume? |
| Economic | Execution Costs | What does producing it actually cost? |
For our research agent:
VALUE
1 completed research report
↓
COMMERCIAL
10 credits
↓
ECONOMIC
Models + Retrieval + Tools + APIs
+ Retries + Compute + Storage
These layers influence each other, but they do not need to collapse into a single unit.
The Value Unit helps explain why the product matters to the customer. The Commercial Unit translates the business model into allowance and access. The Economic Unit helps the company understand what fulfilling that allowance actually costs.
A healthy monetization model therefore does not necessarily require finding one perfect unit. It requires understanding the relationship between the units the business chooses to use.
That relationship becomes especially important when execution is variable. If ten credits can authorize workflows with materially different cost-to-serve, the commercial abstraction may remain perfectly useful — but the infrastructure needs enough visibility to understand what is happening underneath it.
And at that point, what initially looked like a pricing problem starts becoming an architecture problem.
This Becomes a Runtime Problem
Once Value Units, Commercial Units and Economic Units are separated, a new responsibility appears.
Something still has to connect them.
For our research agent, the commercial system may know that the customer has enough allowance for another report. The customer may understand that the report consumes 10 credits. The execution layer, meanwhile, is about to trigger models, retrieval, tools and external services whose actual cost is not yet fully known.
Those realities meet at runtime.
A simplified lifecycle might look like this:
Payment
↓
Commercial State
↓
Entitlement / Allowance
↓
Authorization
↓
Execution
↓
Metering
↓
Cost Attribution
↓
Outcome
↓
Economics
Each stage answers a different question.
Payment establishes a commercial event. Commercial state represents what the customer has purchased. Entitlements and allowances describe what the product should make available. Authorization determines whether a particular operation should proceed.
Execution then creates the actual workload.
Metering records what happened. Cost attribution attempts to connect meaningful execution costs back to customers and workflows. Outcome information provides context about what the execution produced. Only after connecting these layers can the business begin reasoning about the resulting economics.
This is why billing infrastructure and runtime infrastructure have different responsibilities.
A payment provider does not need to understand every model call, retry or tool execution inside the research agent. That is not the responsibility of payment infrastructure.
Similarly, knowing that a customer successfully paid does not tell the application whether every future execution should be allowed.
A useful distinction is:
Billing records commercial events. A monetization runtime governs what should happen during execution.
The two layers complement each other.
Suppose our customer purchases a plan containing 100 credits.
The payment event establishes the commercial relationship. But when the customer requests a research report three weeks later, the runtime may still need to determine whether the account is active, whether sufficient allowance remains, whether the requested capability is available and whether consumption can be applied correctly.
Payment says:
"Commercial event completed."
Runtime asks:
"Given the current commercial state,
should this execution happen now?"
That distinction becomes more important when execution itself has meaningful variable cost.
Once authorization allows the workflow to proceed, the business begins consuming resources. A decision that looks like access control at the application layer can therefore also determine whether the company incurs model, tool and infrastructure costs.
But authorization is only the beginning.
The system also needs trustworthy information about what happened after execution was allowed.
If usage is recorded incorrectly, retries consume allowance twice, concurrent requests overspend the same balance or failed executions disappear from the data, later economic analysis inherits those inconsistencies.
Before asking whether usage was profitable, we first need confidence that usage was correct.
From Correct Usage to Profitable Usage
There is a useful progression here:
Payment ≠ Access
↓
Access ≠ Correct Usage
↓
Correct Usage ≠ Profitable Usage
Each step introduces a different problem.
Payment ≠ Access
A successful payment is an event.
Product access is an ongoing state.
A customer may upgrade, downgrade, cancel, receive additional allowance or lose access to a capability. Payment information therefore needs to become reliable application state before the runtime can make execution decisions from it.
The important question is no longer only:
Did the customer pay?
It also becomes:
Given the customer's current commercial state, should this operation be available now?
This is where commercial state, entitlements and runtime authorization begin to matter.
Access ≠ Correct Usage
Now suppose the customer is correctly authorized to run the research workflow.
That still does not guarantee that consumption will remain correct during execution.
Two requests might arrive concurrently. A network timeout might cause a retry. A client might resend the same operation. A worker may complete successfully while the caller believes the request failed.
The customer was allowed to execute.
The harder question becomes whether the system preserves the intended commercial semantics while those distributed-system behaviours occur.
For example:
Customer has 10 credits
↓
Workflow costs 10 credits
↓
Two concurrent requests arrive
↓
Both observe the same balance
↓
What happens?
This is no longer simply a pricing question.
It is an engineering correctness problem involving concepts such as atomic consumption, idempotency, concurrency control, reconciliation and retry-safe execution.
The objective is to make the commercial abstraction trustworthy even when the underlying system is distributed and imperfect.
Correct Usage ≠ Profitable Usage
Now assume the system handles all of that correctly.
The customer is entitled to execute.
Authorization succeeds.
Ten credits are consumed exactly once.
Retries preserve the intended usage semantics.
Metering accurately describes what happened.
The research report is successfully delivered.
From a runtime-correctness perspective, the system behaved exactly as intended.
But return to our two customers:
Customer A
1 report
10 credits
Simple execution path
Lower cost-to-serve
Customer B
1 report
10 credits
Complex execution path
Higher cost-to-serve
Both executions can be commercially correct.
Both can be operationally correct.
Both can produce exactly the value the customer expected.
Their economics can still differ.
This is the third layer of the problem.
Correct usage tells us whether the commercial rules were executed reliably. It does not automatically tell us whether those rules produced healthy economics.
One useful way to reason about this distinction is:
Commercial Correctness
↓
Was the customer's commercial state represented correctly?
Runtime Correctness
↓
Was execution authorized, consumed and recorded correctly?
Economic Understanding
↓
What economics did that correct execution produce?
The final step should be treated carefully.
It does not imply that every request needs a real-time profitability calculation before it executes. Nor does it mean that an expensive workflow should automatically be blocked.
Some high-cost workflows produce substantial customer value. Some customers justify lower margins. Some execution costs can only be understood after the workflow completes. Some forms of value cannot be attributed cleanly to a single request at all.
The important point is narrower:
An execution can be correctly authorized, correctly consumed and correctly charged while still producing economics the business may want to understand.
That is where the relationship between our three units becomes especially useful.
The Value Unit tells us what the customer received.
The Commercial Unit tells us what allowance was consumed.
The Economic Unit tells us what producing that result required.
None of those facts alone is enough to describe the whole system.
What This Means for AI Builders
This framework does not produce a universal pricing model.
It does not tell every AI company to sell outcomes. It does not tell teams to replace credits with usage-based billing, or usage-based billing with subscriptions. It does not tell developers to expose infrastructure costs directly to customers.
Instead, it suggests a set of questions worth answering before choosing the abstraction.
What does the customer actually perceive as value?
For the research agent, that may be a completed report. For another product, value may be continuous, exploratory or difficult to reduce to one event.
The goal is to understand the customer's mental model before deciding whether an infrastructure unit should become a pricing unit.
What unit makes commercial allowance understandable?
Credits, runs, quotas or included usage can provide useful commercial boundaries.
The right abstraction depends on the product, the customer and the variability of the underlying execution.
The question is not whether credits are inherently good or bad. It is what responsibility they are supposed to serve.
What does execution really consume?
Which costs materially affect the economics of delivering the product?
For some systems, inference may dominate. For others, retrieval, tools, third-party APIs, retries, storage or human intervention may materially change cost-to-serve.
Not every cost needs perfect request-level attribution. The objective is enough visibility to explain economically meaningful variance.
How variable is cost-to-serve?
Can two customers consume the same Commercial Unit while generating very different execution costs?
If so, how frequently does that happen, how large is the variance, and does the broader commercial relationship compensate for it?
Which variance should the customer see?
Some infrastructure variability may belong in customer pricing.
Some may be better absorbed by the product.
A provider change, retry or internal routing decision does not automatically need to become a new concept the customer has to understand.
Which complexity should infrastructure absorb?
Every abstraction moves complexity somewhere.
A simple customer-facing pricing model can require more sophisticated internal measurement. A highly granular usage model can expose more infrastructure economics directly to the customer.
Neither approach is automatically correct.
The important thing is knowing where the complexity lives.
These questions lead to a different way of approaching AI monetization.
Instead of beginning with:
What is the perfect unit to charge for?
begin with:
Which unit describes customer value, which unit governs the commercial relationship, and which units describe the economics of execution?
Only then decide where those units should align — and where they should remain separate.
Closing — Three Units, One Economic System
Return to the research agent one last time.
The customer asks for a company analysis and receives:
1 Completed Research Report
That is the unit closest to the value they came to the product to receive.
The commercial system deducts:
10 Credits
That is the abstraction the product uses to represent allowance.
Underneath both, the runtime executes:
Retrieval
↓
Model Inference
↓
Search
↓
Tool Calls
↓
External API
↓
Retry
↓
Additional Inference
↓
Validation
↓
Storage
Those operations describe the economic reality of producing the result.
Three perspectives on the same interaction:
VALUE UNIT
What the customer values
1 Research Report
↓
COMMERCIAL UNIT
What the product allocates
10 Credits
↓
ECONOMIC UNIT
What execution consumes
Models + Tools + APIs + Retries + Infrastructure
The important insight is not that these units should always be different.
Sometimes they may align naturally.
A developer-facing API may expose consumption in a way customers already understand. A predictable workflow may have sufficiently stable execution costs that its Value Unit and Commercial Unit can closely correspond. Another product may deliberately expose infrastructure consumption because that transparency is useful to its customers.
The point is that alignment should be a design decision, not an assumption.
What the customer values, what the product sells or allocates, and what the infrastructure consumes are related — but they are not necessarily the same unit.
Once those units are separated conceptually, a different architecture becomes easier to reason about.
The customer does not necessarily need to understand every model call, retry, retrieval operation or provider cost.
The Commercial Unit can provide an understandable boundary.
The runtime can preserve that boundary during authorization and consumption.
And the economic layer can observe what fulfilling that commercial promise actually required.
Customer Value
↕
Commercial Model
↕
Runtime Execution
↕
Economic Reality
The challenge is not making every layer identical.
The challenge is maintaining a trustworthy relationship between them.
If the commercial layer says the customer has 10 credits, the runtime should be able to enforce that state correctly.
If the runtime records a workflow, the resulting usage data should describe what actually happened.
If the business later analyzes cost-to-serve, that analysis should be built on execution data it can trust.
This is where the distinction between monetization and billing becomes useful.
Billing establishes and records commercial events.
Runtime infrastructure has to carry those commercial decisions into the actual execution of the product.
And as AI execution becomes more variable, trusted runtime data can provide the foundation for understanding what those decisions eventually mean economically.
That progression can be summarized as:
Payment
↓
Commercial Correctness
↓
Runtime Correctness
↓
Economic Observability
↓
Economic Understanding
Each layer depends on the reliability of the one beneath it.
There is little value in sophisticated profitability analysis if the underlying usage data is wrong. There is little value in correct usage accounting if execution ignores the customer's commercial state. And a successful payment alone cannot guarantee either of those properties.
This is also the broader problem I'm currently investigating while building Licenzy.
Licenzy is being developed as an AI Monetization Runtime, focused on maintaining correctness between commercial state and runtime execution after payment.
That foundation is primarily about questions such as whether execution is authorized, whether allowance is consumed correctly and whether runtime behavior remains consistent with the commercial state of the customer.
Beyond that foundation, Runtime Intelligence / ProfitLens represents an evolving direction we're exploring: connecting trusted execution data with deeper visibility into customer, workflow and economic behavior.
The distinction matters.
Reliable execution is something infrastructure can enforce.
Economic understanding is more contextual.
A system should not pretend that every expensive workflow is unhealthy, that every low-margin customer should be blocked or that profitability can always be calculated perfectly at request level.
Those conclusions depend on information that may exist outside the runtime: revenue, retention, strategic value, customer behavior, product outcomes and costs that are difficult to attribute precisely.
So the immediate opportunity is not autonomous economic optimization.
It is better economic visibility built on trustworthy execution data.
And that brings us back to the three units.
VALUE UNIT
What does the customer value?
COMMERCIAL UNIT
What does the product allow?
ECONOMIC UNIT
What does producing it actually consume?
For some AI products, the three may remain relatively close.
For others, they may diverge significantly.
Neither situation is inherently wrong.
The important question is whether the business understands the relationship between them well enough to design its pricing, infrastructure and product deliberately.
Because the challenge ahead may not be finding one perfect unit for AI monetization.
It may be learning how to operate a product where several different units can all be correct at the same time.
And that leaves a broader question worth investigating:
How do you build and monetize software when every customer, every workflow, and even two executions of the same workflow can have different economics?
Before choosing your next pricing unit, there may be an even simpler question to ask:
Am I designing my AI product as if Value, Commercial and Economic Units were the same thing?
Top comments (0)