How costs are computed

Open Cost Explorer for a single namespace yesterday: $4,210. Sum the workloads inside that namespace: $3,612. The cluster's total for the same day: $4,890. Three numbers, all correct, none of them equal. This page explains why — what feeds the cost engine, the math that turns raw readings into the headline number, and which mode answers which question.

The bottom-up model

Kubeadapt computes cost bottom-up from instance prices × actual usage. It never reads your cloud invoice. This is intentional: a model that runs on live cluster state can answer "what did this deployment cost in the last 24 hours?" — a question your monthly invoice can't answer until weeks after the fact.

The inputs:

GCP discount-program rates (Committed Use Discounts) are coming in June 2026. Until then, GCP workloads price against on-demand and spot rates.

For on-prem and bare-metal clusters, where there's no cloud price catalog to query, Kubeadapt uses industry-default rates per CPU-hour, GiB-hour, and GPU-hour. You can override these per cluster with your own pricing.

From instance price to per-resource rate

A node has one price — $0.42/hr for an m5.2xlarge, for example — and that one price has to be split across CPU, memory, and (for GPU nodes) GPU so each pod gets charged for what it actually consumed.

Kubeadapt splits the node price using the OpenCost-standard ratios: CPU is priced 5× memory per unit, and GPU is priced 40× memory per unit, normalized to the node's vCPU, GiB, and GPU counts. The result is three hourly rates — one for CPU, one for memory, one for GPU — that together equal the node's total hourly price.

This decomposition matters because pods don't all consume the same resources. A memory-heavy in-memory cache and a CPU-bound batch job on the same node deserve different cost slices, not "1/Nth of the node price each."

From rates to workload cost

For every container in every minute-snapshot:

cpu_cost  = max(cpu_request,  cpu_usage)  × node.cpu_rate
ram_cost  = max(ram_request,  ram_usage)  × node.ram_rate
gpu_cost  = gpu_request                   × node.gpu_rate   (GPU is request-based; never discounted)

A pod's cost is the sum of its containers. A workload's cost is the sum of its pods. A namespace is the sum of its workloads. A cluster is the sum of its nodes plus persistent volumes plus a control-plane fee ($0.10/hr on EKS, GKE, AKS; $0 on self-managed).

The max(request, usage) rule is the reason your bill stays predictable even when a pod briefly under-uses what it reserved: you pay for what you scheduled. It's also why right-sizing requests — not limits — is the actual cost lever in Kubernetes. See Right-sizing.

The three corrections

Raw per-resource cost is then run through three corrections before it lands in Cost Explorer.

Capping

Each container's per-resource cost is capped at the node's per-resource cost for that day. A container can't cost more than the node's share for that resource — capping prevents one container from being charged for more than its share of the node.

Idle redistribution

A node bought at $50/day might host workloads that together account for $35/day of (capped) compute. The remaining $15/day is idle — capacity that was paid for but not used by any pod.

In Fully Loaded mode, that idle slice is distributed across the workloads on the node, proportional to their compute share. A workload that ran heavier gets a bigger share of the idle.

Overhead distribution

After accounting for node compute and idle, there's still the cluster's overhead: control-plane fee, system pods, DaemonSets, the load balancer in front of the cluster, persistent volumes — anything in the cluster total that isn't directly attributable to a workload as node compute.

In Fully Loaded mode, overhead is distributed across workloads proportional to their post-idle compute share. In Workload Only mode, overhead stays outside the workload numbers.

The two cost modes

Cost Explorer, every Dashboard, and every per-entity drilldown share the same two-mode toggle.

Fully Loaded (default)

• Workload's own capped compute + its share of node idle + its share of cluster overhead.
• The sum across all workloads in a cluster equals the cluster's total for that day.
• The number to cite to finance, and the number that maps to your cloud bill once a cloud account is connected.

Workload Only

• Capped compute only. No idle. No overhead.
• The sum across all workloads in a cluster will be less than the cluster total — that's expected.
• The right mode when you're optimizing a single workload, because idle and overhead would distort the picture of what that workload actually consumed.

See Cost modes for a side-by-side reference.

A worked example

For one day on cluster prod-east:

• Node compute total: $80 (sum of every node's price × time).
• Workload capped compute (sum across all pods): $60.
• Cluster total cost (everything in the cluster bill): $100.

Then:

• Idle = $80 − $60 = $20 (node capacity paid for but not used by any pod).
• Overhead = $100 − $80 = $20 (cluster cost minus node compute — control plane, DaemonSets, PVs, etc.).
• Workload Only sum = $60. The remaining $40 stays outside.
• Fully Loaded sum = $60 + $20 + $20 = $100, which equals the cluster total.

Idle and overhead get pushed onto workloads proportional to their compute share, so heavier workloads carry a bigger slice.

Why three sums don't match

Back to the question from the lead paragraph:

• Cluster total ($4,890) — the unaltered cluster cost for the day.
• Fully Loaded namespace sum ($4,210) — the workloads in that namespace plus their share of idle and overhead. Less than the cluster total because not every workload lives in that namespace.
• Workload Only sum ($3,612) — the same workloads, capped compute only. The gap to $4,210 is the namespace's share of idle and overhead.

All three are correct. They answer three different questions:

• "What did the cluster cost?" → cluster total.
• "What share of the cluster cost does this namespace own?" → Fully Loaded.
• "What did the workloads in this namespace actually consume?" → Workload Only.

Time granularity

Cost Explorer buckets at daily, weekly, or monthly granularity. Daily is the smallest bucket — sub-day reads live in the utilization and capacity views, which pull from per-minute snapshots directly.

All date inputs are UTC. The end-of-range is exclusive: the monthly window for "May 2026" runs 2026-05-01T00:00:00Z (inclusive) → 2026-06-01T00:00:00Z (exclusive). The same convention runs through every cost view.

Data completeness

Every Cost Explorer response includes a data completeness ratio — how much of the expected data actually arrived from your clusters. The dashboard surfaces it as a banner:

• ≥ 98% — complete.
• 85% – 98% — partial; some clusters missed updates.
• < 85% — agent outage; cost numbers are understated until data catches up.

This is what you see when a chart prints "partial coverage" or "agent fell behind."

What Kubeadapt's cost numbers don't include

• No cloud-bill reconciliation. Numbers are computed bottom-up from instance pricing × utilization, never reconciled against your AWS, GCP, or Azure invoice. A connected cloud account feeds prices — Reserved Instances, Savings Plans — not the invoice itself.
• No per-container network cost. Cross-AZ and egress traffic visibility lives in the optional eBPF agent's network pages, not in the per-container cost roll-up.
• No retroactive corrections. If Kubeadapt ships a cost-model improvement, it applies from that point forward. Finalized Reports keep their numbers; live queries pick up the improvement on the next read.
• No discounting of GPU. GPU cost uses the published per-GPU rate. Reserved-Instance and Savings-Plan discounts don't apply to GPU spend (the cloud providers don't price GPU under those programs).

Next steps

• Cost Explorer — the surface that reads these numbers.
• Cost modes — Fully Loaded vs Workload Only, side by side.
• Resource Efficiency — the used-vs-requested ratio that drives right-sizing.
• How Kubeadapt works — the agent, the pricing inputs, the read-only path.