Reference
Cost modes
When to use Fully Loaded, Workload Only, and Uncapped cost — and what each one actually measures.
You're staring at Cost Explorer with a Fully Loaded chip lit up, and the Workload Only number for the same query is lower. Someone in Slack is asking which one to use for the chargeback report. This page is the answer: three cost modes, what each one measures, and a flow chart for picking the right one.
Kubeadapt supports three cost modes. Two of them surface in the UI as chips in Cost Explorer; the third is API-only and used by tooling that needs raw pre-cap numbers.
The three modes at a glance
| Mode | Includes | Reconciles to | UI chip |
|---|---|---|---|
| Fully Loaded | Capped CPU/RAM/GPU + idle redistribution + cluster overhead | Your cloud bill | Fully Loaded (default) |
| Workload Only | Capped CPU/RAM/GPU only | Node compute total (before idle) | Workload Only |
| Uncapped | Raw observed-usage cost — no cap, no overhead | Pre-distribution cost | not surfaced |
Fully Loaded
The default chip in Cost Explorer, and the number that appears on KPI cards, the cluster dashboard, and organization rollups.
What it includes:
- The workload's own capped compute (CPU + RAM + GPU at the request line).
- Idle redistribution — unclaimed node capacity, redistributed to the workloads that requested it.
- Cluster overhead distribution — control-plane fees, system processes (kubelet, kube-proxy, daemons), and other non-attributable infrastructure cost, distributed across workloads.
What it reconciles to: your cloud bill. If you sum every workload's Fully Loaded cost across a cluster, you should land within a few percent of what AWS, GCP, or Azure charges for that cluster's compute over the same window.
Use it for:
- Finance reports — anything that needs to tie back to the invoice.
- Organization dashboards and cluster overviews.
- Cost trends shown to non-engineering audiences.
Workload Only
The second chip in Cost Explorer. Strips out idle and overhead so each workload pays for exactly the compute it requested.
What it includes:
- Capped CPU cost.
- Capped RAM cost.
- Capped GPU cost.
No idle redistribution. No overhead distribution. If a node is 60% packed, the 40% empty space doesn't get charged to anyone.
What it reconciles to: the sum of all workloads' Workload Only cost equals the node compute total before idle. It's smaller than the cloud bill by the idle + overhead share.
Use it for:
- Per-workload optimization decisions. Idle and overhead distort fair comparisons between workloads.
- Right-sizing reviews — you want to know what this workload costs in compute terms, not what its idle share looks like.
- Cost-attribution math when you specifically need to exclude shared cluster cost.
Uncapped
The third mode. Real, queryable via the API — but not surfaced as a chip in Cost Explorer. The toggle in the UI only shows Fully Loaded and Workload Only.
What it includes:
- The cost the workload would generate at the node's per-unit rate if you priced its full observed CPU/RAM/GPU usage, ignoring the request line.
A workload requesting 1 core and burning 2 cores during a burst is reported at 2 cores' worth of cost in Uncapped. In every other mode, it pays for 1 — the cap.
What it reconciles to: pre-distribution observed cost. Per workload, uncapped cost can be higher or lower than capped cost depending on whether the workload is over- or under-provisioned at that minute.
Use it for:
- Right-sizing analysis that needs to compare actual usage to requested resources.
- Audit queries via the API.
Note on the node family: Uncapped is not defined for node-axis queries (Node, Instance Type, Zone). Queries that combine Uncapped with a node-axis grouping return total cost for safety.
Worked example
Take one workload running for one day on a node with $0.04/core/hr CPU and $0.005/GiB/hr RAM. The workload requests 1 core and 2 GiB, bursts to 1.4 cores and 1.6 GiB observed, and the node has 30% unclaimed idle plus a 5% overhead share that gets distributed.
| Component | Value |
|---|---|
| CPU capped @ 1 core × $0.04 × 24h | $0.96 |
| RAM capped @ 2 GiB × $0.005 × 24h | $0.24 |
| Capped subtotal | $1.20 |
| Idle redistribution (this workload's share) | $0.36 |
| Overhead distribution (this workload's share) | $0.06 |
| Loaded total | $1.62 |
| Uncapped CPU @ 1.4 cores × $0.04 × 24h | $1.344 |
| Uncapped RAM @ 1.6 GiB × $0.005 × 24h | $0.192 |
| Uncapped total | $1.536 |
Reported per mode:
| Mode | Reported cost | Why |
|---|---|---|
| Fully Loaded | $1.62 | Capped + idle + overhead. Reconciles to the bill. |
| Workload Only | $1.20 | Capped only. Cleanest for per-workload comparison. |
| Uncapped | $1.536 | Priced at observed usage, regardless of the request. |
Notice that uncapped sits between the other two for an under-utilizing workload. For an over-utilizing workload (burst above the request line), uncapped would be the highest of the three.
When to use which
| Question you're answering | Mode |
|---|---|
| "Why is the bill up 18%?" | Fully Loaded |
"How much is namespace payments costing us?" | Fully Loaded |
| "Which workload should I right-size first?" | Workload Only |
| "Did this Helm change make the workload cheaper?" | Workload Only |
| "What does this workload actually consume, ignoring its request?" | Uncapped (via API, not UI) |
| "How much idle do we have?" | Fully Loaded total − Workload Only total |
The default in the UI is Fully Loaded for a reason: most people opening Cost Explorer have a question that ties back to the invoice. Switch to Workload Only when you're optimizing a single workload and want the idle/overhead noise stripped out.
See also
- Cost Explorer — where the Fully Loaded / Workload Only chip lives.
- How costs are computed — the bottom-up math behind every mode, including capping, idle, and overhead.
- Right-sizing — uses Workload Only and Uncapped to compute recommendation savings.