Nothing Changed in Your AI Product. Your Economics Did.

Imagine an AI research product that charges $1 for a completed report.

A customer, ACME, runs the same Research Report workflow throughout August. Each completed report consumes 10 credits.

For one representative execution, the economics look like this:

Now move forward to September.

ACME is still using the same product.

The customer requests the same kind of report. The workflow follows the same execution path. It consumes the same measured quantities of the underlying resources. The product still deducts 10 credits. The selling price is still $1.

Nothing about the customer-facing transaction appears to have changed.

But the economics now look like this:

On this deliberately simplified cost boundary, the amount remaining after the illustrated execution cost has fallen from 80% to 45% of revenue.

What changed?

Not the customer.

Not the selling price.

Not the commercial allowance.

Not the number of credits consumed.

For the purpose of this example, not even the execution quantities underneath the workflow.

An upstream provider changed the rate applied to one of the resources the workflow depends on.

The product did the same work.

That work became more expensive.

This is an easy possibility to miss when we reason about AI economics primarily through usage.

We often expect an increase in cost to have an operational explanation: more requests, more tokens, more tool calls, more retries, more customers.

Sometimes it does.

But quantity is only one side of the economic relationship.

Even a deliberately simplified model makes the distinction visible:

execution cost ≈ quantity consumed × applicable unit rate

If quantity remains stable while the applicable rate changes, the cost changes too.

same quantity
×
different rate
=
different cost

The important point is not that providers can change their prices. Software businesses have always depended on infrastructure, vendors, payment networks, APIs, labor, and other inputs whose economics can move independently of customer demand.

The more useful realization is this:

Product behavior can remain stable while product economics change.

And once that is possible, a second question appears.

If the economics of an AI product changed, how do we know what actually caused the change?

The credit ledger can be perfectly right

There is no billing bug in the example above.

ACME was supposed to consume 10 credits.

The product deducted 10 credits.

The commercial state is correct.

That fact tells us something important about the relationship between ACME and the product. It tells us how the product represented and governed the transaction commercially.

It does not tell us that the economics underneath those 10 credits remained constant.

This follows from a distinction we introduced in the previous Guide: the unit a product uses commercially does not have to reproduce the execution economics underneath it.

A credit can remain a perfectly valid commercial abstraction even as the cost of delivering what that credit represents changes.

In August:

10 credits
    ↓
same measured execution quantities
    ↓
applicable rates
    ↓
$0.20 illustrated execution cost

In September:

10 credits
    ↓
same measured execution quantities
    ↓
different applicable rates
    ↓
$0.55 illustrated execution cost

The credit ledger does not need to become incorrect for the economics to move.

That distinction matters because otherwise we risk asking a commercial system to answer an economic question it was never designed to answer.

Knowing that 10 credits were correctly consumed can tell us that the commercial rules were applied correctly.

It cannot, by itself, tell us whether the economics changed because more work was requested, the workflow executed differently, the commercial relationship changed, an underlying resource changed price, or the same execution produced fewer useful outcomes.

Those are different questions.

This is the deeper consequence of keeping commercial abstraction above and economic evidence below:

Commercial correctness does not, by itself, establish that the underlying economics remained unchanged.

Usage is only one variable

Suppose a dashboard tells you that the cost of the Research Report workflow increased in September.

A natural first question is:

Did usage increase?

That is a useful question.

It is not a sufficient explanation.

Imagine that request volume is unchanged.

You look one level deeper.

Token consumption is approximately unchanged too.

That rules out some explanations, but it still does not tell you what happened.

Perhaps retries increased while total customer demand remained stable.

Perhaps the workflow started routing some executions to a more expensive model.

Perhaps a paid search or tool dependency entered the execution path.

Perhaps the execution quantities were identical, but one provider changed its rates.

Perhaps nothing about execution cost changed at all, but a commercial discount reduced the revenue associated with the same work.

Or perhaps approximately the same amount was spent while fewer executions produced a successful result.

Each case can deteriorate the economics of the product.

But they do so for different reasons.

If demand increased, you are looking at a different problem from an increase in retries.

If an upstream rate changed, you are looking at a different problem from a pricing discount.

If successful outcomes declined, looking only at resource consumption may miss the change entirely.

This is why:

"Economics changed" is an observation. It is not yet an explanation.

