After you apply: the realized measurement

Most cost tools stop at the recommendation. You apply it, the dashboard congratulates you, and nobody ever checks. Three months later someone asks whether it worked and the honest answer is that the projection was not revisited.

This page is about the step after. Once a recommendation has been applied and enough traffic has run under it, the loop goes back and measures what happened. That measurement is the only thing in the whole system that produces a PROVEN saving.

What is being measured

Every costed row carries cost.would_usd: what that same request would have cost at each of your tiers. It is written for every row, always, whether or not routing is on.

That field is what makes the measurement possible. For rows that ran after the change, the measurement is a per-row subtraction:

saving = Σ over post-apply rows of ( would_usd[the tier that was serving before] − usd )

Nothing is extrapolated and nothing is multiplied by projected volume. These are rows that happened, priced two ways.

The honest label on it is fixed_usage, and it is not decoration: the prior tier would have generated slightly different tokens for the same prompt, and this arithmetic prices the tokens that were produced. That is the residual approximation in a measurement that is otherwise direct, and it travels on the figure rather than being argued away.

The two numbers stand side by side

Applying a recommendation does not overwrite its projection. The projection is the record of what you decided on, it stays immutable, and the measurement lands beside it.

Beside, not against. The surface shows both figures and computes no difference between them, which is the single most important thing on that screen.

Read the two columns as separate claims. They share no window, no population and no baseline, so their difference is a number about nothing.

A run from the project’s own evidence gallery makes it concrete. The projection was $2.146, quoted over a 28-day detection window of 120 rows against the slice’s recorded spend. The measurement was $2.340, over 5 post-apply days of 90 rows against what the previous tier would have cost. Subtract them and you get −$0.194, which reads as “it over-delivered by 9%” and means nothing at all. While those two numbers sat side by side, the actual story was that traffic had quadrupled, from 4.286 to 17.851 requests a day.

So each figure renders inside its own column, headed by its own window, row count and baseline, and the volume note occupies the space where the meaningless delta would otherwise go.

localhost:9090/ui/cost/realizedDemo data

When the figure is due

The first measurement lands at apply + 72 hours, and after that weekly, each one appended as a new version rather than replacing the last.

Waiting is the point. A counterfactual over a handful of post-apply rows is a number with no power behind it, and the first realized figure someone sees sets what they believe the whole loop is worth. So the window is waited out rather than answered early.

Whether a build has the measurement job at all is advertised on its capabilities response, and the view renders from that rather than guessing:

{
  "measurement": {
    "wired": true,
    "at": "2026-08-10T02:00:17Z",
    "considered": 0,
    "due": 0,
    "measured": 0,
    "refusals": []
  }
}

A build with no job says so. A build with one says the figure is not due yet and names the date. Those are opposite facts, and for one release the surface rendered the first for both.

Three answers that are not “your saving is $X”

The interesting states here are the ones that are not a number, and the surface keeps them apart.

Not yet. The 72 hours have not elapsed. The view names the date.

Never, and here is why. Some applied changes cannot be measured this way at all, and the refusal is marked permanent. A cache rule is the example: its lever is not a tier change, so no prior tier was recorded, so the prior-choice baseline has nothing to read. No later pass can change that: the prior tier is frozen at apply time precisely because the config it names has already moved. The view renders this as this recommendation will never be measured, with the reason, and drops the due date. Rendering it as “not yet” tells someone to keep waiting for a number that is not coming.

Zero, and whether it measured anything. A row that was already being decided at the prior tier contributes exactly zero by construction, because the old choice and the new choice were the same choice on that row. When every measured row is in that state, $0.00 · PROVEN · 19 rows measured reads as “the change was evaluated and delivered nothing” when it means “the change has not been exercised yet”. So the record carries a count of rows still at the prior tier, and when that equals the measured row count the server refuses to send the figure without a note saying so. A partial overlap carries the count and no caveat: 14 of 20 rows decided under the new config is a sound measurement of those 14, and a caveat that fires on the normal case is one people learn to skip.

What can go wrong

You compare the two columns anyway. The screen makes that awkward for a reason. If you need one number for a report, use the realized figure with its window and row count attached, and describe the projection separately as what was expected at the time.

A restart lost the card. Applied state is in memory on this build, so the recommendation returns to open. The audit row, the config change and the stored artifact all survive, and the measurement job reads the artifact rather than the card’s status.

Low coverage went unnoticed. When more than 20% of the rows in scope were excluded, whether as unpriced or as not licensing the baseline, the figure is disclosed as low-coverage rather than quietly averaged over whatever survived.

Why a refusal is recorded rather than swallowed

Every measurement sweep records what it considered, what was due, what it measured, and every refusal with its reason and whether that reason is permanent.

A measurement that was owed and did not happen is a fact you can act on. The alternative is a realized field that stays absent for a reason nobody can see, which is the same failure as an empty recommendations list with no explanation, and it has the same fix.