Your AI Product Has Three Different Units: Value, Commercial, and Economic

An AI product can make a transaction look deceptively simple.

A customer asks an AI research product to produce a report. The product deducts 10 credits. A few minutes later, the report is ready.

From the customer's perspective, the interaction might be summarized as:

1 research report → 10 credits

That relationship is useful. The customer receives something recognizable, and the product has a clear way to represent its commercial consumption.

But those 10 credits are doing only one job.

They tell us how the product chose to represent the transaction commercially. They do not necessarily tell us how much work the system performed, which resources were consumed, or what it economically took to produce the report.

One report might complete after a small number of model calls and searches. Another might require substantially more retrieval, several tool calls, an external API, multiple retries, and additional validation before producing an equivalent result.

The customer can still receive one report.

The product can still deduct 10 credits.

The underlying economics can be very different.

This distinction matters because an AI product operates across at least three separate concerns:

Value Unit — what recognizable unit of value or work the customer cares about.

Commercial Unit — what the product counts, allocates, deducts, or bills.

Economic Unit — the unit of execution whose economics the business wants to understand.

These are not necessarily three different physical units in every product. A product may deliberately make two of them coincide. An API, for example, might expose an infrastructure-oriented unit directly as its Commercial Unit.

The important distinction is not that the three units must always be different.

It is that they answer different questions.

Understanding those questions separately gives us a better model for reasoning about AI pricing, runtime execution, and the economics underneath both.

Three units, three different questions

Consider the research product again.

The customer wants a completed research report. That is the recognizable result they care about.

The product might decide that generating one report consumes 10 credits. Credits provide a commercial abstraction that can be packaged into plans, allocated to customers, deducted during usage, or replenished independently of the implementation underneath.

Producing the report, however, is an execution problem.

The system may need to call one or more models, retrieve context, search external sources, invoke tools, call third-party APIs, validate intermediate results, retry failed operations, and persist data.

We can therefore look at the same product through three different questions:

The last row is important.

The Economic Unit is not itself a single infrastructure resource. It defines the execution whose economics we want to reason about. Economic Evidence describes what actually happened underneath that execution.

For one report delivery, that evidence might include model inference, retrieval operations, search and tool calls, external APIs, retries, validation, storage, and other resources required by that particular workflow.

Not every AI workflow contains all of these components, and their relative importance can vary substantially between products.

The distinction is therefore not:

customer-facing units are simple, so they are inaccurate.

A better way to think about it is:

customer-facing units and execution-level evidence exist for different purposes.

That becomes clearer when we look at each unit separately.

Value Unit: what does the customer actually care about?

Start from the customer's perspective rather than the infrastructure.

Someone using an AI research product probably does not open it because they want to consume 40,000 tokens, perform eight retrieval operations, or trigger six search calls.

They want research.

More specifically, they might want a completed report they can read, evaluate, share, or use to make a decision.

For that product, a completed report can therefore be a useful Value Unit: a recognizable unit of work that represents what the customer is trying to obtain.

This does not mean that every AI product has a clean outcome such as a report, resolved ticket, or processed document. Value can be continuous, subjective, collaborative, or difficult to reduce to a single event. A developer using a model API may also care directly about access to compute or granular consumption rather than a higher-level business outcome.

Nor does identifying a Value Unit tell us how the product should charge for it.

That distinction is important.

In SaaS pricing, the term value metric is often used for the metric that determines how customer usage maps to price. We are using Value Unit differently here: to describe the recognizable unit of value or work the customer cares about. A product may choose to use that same unit commercially, but it does not have to.

A research product could therefore recognize the completed report as its Value Unit while selling subscriptions containing credits.

Another product could charge directly per report.

Another could meter usage more granularly.

Those are commercial design decisions.

The Value Unit answers an earlier question:

What is the customer ultimately trying to get from this system?

Once that is separated from how the product charges for it, the role of the Commercial Unit becomes much easier to understand.

