# After you apply: the realized measurement

The only path to a measured saving: what the prior tier would have cost on rows that ran, and why it stands beside the projection.

Source: https://tokentriage.com/docs/build/cost-realized

---
import Callout from '../../../components/Callout.astro';
import Details from '../../../components/Details.astro';
import NextSteps from '../../../components/NextSteps.astro';
import RealizedWindowsDiagram from '../../../components/RealizedWindowsDiagram.astro';
import Screenshot from '../../../components/Screenshot.astro';

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:

```text
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.

<Callout type="key">
This is **not** a before-and-after comparison of two windows. Subtracting last
month's bill from this month's cannot distinguish "you saved money" from "you shipped less", and
traffic growth is indistinguishable from savings in it. The raw request rates either side of the
change are disclosed beside the figure, and are not used to rescale the dollar.
</Callout>

## 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.

<RealizedWindowsDiagram />

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.

<Screenshot
  stem="realized"
  dark={true}
  url="localhost:9090/ui/cost/realized"
  alt="The realized view: the projection and the measurement in separate columns, each headed by its own window and baseline, with a traffic-volume note between them and no delta."
  caption="Projected and realized, side by side and not subtracted: each headed by the window and baseline it is quoted over (real dashboard, demo mode)."
/>

## 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:

```json
{
  "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.

<Details summary="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.

</Details>

<NextSteps items={[
  {title: "Recommendations", href: "/docs/build/cost-optimization", description: "The projection this measures against, and why a recommendation is ESTIMATED at best."},
  {title: "How to read a cost figure", href: "/docs/build/cost-figures", description: "What PROVEN licenses, and the paperwork a measured dollar carries."},
  {title: "Verdicts, methods and baselines", href: "/docs/build/cost-figure-reference", description: "The prior-choice baseline and the two proven-capable methods, in full."},
  {title: "Reconcile against a provider invoice", href: "/docs/build/cost-reconciliation", description: "The other way to check the ledger against reality: the provider's own bill."},
]} />