Before deciding what should change, we first need a better question:

Which part of the economic relationship moved?

Five dimensions of economic change

A practical way to investigate that question is to stop treating "cost went up" or "margin went down" as a single type of event.

Instead, ask which dimension moved.

For many AI product investigations, five dimensions provide a useful starting point:

                    ECONOMICS CHANGED
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
     DEMAND            EXECUTION          COMMERCIAL
        │                  │                  │
        └────────────┬─────┴─────┬────────────┘
                     │           │
                    RATE       OUTCOME

This is not meant to be an exhaustive taxonomy of every possible economic cause, and the dimensions are not mutually exclusive. A provider rate can change during the same period that retries increase or customer demand falls.

The framework is more useful as a set of diagnostic questions:

• Did the amount of customer-requested work change?
• Did the execution required to deliver it change?
• Did the commercial relationship change?
• Did the price of an underlying resource change?
• Did the amount of useful outcome produced by the execution change?

Those questions separate changes that can look similar in aggregate but mean very different things underneath.

Demand: did the amount of requested work change?

This is the most intuitive explanation for changing economics.

ACME generated 1,000 reports last month and 1,500 this month.

Nothing necessarily became more expensive per report. There was simply more customer-requested work to execute.

August                         September

Reports requested   1,000     Reports requested   1,500
Cost per report     $0.20     Cost per report      $0.20

Total cost          $200      Total cost           $300

Total cost increased by 50%.

But the economics of delivering an individual report did not necessarily deteriorate.

This distinction already shows why "AI costs increased" is incomplete information. Higher aggregate spend can reflect growth rather than worsening unit economics.

The question here is whether economics moved because the product was asked to deliver more work.

If not, we need to look elsewhere.

Execution: did delivering the work require something different?

Now imagine customer demand remains stable.

ACME requests the same number of reports, but the runtime path changes.

Perhaps retrieval requires more searches. Context becomes larger. A model fails and requests are retried. Some reports are escalated to a different model. An additional validation step enters the workflow.

The customer can still see the same unit of value and consume the same commercial allowance while more—or simply different—work happens underneath.

Here the applicable rates may be completely unchanged.

What moved was the shape or quantity of execution required to deliver the work.

The relevant question is whether the runtime did different work to produce the customer-visible result.

This is closely related to the execution variability discussed in the Three Units model, but it is only one possible explanation.

Our opening scenario showed another.

Commercial: did the economics of the customer relationship change?

Suppose demand remains stable.

Execution remains stable.

Provider rates remain stable.

But ACME receives a larger discount at renewal.

The system performs the same work at approximately the same direct execution cost, while the revenue associated with that work decreases.

August                         September

Revenue/report      $1.00     Revenue/report      $0.75
Execution cost      $0.20     Execution cost      $0.20

Nothing became more expensive to execute.

The commercial side of the relationship changed.

The same principle can apply when a product changes included allowances, credit conversion rules, plan structure, negotiated terms, or other commercial conditions that alter how revenue relates to delivered work.

Economic investigation therefore cannot stop at infrastructure cost. A deterioration can originate above the execution layer too.

Here the question is whether the commercial relationship moved while the underlying execution remained stable.

Rate: did the same resource become more or less expensive?

This is what happened in our opening scenario.

The amount of requested work remained stable.

The measured execution quantities remained stable.

The commercial relationship remained stable.

But the rate applied to an underlying resource changed.

Conceptually:

August

100 units × Rate A = $0.20

September

100 units × Rate B = $0.55

The workflow did not need to consume more of the resource for its economics to change.

The resource itself became more expensive.

The reverse is equally possible. If an underlying rate falls while the rest of the system remains stable, the economics can improve without any optimization to the workflow.

This matters in AI systems because execution may depend on several independently priced resources: model providers, search services, external APIs, infrastructure, or paid tools.

But the phenomenon is not unique to AI. Any software business that depends on variable-cost external inputs can experience it.

The question is whether the price of something underneath the execution changed.

Outcome: did the same execution produce the same amount of useful result?

The fifth dimension is slightly different from the first four.

Imagine 100 executions cost $100 in August.

All 100 produce whatever the product defines as a successful outcome.

$100 execution cost
÷
100 successful outcomes
=
$1 per successful outcome

In September, the system still performs 100 executions and still spends approximately $100.