Commercial Unit: abstraction is a feature

Suppose the research product decides that one standard report consumes 10 credits.

It would be easy to criticize the credits because they do not correspond exactly to the infrastructure consumed by every report.

But that would miss the purpose of the abstraction.

A Commercial Unit does not necessarily need to reproduce the internal economics of the system. It needs to provide a useful representation for the commercial relationship between the product and the customer.

Credits can allow a product to package different kinds of work into a common allowance. They can make plans easier to reason about, provide customers with a visible balance, and allow the product to change some implementation details without exposing every underlying infrastructure unit.

The same principle applies beyond credits.

A Commercial Unit might be an API request, an included run, a processed document, a seat with a usage allowance, a minute, a token, a task, or the outcome itself.

The right abstraction depends on the product.

This is why the distinction between Value Unit and Commercial Unit matters.

A product does not have to expose every internal resource simply because that resource contributes to cost. Conversely, it does not have to charge directly for the customer-visible outcome simply because that outcome represents value.

Commercial design can intentionally sit between the two.

For the research product:

Value Unit: 1 completed report
Commercial Unit: 10 credits

There is nothing inherently inconsistent about that relationship.

The more interesting question is what happens underneath it.

Because while commercial abstraction can simplify what the customer sees, it does not make the underlying execution uniform.

Economic Unit: what did delivering the value actually require?

The Commercial Unit tells us that 10 credits were consumed.

It does not necessarily tell us what happened to produce the report.

That is a different question.

An AI workflow is rarely a single indivisible operation. What appears to the customer as one action can expand into a sequence of model calls, retrieval operations, searches, tool invocations, API requests, validation steps, retries, and persistence operations.

The Economic Unit gives us a boundary around the execution whose economics we want to understand.

For our research product, that could be one report delivery.

Underneath that unit sits the Economic Evidence produced by the execution:

• model inference and token consumption;
• retrieval operations;
• search requests;
• tool calls;
• third-party API usage;
• retries;
• validation or evaluation steps;
• storage;
• infrastructure consumption.

Depending on the product, the economic envelope may extend further. Some workflows may require human review, manual intervention, rework, or other operational resources. Others may consist almost entirely of inference.

The point is not that every AI product needs to measure every possible cost component.

The point is that the commercial event alone does not necessarily describe the execution that produced it.

This is also why model tokens, despite being an important infrastructure unit, should not automatically be treated as a complete representation of AI product economics.

For some products, tokens can be a perfectly reasonable Commercial Unit. This is especially natural when customers themselves want granular control over model consumption.

But tokens answer a specific consumption question.

They do not necessarily tell us how much retrieval occurred, how many paid tools were invoked, whether an external API was called, whether the workflow retried three times, or whether additional validation was required before the result became usable.

And they do not necessarily represent what the customer ultimately considers valuable.

Tokens are an infrastructure unit, not necessarily a customer outcome.

The distinction becomes much more important once two apparently identical commercial events take different paths through the runtime.

Same report. Same 10 credits. Different economics.

Consider two customers asking the research product for comparable reports.

From the commercial system's perspective, the two executions look identical:

Both customers received the expected result.

Both consumed the same commercial allowance.

Now look underneath that abstraction.

Report A follows a relatively direct execution path.

The system performs a few searches, retrieves relevant context, makes several model calls, validates the generated result once, and completes successfully.

Conceptually:

Report B reaches an equivalent customer-facing result, but its path is less direct.

Perhaps the initial retrieval produces insufficient context. Additional searches are required. One external source is accessed through a paid API. A model call fails transiently and must be retried. The first generated result does not pass validation, causing part of the workflow to execute again before the final report can be delivered.

Its path might look more like this:

The exact numbers are not important, but the difference can be represented more concretely:

These numbers are illustrative, not a claim about what a typical AI research workflow requires.

What matters is the shape of the problem.

