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 costProjected 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 costRAM 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 costThis 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.
NoteThis 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:
| Field | Value |
|---|---|
| Actual cost | Actual CPU cost + actual RAM cost |
| Projected cost | Projected CPU cost + projected RAM cost |
| Autoscaler savings | Autoscaler CPU savings + autoscaler RAM savings |
| Workload autoscaler savings | Workload autoscaler CPU savings + workload autoscaler RAM savings |
| Total savings | Currently 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
| Situation | Outcome |
|---|---|
| Cluster is younger than 14 days, or not yet under active Cast AI management | No baseline; cluster is excluded from the report |
| At least 7 days of own history before Cast AI took over management | Cluster history baseline |
| Fewer than 7 days of own history, but an org peer has a Cluster history baseline | Peer clusters baseline |
| No own history and no eligible org peers | Industry average baseline |
| Baseline manually overridden | Overridden; automatic recalculation stops for that cluster |
Per-day savings
| Day is... | Workload autoscaling active? | Autoscaler savings that day | Workload autoscaler savings that day |
|---|---|---|---|
| Inside the baseline period | No | None (projected = actual) | None |
| Inside the baseline period | Yes | None (projected = actual) | Accrues |
| After the baseline period ends | No | Accrues | None |
| After the baseline period ends | Yes | Accrues | Accrues |
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
- Savings Report overview — what the Savings Report shows and the two sources of savings it tracks.
- Savings baseline — how the baseline period, overprovisioning factors, and unit costs behind these formulas are established.
- Organization-level savings report
- Cluster-level savings report
Updated 5 hours ago
