You can have a perfectly healthy Kubernetes cluster and still have no idea who is driving the bill. The cloud invoice will tell you what the cluster cost. It will not tell you which namespace, workload, or team consumed that capacity, or how much of the spend was simply idle headroom nobody requested. OpenCost fills that gap. It gives you a vendor-neutral way to allocate Kubernetes cost down to cluster objects, query it over an API, and build showback without buying into a commercial platform first.
As of v1.121.0 (July 2026), the current release, OpenCost is a CNCF Incubating project. The useful mental split is straightforward: OpenCost is the open-source engine and specification; Kubecost is the commercial product line in the same space. The OpenCost repository notes that the project was originally developed and open-sourced by Kubecost, while Kubecost's public site is now branded IBM Kubecost. For this post, we are staying on the OSS side: self-hosted OpenCost, standard Helm install, standard API, standard Prometheus queries.
The allocation model is the part to understand first
If you only remember one detail from OpenCost, make it this one: workload cost is not just raw usage. In the OpenCost specification, workload costs are defined as max(request, usage) for resources with allocation costs such as CPU and GPU. That matters because the bill follows reserved and allocatable capacity rather than whatever a container happened to burn in a five-minute slice.