At the customer layer:

same value.

At the commercial layer:

same consumption.

At the execution layer:

different behavior.

And therefore, potentially:

different economics.

Nothing about this means that Report B should necessarily cost the customer more.

That would collapse the distinction we have just established.

A product may intentionally decide that both reports should cost 10 credits. Stable commercial abstraction can be valuable precisely because customers do not need to absorb every variation in the system's internal execution.

The business, however, faces a different problem.

If it sees only:

Report completed
Credits consumed: 10

then both executions are indistinguishable.

If it can also observe what happened underneath:

Report A
├── model execution
├── retrieval
├── search
└── validation

Report B
├── additional model execution
├── additional retrieval/search
├── external API usage
├── retries
├── rework
└── additional validation

it can begin to understand why two commercially equivalent events may have different economic characteristics.

That distinction becomes increasingly important as AI products move from simple model calls to workflows composed of models, retrieval systems, tools, external services, and failure-recovery paths.

The customer does not necessarily need any of this complexity exposed to them.

The business does.

The Commercial Unit should not have to explain the runtime

There is a tempting conclusion at this point.

If 10 credits hide meaningful variation underneath, perhaps the credits should become more granular. Maybe Report A should cost 8 credits and Report B should cost 17.

But that does not follow automatically.

Doing so would ask the Commercial Unit to solve a problem that belongs to another layer.

Commercial units exist to structure the commercial relationship. Economic evidence exists to describe what happened during execution.

Sometimes the two should be closely connected. Sometimes they should deliberately remain separated.

Imagine that the research product improves its retrieval architecture and reduces the average amount of inference required to produce a report. If customer value remains unchanged, the company may have no reason to modify the 10-credit price simply because its implementation became more efficient.

The reverse can also happen. A provider price changes, a workflow begins using a more expensive model, or a new validation step improves reliability while increasing execution cost.

None of those changes necessarily requires an immediate change to the customer-facing Commercial Unit.

Understanding cost is an input to commercial decision-making, not necessarily the formula for pricing.

This separation gives the product room to optimize its implementation, evolve its architecture, and make commercial decisions independently.

But independence does not mean ignorance.

The commercial layer can remain abstract only if the business has another way to understand what is happening underneath it.

Why separating the units matters

Separating Value, Commercial, and Economic Units is not just a cleaner way to describe pricing.

It changes which questions an AI product can ask about itself.

When the three concerns are collapsed into one number, changes at one layer can easily be mistaken for changes at another. More credits consumed may look like more value delivered. Higher token usage may look like higher customer usage. Stable commercial consumption may look like stable economics.

None of those relationships is guaranteed.

Keeping the units conceptually separate makes it possible to reason about product usage, runtime execution, and economics without assuming that one metric explains all three.

Product usage is not the same as economic behavior

Imagine that the research product delivers 10,000 reports in one month and 10,000 reports the next.

At the Value Unit level, activity appears stable.

Suppose it also consumes the same number of customer credits in both months.

At the Commercial Unit level, activity still appears stable.

But underneath those numbers, the runtime may have changed significantly.

Perhaps more reports required retries. Perhaps retrieval became less efficient. Perhaps a larger share of requests was routed through a more expensive model. Perhaps a third-party API became part of the execution path.

Or perhaps the opposite happened: the product became substantially more efficient while delivering the same amount of customer-visible work.

Neither change is necessarily visible from the Value or Commercial Unit alone.

The economic consequence can be significant. Margin can change while customer-visible usage and commercial consumption remain stable.

That does not automatically mean the workflow is inefficient. A more expensive execution path may produce better reliability, higher-quality results, or another benefit that justifies its cost.

The separation simply allows the business to see that there is a question worth investigating.

Runtime execution needs its own evidence

This distinction also has an architectural consequence.

Commercial systems are good at representing commercial state.

They can tell us that a subscription is active, a customer has 120 credits remaining, a particular operation consumed 10 credits, or an allowance has been exhausted.

