Savings report calculations

Reference for the exact formulas, cost fields, and pricing logic behind every number in the Savings Report.

This page documents the exact calculations behind every field in the Savings Report, for readers who want to reproduce or audit the numbers. For an introduction to the report and its terms, start with Savings Report. For how the baseline itself is built, see Savings baseline.

Actual cost

Actual cost is the straightforward sum of real dollars spent on provisioned CPU and RAM over the period you're viewing — no modeling involved.

actual cost = actual CPU cost + actual RAM cost

Projected cost — the counterfactual

Projected cost is the modeled estimate of what you'd be paying without Cast AI. It's the number every savings figure is derived from, so it's worth understanding piece by piece.

projected CPU cost =
  if (day is on/after the baseline period ends):
      greatest(original requested core-hours, current requested core-hours)
        × CPU overprovisioning factor
        × greatest(current effective $/core-hour, baseline $/core-hour)
  else:
      actual CPU cost

RAM is calculated the same way, using the RAM overprovisioning factor and RAM unit cost.

Reading it piece by piece:

  • Before your baseline period ends, projected cost equals actual cost. Cast AI hadn't optimized the cluster yet during the baseline window, so there's nothing to attribute savings to. Savings only start accruing once the baseline period closes — see Savings Report.
  • Demand is the larger of original or current requested core-hours. If a workload's requests were rightsized down, projection uses the larger, pre-rightsizing original request. If a workload's requests grew above its original level, projection uses the larger current request. Either way, the model never assumes you'd be running leaner than you actually run today.
  • Demand is scaled up by the overprovisioning factor — the ratio your cluster historically ran at without Cast AI's node-level optimization.
  • The result is priced at whichever is higher: your current effective rate or your baseline rate. This ensures the counterfactual is never underpriced — if Cast AI lowered your unit cost (e.g., through spot adoption), the projection reflects the higher pre-optimization rate.

Realized savings

realized savings = projected cost − actual cost

This is zero for any cluster without a baseline, and zero for any day inside the baseline period, since projected cost equals actual cost during that window (see above).

Workload autoscaler savings

workload autoscaler savings =
  (original requested core-hours − current requested core-hours)
    × greatest(current effective $/core-hour, baseline $/core-hour)

counted only on days when workload autoscaling (VPA) was actually active on the cluster.

📘

Note

This calculation runs independently of the baseline period. Unlike autoscaler savings, workload autoscaler savings can accrue even on days that fall inside your baseline window — rightsizing isn't tied to when Cast AI took over node management.

Reported cost fields

The report combines the CPU and RAM figures above into the fields you see in the UI and API:

FieldValue
Actual costActual CPU cost + actual RAM cost
Projected costProjected CPU cost + projected RAM cost
Autoscaler savingsAutoscaler CPU savings + autoscaler RAM savings
Workload autoscaler savingsWorkload autoscaler CPU savings + workload autoscaler RAM savings
Total savingsCurrently equals autoscaler savings only, since the workload autoscaler impact is already included by decreasing the CPU and RAM demand

Listing prices vs. discounted prices

The report can show actual cost and current unit price using either your discounted (effective, negotiated) rates or listing (on-demand list) prices, ignoring any discounts. Toggling this changes what "actual cost" means, but not your baseline:

  • Discounted (default): reflects what you actually pay — negotiated rates, real spot prices.
  • Listing: uses on-demand list prices, useful for showing savings against undiscounted, rack-rate pricing.

Two things to know about this toggle:

  • Listing prices aren't available before August 6, 2025. If you select a time range that starts before this date, the report automatically falls back to discounted prices regardless of your selection.
  • Your baseline unit cost is always based on discounted pricing, since that's what was available when your baseline was calculated. If you switch to listing prices, actual and current costs rise to list-price levels while the baseline floor stays at your discounted historical rate — the "whichever is higher" pricing rule described above still applies on top of that.

Historical data quality

A small number of data-quality safeguards apply to historical data, mainly affecting workloads' original (pre-rightsizing) requests:

  • Some workload types had a data-collection gap that produced zero values for original requests before Cast AI resolved it in early 2026; the report substitutes current requests as a reasonable proxy for those older data points.
  • Values that are implausibly large (well beyond what any real pod would request) are excluded and replaced with a sane fallback, to guard against occasional data-collection errors.
  • For time ranges that start before October 2025, the report uses the earliest reliable snapshot of original requests it can find, rather than assuming zero.

These safeguards only affect historical accuracy for older data — they don't change how current and future savings are calculated.

Scenario reference

Use this table to predict what the report will show for a given cluster or day.

Baseline assignment

SituationOutcome
Cluster is younger than 14 days, or not yet under active Cast AI managementNo baseline; cluster is excluded from the report
At least 7 days of own history before Cast AI took over managementCluster history baseline
Fewer than 7 days of own history, but an org peer has a Cluster history baselinePeer clusters baseline
No own history and no eligible org peersIndustry average baseline
Baseline manually overriddenOverridden; automatic recalculation stops for that cluster

Per-day savings

Day is...Workload autoscaling active?Autoscaler savings that dayWorkload autoscaler savings that day
Inside the baseline periodNoNone (projected = actual)None
Inside the baseline periodYesNone (projected = actual)Accrues
After the baseline period endsNoAccruesNone
After the baseline period endsYesAccruesAccrues

Demand and price selection

The projected-cost formula always picks the higher option for both demand and price — if Cast AI lowered your unit cost (e.g., through spot adoption), the projection reflects the higher pre-optimization rate:

  • Demand uses whichever is larger: original (pre-rightsizing) requests or current requests.
  • Price uses whichever is higher: your current effective unit cost or your baseline unit cost.

Known limitations and edge cases

  • Clusters without a baseline are absent, not zeroed. A cluster that's too new, not yet under active management, or that produced no usable data in any of the three baseline methods simply doesn't appear in either report view — it isn't shown with zero savings.
  • Clusters created before node-level monitoring became available (February 2025) may have a less precise baseline window. For these clusters, the baseline period ends when Cast AI took over credentials rather than when it took over active node management, which can make the overprovisioning and cost factors slightly less representative.
  • An industry-average baseline draws from Cast AI's entire fleet, not just your organization. This is intentional — it's meant to be a genuine cross-fleet reference point — but it means an industry-average baseline for your cluster is influenced by data from unrelated organizations.
  • Savings only start after your baseline period ends. A report whose entire time range falls inside the baseline window will show projected cost equal to actual cost and zero autoscaler savings (workload autoscaler savings may still appear, since that calculation isn't tied to the baseline window).
  • Baseline factors don't distinguish between on-demand, spot, and fallback capacity. All four baseline parameters are single averaged values applied uniformly across lifecycles, so spot-versus-on-demand nuance isn't captured in the model.

Related resources


Did this page help you?