Your AI Cost Calculation Can Be Correct — and Still Be Historically Wrong

Imagine an AI workflow that ran on August 10.

The execution completed successfully. The system recorded 100 units of usage for Model X, and the provider rate applicable at the time was $0.002 per unit.

The valuation was straightforward:

100 units × $0.002 = $0.20

A few weeks later, the provider changes its rate from $0.002 to $0.0055 per unit.

Nothing about the August execution changes. It still consumed 100 units. The model is still correctly identified. The execution timestamp is still there. Every measurement we stored is accurate.

Then, in September, we want to analyze the economics of that historical execution.

Our system retrieves the 100 units, looks up the current rate for Model X and calculates:

100 units × $0.0055 = $0.55

The query works. The formula is correct. The decimal arithmetic is correct. The usage measurement is correct.

And the answer is historically wrong.

That execution did not represent $0.55 under the economic conditions that applied when it occurred. We have taken an accurate historical measurement and interpreted it using a different economic context.

The interesting part isn't the multiplication. It's the assumption hidden behind it.

If a system stores what an AI execution consumed but not enough information to determine which rate or pricing policy applied at the relevant point in time, then accurate usage does not necessarily give us accurate historical economics.

I've been thinking about this while working on AI monetization infrastructure because I initially treated measurement as the difficult part: preserve reliable usage now, and you can reason about its economics later.

I'm becoming less convinced that this is enough.

The deeper problem seems to be temporal. If rates, pricing policies and other economic conditions can change independently from the execution itself, reconstructing the past requires more than knowing what happened.

We also need to know which economic context belonged to it.

---

Usage History Is Not Economic History

The example exposed a distinction I had been treating too casually: measurement and valuation are not the same fact.

A measurement records an observed quantity associated with an execution. In our example, Model X consumed 100 units. That fact can remain perfectly stable over time.

A rate or pricing policy answers a different question: how should those 100 units be valued under the economic conditions that applied to them? In the simplest case, that might be a single price per unit. In a real system, the policy could be more complex, but the separation still matters.

The valuation is what we get when the two are connected:

Measurement
100 units
    +
Applicable rate
$0.002 / unit
    ↓
Valuation
$0.20

This means $0.20 is not simply another measurement produced by the execution. It is a derived economic amount whose meaning depends on both the measured quantity and the rate or policy used to interpret it.

The execution from August can remain immutable:

execution_id: research-report-123
model: Model X
quantity: 100 units

while the economic rules around Model X evolve:

before September 1: $0.002 / unit
from September 1:   $0.0055 / unit

If we preserve only the measurement, we know what was consumed but may lose the context required to value it historically. If we preserve only the final $0.20, we retain an answer but not necessarily enough information to reproduce why that answer was correct.

So I'm starting to think about historical execution economics as at least three separate pieces:

Measurement — what quantity was observed?

Rate or policy — how should that measurement be valued under the applicable economic context?

Valuation — what economic amount results from connecting the two?

There is a fourth piece that becomes important later: the lineage connecting them. If I look at $0.20 months from now, can I determine which measurement produced it and which rate version was applied?

That is where this stops being only a cost-calculation problem.

Because once rates can change, pricing itself has a history.

---

Pricing Has Time

Once measurement and valuation are separated, the next problem is deciding which rate belongs to which execution.

A typical pricing lookup might start with something conceptually simple:

getRate(provider, model)

That works if we only care about the rate that applies now. Historical reconstruction asks a different question:

getRate(provider, model, executionTime)

The difference looks small in code, but it changes what the data model needs to represent. A rate is no longer just a property of a provider or model. It is a versioned economic rule with a period during which it applies.

For our running example, we might represent the history like this:

Model X

$0.002 / unit
effective from: August 1
effective until: September 1

$0.0055 / unit
effective from: September 1

The August 10 execution should therefore be valued using the first rate because its occurrence falls inside that rate's effective period:

execution.occurred_at
        ↓
2026-08-10
        ↓
applicable rate version
        ↓
$0.002 / unit

This is where the concept of effective time becomes useful. It describes when a fact or rule is applicable in the domain, rather than simply when we happened to store it in our database.

That distinction matters because those moments do not always coincide. A provider might announce a pricing change today that becomes effective next month. Or we might learn today about a pricing correction that should have applied to executions from last week.

So an execution timestamp and a rate's effective period answer different questions. occurred_at tells us when the execution happened. effective_from and effective_to tell us when a particular economic rule applies.

We do not need a sophisticated temporal database to understand the basic requirement. At minimum, the lookup has changed from asking:

What is the rate for Model X?

to asking:

Which version of the rate for Model X
was applicable when this execution occurred?