Those facts matter.

But they describe the commercial relationship.

The execution layer answers different questions.

What actually ran?

Which model or execution path was used?

Which external resources were invoked?

Did part of the workflow fail?

Was anything retried?

What evidence was produced while delivering the result?

A commercial event such as:

10 credits consumed

cannot be expected to reconstruct all of that information after the fact.

If those details matter economically, they need to exist as execution-level evidence rather than being inferred solely from the commercial transaction.

This does not mean every product needs exhaustive telemetry for every operation.

The appropriate level of evidence depends on the architecture, the variability of the workflow, and the economic questions the business actually needs to answer.

But the conceptual boundary remains useful:

commercial state tells you what was commercially allowed or consumed; execution evidence tells you what actually happened.

Commercial abstraction above. Economic truth below.

The customer should not have to reason about every internal operation required to produce useful work.

That complexity belongs inside the product.

A customer may reasonably think in terms of:

reports
tasks
runs
credits
included usage
outcomes

while the system underneath operates through:

inference
retrieval
tools
external APIs
retries
validation
storage
infrastructure

Those two views do not need to be identical.

In many cases, they probably should not be.

The commercial layer exists partly to create a stable and understandable abstraction over a more complicated implementation.

But abstraction creates a responsibility.

Once the customer-facing representation no longer mirrors the execution directly, the business cannot rely on that representation alone to understand what the runtime is doing.

This gives us the deeper principle behind the three-unit model:

Commercial abstraction above. Economic truth below.

The word truth here does not imply that every possible cost can always be measured perfectly.

Real systems have incomplete data, shared infrastructure, attribution problems, delayed costs, and resources that are difficult to assign precisely to an individual execution.

The principle is simpler than that.

The commercial abstraction should not be mistaken for the underlying execution.

The closer a business wants to get to understanding its actual AI economics, the more it needs evidence from what happened beneath that abstraction.

A useful way to summarize the relationship is:

The customer does not need to see this entire stack.

The business does need enough evidence to understand what happened underneath.

Or, as a useful design principle:

Your customer shouldn't need to understand your AI economics. Your runtime does.

The questions underneath the abstraction

Once Value, Commercial, and Economic Units are separated, the interesting questions move deeper into the system.

If two commercially identical executions consume different resources, what caused the difference?

If a workflow fails before producing customer value, where does the cost of that failed execution belong?

If retries eventually produce a successful outcome, should their cost be considered part of delivering that outcome?

If a model change reduces inference cost but increases retries, did the economics actually improve?

If multiple models, tools, APIs, and infrastructure components contribute to one result, how should their economic impact be attributed?

And if margin changes while customer usage appears stable, what changed underneath?

Those questions cannot be answered simply by choosing a better pricing unit.

They require us to understand the relationship between commercial state and runtime execution.

That is why the three-unit model is useful.

It does not prescribe whether an AI product should charge by credits, tokens, subscriptions, usage, workflows, or outcomes.

It provides a way to reason about what each of those choices represents—and what it does not.

For the research product, the relationship remains simple at the surface:

1 completed report
10 credits

Underneath, the execution may vary every time.

Both views can be correct.

They are simply describing different parts of the system.

Value tells you what matters to the customer.

Commercial tells you what the product counts.

Economic tells you which execution you need to understand—and the evidence underneath tells you what delivering it required.

Keeping those questions separate is the first step toward understanding what your AI product is actually doing beneath the price.

References

• Stripe — A framework for pricing AI products — distinguishes consumption-based, workflow-based, and outcome-based charge metrics, including the different relationships they have with infrastructure cost and customer value.
• Stripe — SaaS pricing and packaging strategy: Choosing the right model, metric, and tier structure — uses value metric to describe the unit customers pay for as they grow, which is why this Guide distinguishes that established pricing usage from the broader concept of a Value Unit.