OpenCost: Kubernetes cost allocation from Helm, with an opt-in MCP server

The problem OpenCost solves: shared Kubernetes clusters with no per-team bill

A cloud bill tells you what a provider charged. It does not tell you which namespace, controller or pod inside a shared cluster caused the charge. OpenCost exists to close that gap. The README describes it as giving teams visibility into current and historical Kubernetes and cloud spend and resource allocation, with models built for environments that host multiple applications, teams and departments.

The intended reader is a platform or infrastructure engineer who has to answer questions like which team is responsible for a node's cost, or how much a persistent volume contributes to a monthly total. OpenCost also covers cloud services outside the cluster on AWS, Azure and GCP, so the same tool can report both the cluster slice and the wider cloud spend. It was originally developed and open sourced by Kubecost, and the repository ships both a specification under spec/ and a Go implementation of it.

How allocation works: Prometheus as the source, a pricing model on top

OpenCost does not instrument your workloads. It reads the metrics your cluster already exports and applies a pricing model. The repository layout reflects this: modules/prometheus-source and modules/collector-source sit beside the main Go code, and the README points to a /metrics endpoint for exporting pricing data back to Prometheus.

The allocation dimensions listed in the README are cluster, node, namespace, controller kind, controller, service and pod. For in-cluster resources it reports CPU, GPU, memory and persistent volumes. Prices come from two directions: dynamic on-demand asset pricing through AWS, Azure and GCP billing APIs, or a custom CSV for on-premises clusters that have no cloud price list to query. Cloud services are handled separately through cloud cost ingestion, which the Tilt values file turns on with CLOUD_COST_ENABLED and CLOUD_COST_CONFIG_PATH.

The Prometheus dependency is the part that bites. The README carries a note for sharded (HA) Prometheus users: set PROMETHEUS_SERVER_ENDPOINT to a global query endpoint such as Thanos Query, Cortex or Mimir, because pointing at a single Prometheus pod may return incomplete or intermittent export results. That is not a tuning detail. It changes what you must have in place before OpenCost is trustworthy.

Installing OpenCost with Helm and reading the first allocation

The README states that OpenCost is now installed and managed via the official Helm chart only, and that the standalone Kubernetes manifest files have been removed. Anything you find describing kubectl apply against a manifest is stale. The supported path is on any Kubernetes 1.20+ cluster:

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update
helm install opencost opencost/opencost

After the release is up, the README lists the ways to consume the data: cost APIs, the kubectl cost CLI, Prometheus metrics and a user interface. The UI lives in the separate opencost/opencost-ui repository, and the docs page for it is linked from the README.

If you want the MCP server, it is opt-in and disabled by default in every deployment. It runs on port 8081 and is built into the Helm chart:

helm install opencost opencost/opencost --set opencost.mcp.enabled=true
kubectl port-forward svc/opencost 8081:8081

The chart also accepts a custom port and a log level, for example --set opencost.mcp.port=9091 and --set opencost.mcp.extraEnv.MCP_LOG_LEVEL=debug. The README does not document a rollback procedure for the MCP server beyond changing the Helm values back, so treat enabling it as a deliberate change you can reverse by reinstalling or upgrading the release with the flag removed.

The MCP server is off for a reason

OpenCost's MCP server exposes allocation, asset and cloud cost queries over HTTP to AI agents. The README is explicit that it is disabled by default in all deployments to minimize the attack surface, and that users must enable it explicitly. That default is the right call, and it is worth respecting rather than flipping on because it sounds useful.

Once enabled, the surface includes allocation queries with filtering and aggregation, asset queries covering nodes, disks and load balancers, and cloud cost queries filtered by provider, service and region. All of that is reachable over HTTP on port 8081. The README does not describe an authentication layer for the MCP endpoint, so the practical control is network reachability: if you enable it, decide who can route to that port before you port-forward it anywhere.