This kind of temporal modeling is not new, and it certainly isn't unique to AI. Effective dating and temporal data have been used for years in domains where prices, contracts, policies or other facts change over time.

What makes it interesting in AI execution economics is how easily the temporal relationship can disappear. We may preserve detailed usage for model calls and tool invocations while keeping only the current version of the economic rules used to interpret that usage.

At that point, we haven't necessarily lost the execution history. We've lost part of the context required to understand what that history meant economically.

That raises the architectural question I find more useful than simply asking whether usage is stored:

What is the minimum economic context that needs to survive with an execution if we want to reconstruct its valuation later?

---

What Has to Survive?

A naive implementation can look completely reasonable.

We record the execution, identify the provider and model, and persist the measured usage:

EXECUTION
execution_id
occurred_at
provider
model
usage

When we need a monetary amount later, we retrieve the usage and combine it with the provider's price.

For current analytics, that may be enough. The problem appears when we expect the same data to answer historical questions after the economic rules have changed.

One way to reason about a more reconstructable model is to stop treating execution, measurement, rate and valuation as one record:

EXECUTION
execution_id
occurred_at
provider
model

      ↓

MEASUREMENT
measurement_id
execution_id
component
quantity
unit

      ↓

RATE_VERSION
rate_version_id
provider
model
component
effective_from
effective_to
rate
currency

      ↓

VALUATION
valuation_id
measurement_id
rate_version_id
amount
currency
calculated_at

This is not meant as a universal schema. Different providers, pricing models and products will require different representations. What matters to me is the relationship between the records.

The execution gives the work a stable identity and a point in time. The measurement preserves the observed quantity. The rate version preserves the economic rule that was applicable. The valuation connects a specific measurement to a specific version of that rule.

For the August execution, that gives us a lineage we can inspect later:

research-report-123
        ↓
measurement-42
100 units
        ↓
rate-version-7
$0.002 / unit
        ↓
valuation-91
$0.20

Now $0.20 is not an isolated number in an analytics table. We can answer why it exists.

If someone asks six months later why that execution was valued at $0.20 rather than $0.55, the system does not need to infer the answer from whatever pricing configuration happens to exist at that moment. It can follow the relationship back to the measurement and the economic rule used to produce the valuation.

There are some less visible details that matter here too. Monetary amounts and rates should use exact decimal representations rather than floating-point arithmetic. Currency needs to be explicit. A rate needs enough dimensions to identify what it actually prices — potentially provider, model, component and unit — rather than assuming that a model name alone determines the economic rule.

But I don't think the goal should be to preserve every piece of pricing configuration forever just because we might need it someday. The more useful principle seems narrower:

Preserve enough context to reproduce why a historical economic amount was associated with a particular execution.

That still leaves an obvious shortcut.

Why not calculate $0.20 when the execution happens, store the final amount, and forget about all this lineage?

That works better than recalculating old usage with today's rate.

But it creates a different problem.

---

Why Storing the Final Valuation Isn't Enough

The obvious alternative is to calculate the valuation immediately.

When the August execution happens, we already know the measurement and the rate that applies at that moment:

100 units × $0.002 = $0.20

So instead of reconstructing the amount months later, we persist $0.20 and treat that as the historical valuation of the execution.

That solves an important part of the problem. A future rate change can no longer silently turn the August valuation into $0.55.

But it also raises a different question: what exactly does the stored $0.20 prove?

If all we retain is:

execution_id: research-report-123
valuation: $0.20

then we know the result of a calculation, but we may no longer know how that result was produced.

Compare that with:

measurement-42
100 units
      ×
rate-version-7
$0.002 / unit
      ↓
valuation-91
$0.20

The monetary amount is identical in both cases. The difference is that the second representation preserves the reasoning path behind it.

That distinction matters when someone eventually asks a question that the final number cannot answer on its own.

Was $0.20 derived from measured usage or imported from another source? Which rate version was used? If the amount later changes, did the underlying measurement change, did the applicable rate change, or did we simply learn something new?

A stored result is useful.

A stored result with lineage is investigable.

This reminds me of the distinction I explored in my previous article about what an AI runtime should remember. Preserving the final state of an execution is not always enough to reconstruct the path that produced it.

The same idea appears here at the economic layer:

Execution
    ↓
Measurement Evidence
    ↓
Applicable Rate Version
    ↓
Derived Valuation

Each relationship reduces how much we need to infer later.

This doesn't mean every derived amount needs an elaborate audit system around it. The amount of lineage worth preserving depends on what the product needs to explain, reproduce or reconcile.

But if historical economics matters, storing only the final number creates a new kind of information loss. We have protected the result from future repricing while discarding some of the evidence that made the result meaningful.

And even complete lineage doesn't make history static.

Sometimes the information we had when we created the valuation turns out not to be the information we have later.

