Savings calculations

This page is the technical reference for the Realized savings report. It covers the baseline methodology (how Cast AI establishes a pre-optimization reference point) and the exact formulas that turn that baseline into projected cost and savings figures.

Baseline overview

To say "Cast AI saved you money," Cast AI needs a reference point: what would this cluster have cost, and how would it have looked, without Cast AI? That reference point is the baseline, and it's the foundation every number in the report is measured against.

The baseline isn't a single dollar figure. It's a small model of your cluster's behavior before Cast AI's optimizations took effect, made up of four numbers plus a time window:

1. CPU overprovisioning factor: how much more CPU was provisioned than workloads actually requested.
2. RAM overprovisioning factor: the same, for memory.
3. CPU unit cost: the effective price you paid per CPU core, per hour.
4. RAM unit cost: the effective price you paid per GiB of RAM, per hour.

These four numbers are measured over a baseline period, a historical window representing your cluster before Cast AI optimization. Once captured, the model stays fixed and is reapplied going forward to reconstruct what your projected (no-Cast-AI) cost would be on any given day.

📘

Note

Why a model, and not just an old bill? Clusters grow and shrink over time, so comparing today's bill to a fixed dollar amount from months ago wouldn't be fair. Instead, the baseline captures ratios and rates (how much you tended to overprovision, and at what price) and reapplies those ratios to today's actual workload demand. That keeps the comparison fair as your cluster scales up or down.

What the numbers mean in practice

These four values are averaged across your entire baseline period and applied uniformly. They don't currently distinguish between on-demand, spot, and fallback capacity.

How your baseline is determined

Cast AI computes baselines automatically, once per day, for every eligible cluster. It tries three methods in order, from most to least specific to your cluster, and uses the first one that has enough data:

1. Your cluster's own history      →  most reliable
2. Other clusters in your org      →  fallback
3. Cast AI's broader fleet average →  last resort

A cluster only moves to the next method if the previous one didn't have enough data to compute a baseline. Once a cluster gets a baseline from an earlier method, it's never re-evaluated against a later one.

Your cluster's own history

This is the highest-quality baseline, because it's built entirely from your cluster's own pre-optimization behavior. Cast AI looks at the period between when your cluster first connected and when Cast AI took over active node management (specifically, the point at which more than 20% of your nodes became Cast AI-managed), and calculates the four parameters from your cluster's actual metrics during that window.

Your cluster qualifies for this method only if there's at least 7 days of history between cluster creation and the point Cast AI took over. Without a week of pre-optimization data, the cluster falls through to method 2.

In the report and API, this baseline type is labeled Cluster history.

Other clusters in your organization

If your cluster doesn't have enough of its own history, Cast AI looks for other clusters in your organization that already have a Cluster history baseline, and averages their overprovisioning factors and unit costs. The baseline window becomes the combined span of those peer clusters' own baseline windows.

The assumption here is that clusters within the same organization tend to share infrastructure patterns and pricing, making a sibling cluster's measured behavior a reasonable stand-in for yours.

In the report and API, this baseline type is labeled Peer clusters.

Industry average

If your cluster has no usable history of its own, and no eligible peers in your organization, Cast AI falls back to averaging overprovisioning and cost across all clusters observed on the fleet, on the single day your cluster connected to Cast AI's active management. This is a genuine cross-fleet average, not limited to your organization.

In the report and API, this baseline type is labeled Industry average. Think of it as "no data more specific to this cluster was available for comparison."

📘

Note

An industry-average baseline is the least specific of the three, since it isn't based on your own workloads or infrastructure. If your Savings Report is using an industry-average baseline and the numbers look off, contact your Cast AI representative about a manual baseline review.

When a baseline can't be computed yet

A cluster needs to be at least 14 days old, and Cast AI needs to be actively managing it, before a baseline is computed at all. If your cluster is younger than that, or hasn't yet reached active management, it simply won't appear in the Savings Report yet. It won't show zero savings; it will be absent entirely. This is intentional: it avoids showing noisy, unstable savings numbers for clusters that just connected.

Once your cluster clears both thresholds, Cast AI computes a baseline on its next daily run, and the cluster starts appearing in your report.

Manual baseline adjustments

Sometimes the modeled baseline doesn't reflect reality. For example, if you have out-of-band knowledge of your actual pre-Cast-AI costs, or the automatic calculation landed on a window that wasn't representative. Two adjustments are available through your Cast AI representative:

• Override the baseline: hand-set any of the four parameters directly. Fields you don't specify keep their current values. Once a baseline is overridden, Cast AI's automatic daily calculation will never touch that cluster again, so the override sticks until it's changed manually.
• Recalculate over a custom date range: re-run one of the three calculation methods above, but over a date range you choose instead of the one Cast AI selected automatically.

Both baseline types are labeled Overridden in the report once applied, so you can always tell when a baseline reflects a manual adjustment rather than the automatic calculation.

Baseline assignment summary

Calculation formulas

Actual cost

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

actual cost = actual CPU cost + actual RAM cost

Projected cost

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 Realized savings.
• 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 (for example, 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 realized savings, workload autoscaler savings can accrue even on days that fall inside your baseline window, since 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:

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. To ensure these reflect your actual cloud spend, configure Price adjustments.
• 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

Per-day savings

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 (for example, 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

• 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 realized 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.