But only 50 produce a successful outcome.

$100 execution cost
÷
50 successful outcomes
=
$2 per successful outcome

Total execution cost did not increase.

The amount of useful result produced by that spend decreased.

It also introduces a difficult question: what exactly counts as a successful outcome?

For some products, that may be a deterministic business event. For others, success may depend on customer confirmation, human review, downstream conversion, or another signal that is harder to observe.

We do not need to solve that problem here.

For this framework, the important point is narrower:

Stable spend does not necessarily imply stable economics per useful outcome.

The question is whether execution produced a different yield of useful outcomes.

Taken together, the five dimensions give us a more useful starting point than "usage went up":

The categories can interact.

More demand can expose a failure mode that increases retries. A routing change can alter both execution quantities and the effective mix of provider rates. A commercial change can happen while a provider simultaneously changes pricing.

The purpose of the framework is not to force every economic change into exactly one box.

It is to prevent one observable metric from becoming the explanation by default.

Same economic change. Different causes.

Return to the Research Report workflow.

Suppose all we know is that its economics deteriorated.

Several very different histories could sit underneath that observation:

These can all appear as some form of economic deterioration.

They are not the same event.

A provider rate change is not a retry problem.

A retry problem is not a pricing problem.

A pricing problem is not an outcome problem.

Even if they eventually affect the same economic metric, the mechanisms that produced the change are different.

This gives us a useful separation:

OBSERVATION

"The economics of this workflow deteriorated."

                ↓

CAUSE

"What changed underneath?"

The first tells us that something deserves attention.

The second requires investigation.

And that is where simple economic visibility reaches an important boundary.

"Margin fell" is an observation, not an explanation

Suppose a system can tell us:

The economics of ACME's Research Report workflow deteriorated in September.

That is useful.

Now suppose it can narrow the change further:

Most of the deterioration is associated with ACME's Research Report executions.

That is more useful.

But we still do not know why it happened.

There are at least three distinct reasoning steps here:

OBSERVE

What happened?

Economics deteriorated.
        ↓
ATTRIBUTE

Where did it happen?

ACME / Research Report.
        ↓
EXPLAIN

What changed underneath?

?

Attribution narrows the location of the change.

It does not necessarily explain its cause.

To fill in the final step, we need to distinguish between competing explanations.

Did demand increase?

Did execution behavior change?

Did commercial terms change?

Did an applicable rate change?

Did outcome yield change?

Or did several of them move together?

A chart showing that cost increased cannot answer those questions by itself.

Neither can a customer profitability number.

Both can tell us where investigation should begin.

Explanation requires something more: enough evidence about the state of the system before and after the change to determine what actually moved.

The provider-rate example shows why historical context becomes part of that problem.

Economic explanation needs historical context

Return one last time to the provider-rate scenario.

We know that the Research Report workflow became more expensive in September.

We suspect that an underlying rate changed.

To support that explanation, knowing the provider's price today is not enough.

Suppose we inspect an execution from August and find that it consumed 100 units of some underlying resource.

Today, that resource costs $0.0055 per unit.

It would be tempting to reconstruct the execution like this:

Historical execution

100 units
×
today's rate: $0.0055
=
$0.55

But that calculation answers a different question:

What would those historical quantities cost under today's rate?

It does not necessarily tell us what they economically represented when the execution occurred.

If the applicable rate in August was $0.0020, then the historical valuation on our simplified boundary would instead be:

August execution

100 units
×
applicable August rate: $0.0020
=
$0.20

And a comparable September execution could be:

September execution

100 units
×
applicable September rate: $0.0055
=
$0.55

Now the explanation becomes visible:

Quantity       unchanged
Rate           changed
Cost           changed

The distinction sounds obvious once the two executions are placed side by side.

Reconstructing it later may not be.

The current state of a provider's pricing page does not necessarily describe the pricing context that applied to a historical execution.

And time alone may not determine the rate. Pricing can also depend on model, provider, region, tier, negotiated terms, committed usage, or other commercial conditions.

So the relevant question is not simply:

What is the provider's rate?

It is:

Which rate was applicable to this execution under the relevant pricing context?

That is a historical-state problem.

And rates are only one example.

If the suspected explanation is that retries increased, we need evidence about execution behavior before and after the change.