---

Then Corrections Arrive

So far, I've assumed that the information available when we calculate a valuation is correct and final.

Production systems are rarely that convenient.

Imagine that the August execution was initially valued at $0.20 from the measurement and rate information available at the time. A few days later, additional provider evidence arrives and reveals that one of the underlying measurements was incomplete. With the corrected measurement, the valuation becomes $0.23.

Now we have two interpretations of the same execution at two different moments:

At T1
available measurement + applicable rate
        ↓
      $0.20

At T2
corrected measurement + applicable rate
        ↓
      $0.23

The easiest implementation is to update the original row:

UPDATE valuation
SET amount = 0.23
WHERE valuation_id = 91;

After the update, the system contains the best value we currently know.

But something disappeared.

If I inspect the database tomorrow, I can see $0.23. I can no longer see that the system previously believed the valuation was $0.20, when that interpretation changed, or what new information caused the change.

Whether that matters depends entirely on what we're trying to build.

For a simple dashboard, overwriting the previous value may be perfectly acceptable. If we want to investigate historical decisions, reconcile changing evidence or explain why an economic amount changed, destroying the previous interpretation becomes more problematic.

An alternative is to treat a correction as a new valuation that supersedes the previous one:

V1
$0.20
calculated at T1
    ↓
superseded by
    ↓
V2
$0.23
calculated at T2

Now we can distinguish two questions that initially looked like one:

What do we currently believe this execution should be valued at?

And:

What did the system believe at a particular point in time, based on the information available then?

This is also where another timestamp starts to matter.

Earlier, we cared about when the execution occurred and when a rate was effective. Corrections introduce a different dimension: when did the system actually record or learn a piece of information?

Those times can diverge:

execution occurred
August 10

rate effective
August 1 → September 1

correction recorded
August 15

The correction being recorded on August 15 does not mean the execution happened on August 15, nor does it mean the economic rule became effective on August 15. It tells us when our knowledge about the historical execution changed.

This is the territory where temporal data models — and, in more demanding systems, bitemporal thinking — become useful. They let us reason separately about when something was applicable in the domain and when the system learned or recorded it.

I wouldn't introduce that complexity automatically. Append-only corrections and supersession make reconstruction easier, but they also make the data model, queries and operational semantics more complicated.

The important lesson for me is more basic.

Once historical economics needs to survive corrections, time is no longer a single timestamp attached to an execution.

There is the time of the execution, the period in which an economic rule applied, and potentially the later history of what we learned about both.

And none of this is a new problem invented by AI.

---

This Is an Old Systems Problem in a New Context

Systems have had to represent changing prices, contracts, policies and other time-dependent facts long before AI products existed. Effective dating is an established way to model when a particular version of something applies. Temporal data models go further by preserving how facts evolve over time.

Bitemporal history, as described by Martin Fowler, makes an additional distinction between the history of what was actually applicable and the history of what the system knew or recorded about it.

So I don't think the interesting claim is that AI economics needs a new theory of time.

The interesting part is what happens when these established systems problems meet an execution model where several dimensions can evolve independently.

A provider can change a rate without the workflow changing. A workflow can start consuming a different model while the commercial price remains the same. A retry can add economic work without creating another customer-visible outcome. Evidence about an execution can arrive after the execution has already completed.

That creates several histories that may overlap without being identical:

EXECUTION HISTORY
What actually ran?

MEASUREMENT HISTORY
What resources were consumed?

ECONOMIC POLICY HISTORY
Which rates or rules applied?

KNOWLEDGE HISTORY
What did the system know, and when?

A current-state database can answer current-state questions very well. Historical economic questions are different because they may require relationships between facts that belonged to the same point in the past.

Suppose I still have the August measurement and every rate version ever published. That is better than keeping only the current rate, but the system still has a temporal relationship to resolve:

execution.occurred_at
        ∈
rate.effective_period

The historical answer depends on selecting the rate version whose effective period contains the execution time, not simply the newest rate record available when the query runs.

And if a correction arrived later, another question may appear: do I want the best interpretation we know today, or do I want to reconstruct what the system would have concluded with the information available at that earlier moment?

Those are different queries.

These ideas also have concrete support in relational systems. For example, PostgreSQL 18's temporal constraints include WITHOUT OVERLAPS for temporal primary and unique keys and PERIOD for temporal foreign-key relationships. That doesn't mean we need those features for this design, but it shows that application-time relationships are a first-class data-modeling concern rather than something specific to AI economics.

I don't think every AI product needs bitemporal tables, though. That would turn a useful observation into an architectural prescription.

The requirement should come first.