The same caution applies to the newer AI inference cost tracking, which the README describes for vLLM-based deployments including llm-d, reporting cost per million tokens for input and output, KV cache-corrected pricing and shared infrastructure attribution. That is a real capability, but it is scoped to vLLM-compatible deployments, not to arbitrary inference stacks.

Where OpenCost is the wrong tool

OpenCost is a cluster and cloud cost allocator, not a budget enforcement system. Nothing in the README describes admission control, quota enforcement or automatic remediation when a namespace overspends. If your requirement is to stop spend rather than to attribute it, OpenCost reports the number after the fact.

The Prometheus dependency is the second boundary. On a sharded setup without a global query endpoint, the README's own warning is that results can be incomplete or intermittent. A cost report that is sometimes wrong is worse than no report if people make staffing or migration decisions from it, so a Thanos Query, Cortex or Mimir endpoint is effectively a prerequisite in that topology.

Third, dynamic on-demand pricing depends on integrations with AWS, Azure and GCP billing APIs. If you cannot grant that access, you fall back to custom CSV pricing for on-prem clusters, which means someone has to maintain the price list. The README does not describe an automatic refresh for that CSV.

OpenCost and Kubecost: same origin, different distribution

The README states that OpenCost was originally developed and open sourced by Kubecost. That shared origin is why the two get compared, and it is also why the practical difference is not the allocation model. OpenCost is a free and open source distribution under the Apache 2.0 license, maintained as a CNCF project with a published specification in the spec/ directory and a Go implementation of those requirements.

Kubecost is the commercial product from the same lineage. The README does not describe Kubecost's feature set or pricing, so any comparison beyond the origin and the licence has to come from somewhere other than this repository. What the repository does show is the shape of the open project: Helm-only installation, a separate UI repository, a plugin mechanism for external costs such as Datadog through opencost-plugins, and a metrics endpoint you can wire into your own Prometheus and Grafana dashboards. If your deciding factor is a single vendor contract with support attached, OpenCost is not that product. If your deciding factor is Apache 2.0 code you can read against a written specification, it is.

Maintenance, releases and what the licence does not decide for you

The repository is not archived, and the last push was on 2026-09-16. The release cadence is visible in the tags: v1.121.1 on 2026-08-05, v1.121.2 on 2026-09-11 and v1.121.3 on 2026-09-16. Patch releases landing days apart suggest fixes are being cut quickly, though the README does not document a support window or a deprecation policy for older minor versions.

The upgrade cost is mostly tied to the Helm chart, since that is the only supported install path. Upgrading means a helm upgrade against the same release, and your configuration lives in values rather than in edited manifests, which makes the diff reviewable. The heavier cost is the Go module graph in go.mod, which pulls in AWS, Azure, Google and Alibaba SDKs plus a large Kubernetes dependency tree, and the repository is split into replace directives for core, modules/collector-source and modules/prometheus-source. Building from source is a real undertaking; running the chart is not.

On licensing, OpenCost itself is Apache-2.0, as the README and the LICENSE file state. The repository also carries a THIRD_PARTY_LICENSES.txt and a NOTICE file, and the Go dependencies listed in go.mod bring their own terms. Apache-2.0 covers the project's own code, not the licence obligations of every dependency or of the cloud APIs you connect it to. That is a question for your own legal review.

Editorial conclusion

Adopt OpenCost if you run Kubernetes 1.20+ and want per-namespace, per-controller or per-pod cost allocation without paying for a hosted product, and expect to install it with Helm because the standalone manifests no longer exist. Skip it if a single flat cloud bill is enough for your team, or if you run sharded Prometheus without a global query endpoint such as Thanos Query, Cortex or Mimir, because the README warns that pointing at one Prometheus pod can produce incomplete or intermittent export results. Before you commit, verify your Prometheus query endpoint, decide whether opencost.mcp.enabled should stay false, and confirm which cloud billing APIs you can grant access to, since dynamic on-demand pricing depends on them.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. opencost/opencost on GitHub
3. Project website
4. README
5. Releases