If commercial terms changed, we need the relevant commercial context.

If outcome yield deteriorated, we need some defensible representation of the outcomes produced.

The explanation determines which evidence matters.

No explanation without evidence

Consider the difference between these two statements:

ACME's Research Report economics deteriorated in September.

and:

ACME's Research Report economics deteriorated because the applicable provider rate increased while measured execution quantities remained stable.

The second statement is much more useful.

It is also a much stronger claim.

To support it, we need evidence for both sides of the comparison.

Conceptually, that might include:

EXECUTION
    │
    ├── When did it happen?
    ├── Which provider / model / resource was used?
    ├── What quantity was measured?
    ├── Which rate was applicable?
    ├── What commercial value was associated with it?
    └── What outcome was produced?

Not every investigation needs every piece of information in that list.

A simple rate-change investigation may require only a subset. An outcome investigation may require evidence that a provider-cost investigation does not.

The point is not to collect every possible economic fact about every execution.

It is to preserve enough relevant evidence that an explanation can be distinguished from a guess.

This gives us a useful engineering principle:

No explanation without evidence.

That principle becomes especially important when explanations are generated automatically.

An LLM can produce a plausible narrative from a set of metrics.

Plausibility is not the same thing as evidence.

If a system says:

"Margin deteriorated because provider costs increased."

the important question is not how convincing the sentence sounds.

It is whether the system can show the facts that support it.

Did the measured quantities remain stable?

Did the applicable rate actually change?

Was that rate associated with the relevant resource and pricing context?

Were there execution changes that could provide an alternative explanation?

The relationship should therefore look more like this:

OBSERVATION
     ↓
ATTRIBUTION
     ↓
EXPLANATION
     ↑
 EVIDENCE

Evidence is not the final narrative step.

It is the foundation that makes the later claims defensible.

The alternative is much weaker:

METRICS
    ↓
PLAUSIBLE STORY

This does not mean economic explanation requires AI.

Whether the explanation is produced by a human, a query, a rules engine, a statistical system, or an AI model, the claim should remain grounded in the underlying evidence.

Why this gets harder in AI products

None of these problems is unique to AI.

Software companies have always depended on changing infrastructure costs, external vendors, commercial terms, and variable customer demand.

AI products can make the investigation more layered because one customer-visible action may depend on several independently changing components.

A research report might involve:

customer request
      ↓
retrieval
      ↓
model A
      ↓
search provider
      ↓
external API
      ↓
model B
      ↓
validation
      ↓
completed report

Each component can introduce its own measured quantities, execution behavior, rates, and historical context. The workflow itself can change while commercial terms and outcome yield move independently above and around it.

This is why one aggregate number can be economically useful without being economically explanatory.

A cost view can tell us that spend moved.

A customer-level view can tell us where deterioration is concentrated.

A workflow-level view can narrow the investigation further.

Those are valuable steps.

But eventually the question becomes causal:

What changed underneath?

The question after visibility

We started with an apparently simple contradiction.

ACME requested the same kind of report.

The product charged the same price.

The commercial system deducted the same 10 credits.

The workflow consumed the same measured quantities.

Yet the illustrated direct execution cost moved from $0.20 to $0.55.

The explanation was not more usage.

An underlying rate changed.

But provider repricing was only one example.

Across an AI product, economics can move because demand changes, execution changes, commercial terms change, rates change, or the relationship between execution and useful outcomes changes.

Sometimes several move together.

The progression is therefore not simply from more metrics to more certainty.

It is from observing a change, to locating it, to asking what changed underneath—and requiring evidence strong enough to support the answer.

Seeing the change tells you where to look. Evidence tells you what changed.

And before asking what the product should do about deteriorating economics, a more fundamental question comes first:

Can we show what changed underneath—and the evidence that supports that answer?

References

• Anthropic, Introducing Claude Sonnet 5. A real-world example of explicitly time-bounded introductory API pricing whose planned transition to standard rates was later withdrawn when the introductory rates were made permanent.
• OpenAI, Advancing the price-performance frontier with GPT-5.6. A recent example of API model rates decreasing rather than increasing.
• OpenStax, Principles of Accounting, Volume 2: Managerial Accounting — Contribution Margin. Reference for the distinction between contribution margin and the deliberately narrower execution-cost boundary used in this Guide.