If all we need is a current estimate, keeping current rates may be enough. If we need reproducible historical valuations, effective-dated rate versions and explicit lineage may be enough. If we also need to reconstruct what the system knew before later corrections arrived, then preserving knowledge history starts to matter.

The architecture should follow the questions we expect the system to answer.

For me, that is the broader lesson behind the original $0.20 versus $0.55 example. The bug wasn't that the system couldn't multiply usage by a price.

It was that we were asking a historical question from data modeled primarily for the present.

---

Historical Economics Should Be Reconstructable

Fixing that problem does not necessarily require storing everything forever. It requires preserving the relationships that make a historical economic statement reproducible.

Conceptually, the chain looks something like this:

Execution
    ↓
Measurement Evidence
    ↓
Applicable Rate Version
    ↓
Derived Valuation

And, when the interpretation changes later:

Derived Valuation V1
    ↓
Correction / Supersession
    ↓
Derived Valuation V2

The important property isn't the shape of these tables or whether every system implements them as separate entities. It's that the economic result remains connected to the evidence and context that produced it.

That changes what I mean when I say that a historical valuation is "correct."

It isn't enough that I can produce a plausible number from historical usage. I want to be able to ask why that number belongs to that execution.

Which measurement am I valuing? Which economic rule applied? When was that rule effective? Which version produced this amount? Has that interpretation been corrected since?

This is why I'm becoming more interested in reconstructability than simply historical storage.

A system can retain years of usage records and still be unable to reconstruct what those executions meant economically at the time. Conversely, a system does not necessarily need to preserve every transient runtime detail if it has retained the evidence required for the economic questions it needs to answer.

The design target is not maximum history.

It's sufficient history.

In the Licenzy Guide “Nothing Changed in Your AI Product. Your Economics Did.”, we explored the broader question of why AI product economics can change even when the product appears stable. Rates are only one possible variable among several that can move underneath an apparently unchanged workflow.

The engineering consequence I'm exploring here is narrower: if one of those variables changes, did the system preserve enough evidence to determine what actually applied to an older execution?

That is the boundary between observing the past and reconstructing it.

But there is still an assumption hidden inside everything we've built so far.

We've assumed that we already know what the execution is.

Once we stop making that assumption, the problem gets more interesting.

---

But What Exactly Are We Valuing?

We've treated research-report-123 as if its economic boundary were obvious.

But a customer asking for one research report does not necessarily produce one clean unit of execution underneath.

The request might trigger:

Customer Request
      ↓
   Planning
      ↓
  Retrieval
      ↓
  Model Call
      ↓
   Tool Call
      ↓
   Failure
      ↓
    Retry
      ↓
Fallback Model
      ↓
  Validation
      ↓
Completed Report

From the customer's perspective, this may still be one action. Commercially, it may still consume the same 10 credits.

Economically, however, several pieces of work happened before the result existed.

Suppose we have done everything discussed in this article correctly. Every measurement survived. Every rate is versioned by effective time. Every valuation points back to the measurement and rate version that produced it. Corrections preserve their lineage.

We can now reconstruct the historical valuation of each piece of work.

But which pieces belong to the economic execution we're trying to understand?

If the first model call fails and a retry succeeds, both may have consumed resources. If a fallback model is invoked, its measurement belongs somewhere. If an external tool is called during the workflow, its economics may matter even though it is not part of the model usage itself.

The temporal problem asks:

Which economic context applied when this work happened?

The boundary problem asks:

Which work belongs to the thing we're trying to value?

Those are separate questions. Solving the first does not automatically solve the second.

This is one reason I'm hesitant to reduce AI economics to a single cost column attached to a request. The number may eventually be useful, but several decisions have already been made before that number can mean something: what counts as part of the execution, which measurements belong to it, which economic rules apply to those measurements, and how later corrections affect the interpretation.

The deeper I get into this problem, the more the architecture seems to depend on preserving relationships rather than accumulating numbers:

Customer-visible action
          ↓
   Execution boundary
          ↓
Measurement evidence
          ↓
Applicable economic context
          ↓
      Valuation

This article has focused on one part of that chain: making the economic context historically reconstructable.

The execution boundary is a different problem, and I think it deserves to be treated separately rather than hidden inside the cost calculation.

Because even if we can answer perfectly what a resource should be valued at under the economic context applicable at a particular point in time, there is still another question waiting underneath:

What exactly was the economic execution that consumed it?

---

Final Thoughts

The calculation itself is often the easy part.

The harder question is whether, six months from now, the system still has enough evidence to explain why that calculation was the right one.

Historical usage can tell us what was measured. It does not automatically preserve what that measurement meant economically at the time.

That meaning depends on context — and context has a history too.

And even if we can reconstruct that history correctly, another question remains:

What exactly counts as the economic execution we're trying to reconstruct?

That's the next problem I want to explore.