OpenCost allocates spend by cluster, namespace, service, and pod
OpenCost answers a question cloud invoices handle badly: which Kubernetes workload consumed the money? It combines cluster resource allocation with cloud pricing, then groups costs by node, namespace, controller, service, or pod. AWS, Azure, and GCP integrations extend the view beyond in-cluster resources. On-premises clusters can supply custom CSV pricing.
The implementation is large enough to treat as infrastructure, not a dashboard add-on. Our commit ba0e947 checkout had 976 files, about 230,564 lines of source, and occupied 75.1 MB. OpenCost also maintains a specification, while its web UI and Helm chart live in separate repositories. This checkout alone is not the complete user-facing installation.
Helm and Prometheus are required for the supported deployment
The README directs every production install through the official Helm chart on Kubernetes 1.20 or newer. Standalone manifests have been removed. Prometheus supplies usage data, and the contribution guide requires PROMETHEUS_SERVER_ENDPOINT even for a local Go run. A team without Prometheus, Helm practices, or cluster metrics has several operating decisions to make before the first cost report.
Our sandbox installed 458 Go packages in 73 seconds. That step succeeded in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. A deployment adds Kubernetes access, the Prometheus endpoint, and provider billing configuration. Sharded Prometheus needs a global query layer such as Thanos Query, Cortex, or Mimir; the README warns that one shard can yield incomplete or intermittent exports.
What happened when we ran it
Our run built OpenCost successfully in 207 seconds. The Go test step then finished in 54 seconds with 54 passed and 0 failed out of 54. Both checks completed at commit ba0e947. They do not validate AWS, Azure, GCP, or on-premises prices because the sandbox had no secrets or live cluster services.
The checkout contained a tests directory and 16 CI workflow files. Our scan found no file named Dockerfile, although the contribution guide documents multi-architecture container builds and refers to Dockerfile.cross. The lab measured the Go repository build, while operators normally consume published images through Helm. Before rollout, verify the chart, image digest, embedded revision, Prometheus route, and provider configuration together.
Custom pricing needs reconciliation before internal chargeback
Open issue 4020 reports a serious but bounded pricing case in OpenCost 1.120.4. On OVH bare-metal nodes that fell back to custom pricing, configured hourly CPU and RAM rates appeared divided by about 730 before node cost calculation. The reporter supplied live metrics, configuration values, and a CSV-provider workaround, but did not identify the exact code line. The report justifies comparing calculated totals with a known node and the provider invoice.
Our 54 passing tests finished with 0 failures, yet they cannot settle a provider-specific runtime report that depends on live configuration and node metadata. Build an acceptance set around your environment: a known node-hour, one persistent volume, one load balancer, and a namespace with predictable requests. Use the result for chargeback only after those totals reconcile within an agreed tolerance.
The opt-in MCP server exposes four cost-query tools
OpenCost includes an HTTP Model Context Protocol server with four documented tools: allocation costs, asset costs, cloud costs, and efficiency recommendations. It is disabled by default and uses port 8081 when enabled. Filters can narrow cloud results by provider, service, region, category, and account. The efficiency tool groups workload data and applies a recommendation buffer.
The MCP feature does not change the data requirements. Answers still depend on Prometheus coverage, provider pricing, the requested window, and choices such as idle-cost sharing. Our 207-second build says the source compiled; it says nothing about whether an agent received accurate costs. Keep the server private without a reviewed exposure design, and compare agent responses with the underlying API queries.
August 2026 activity points to active maintenance
GitHub recorded a push on August 26, 2026. Release v1.121.1 was published on August 5 with AWS Athena result reuse configuration, NAT gateway metrics, GPU allocation work, and pricing changes. GitHub listed 296 combined issues and pull requests. That is a queue rather than a defect count, and current pull requests plus issue updates show ongoing work.
Release discipline still deserves checking. Open issue 3888 reports that image tag 1.120.4 shipped a binary based on a 1.120.3-era revision, 18 commits behind the named tag. This was a specific image and does not establish a problem with v1.121.1. It does make digest pinning and go version -m inspection reasonable deployment checks.
OpenCost suits shared clusters better than simple cloud bills
The strongest use case is a platform team with several namespaces, shared nodes, and an existing Prometheus service. OpenCost can export metrics, answer API queries, track AI inference costs for compatible vLLM deployments, and join cluster allocation with cloud-service spending. Apache-2.0 licensing permits internal changes, while the specification gives vendors and users a common model for cost data.
The source result is reassuring: 458 packages installed, the 207-second build passed, and all 54 measured tests passed in 54 seconds. Adoption still depends on data plumbing and reconciliation. Choose OpenCost for live Kubernetes allocation when the team can own Helm, Prometheus, cloud credentials, and validation. Choose Infracost for change-time estimates or Goldilocks for resource requests when those narrower questions are all you need.