Savings
Savings is the page finance is most skeptical of, for good reason: a savings number is easy to assert and hard to prove — you can’t see spend that didn’t happen in a billing ledger the way you can see spend that did. This page exists to make the methodology behind the number visible, not just the total.
Identified versus realized
These are two different numbers, shown side by side and never merged into one:
- Identified savings — the total dollar value of open, not-yet-accepted recommendations sitting in the queue right now. This is a live snapshot, not a figure for a specific time period.
- Realized savings — measured savings for the selected timeframe, computed from what actually happened after a recommendation was accepted.
Potential savings are useful for prioritizing what to work on next. They are not the same claim as savings finance can credit against the bill, and presenting an identified number as if it were achieved is the fastest way to lose that credibility. Two accepted-but-unmeasured states are also called out separately rather than folded into either bucket: pending (still inside the measurement window) and not verifiable (the measurement ran and couldn’t scope this particular recommendation — a permanent state, not a wait).
How realized savings are actually measured
When a recommendation is accepted, TensorCost measures what happened to spend for the same application and model, before and after:
- Before — total spend in the 30 days immediately before acceptance.
- After — total spend in the 30 days immediately after acceptance.
- Verified savings = before − after. This can go negative — if spend went up instead of down, the ledger says so rather than hiding it.
This baseline measurement is labeled single-cohort verification: a genuine before/after on the tenant’s own spend, with no comparison group. Where enough peer volume exists to build a matched control cohort, the measurement is upgraded to a difference-in-differences (DiD) estimate — comparing the change in the treated population against the change in a similar untreated population over the same window, which nets out spend movement that would have happened anyway (seasonal growth, unrelated pricing changes, and so on). Rows carrying this stronger comparison are tagged accordingly, distinctly from plain single-cohort rows.
A recommendation only gets measured once its 30-day “after” window has fully closed — a row is marked estimated (the predicted number at acceptance time, not yet measured) until then, and some recommendation types can’t be scoped for measurement at all, in which case the ledger says so explicitly rather than attributing unrelated spend drift to the recommendation.
The monthly view pairs each accepted row’s estimate-at-acceptance against its measured outcome for the same population, so “expected vs. realized” is visible month over month, with a short list of recently verified rows as supporting evidence — not just a total with no way to check it.
Effective Savings Rate — the industry-standard metric we can’t yet compute
The FinOps Foundation’s standard metric for this is Effective Savings Rate (ESR): realized savings from rate optimization divided by what the same infrastructure would have cost at full on-demand rates, with no discounts of any kind.
ESR needs two audit-able inputs: amortized cost (what you actually paid, after every discount, credit, and commitment amortization) and on-demand-equivalent cost (what the identical infrastructure would have cost with zero discounts). TensorCost does not assemble that second figure — the on-demand-equivalent spend across a tenant’s entire bill — today. We price individual GPU instance types for spot and rightsizing recommendations, and we derive commitment coverage per cloud commitment row, but neither adds up to a tenant-wide on-demand baseline an ESR percentage requires. The Savings page says this plainly and does not synthesize a percentage it can’t support.
What Savings is not
It is not a general cost-optimization dashboard, and it does not attempt a gross-to-net waterfall or a full monthly ledger of every recommendation ever created — that content still exists in the underlying data model for a future page, but Savings itself stays narrow: identified vs. realized, the methodology behind realized, and nothing else. A short, consistent, hard-to-argue-with report is the design goal, not comprehensiveness.
