optops

Analyze a Kubernetes cluster and estimate what it could cost.

npx optops@latest analyze

No account, no operator, no signup. It reads your current kube-context, computes locally, and prints four panels: what you run, how much of it you use, what is blocking consolidation, and what the same workload would cost.

Example

╭─ Cluster Snapshot ─────────────────────────────╮
│  Nodes            4                            │
│  CPU capacity     7.7 cores                    │
│  Memory capacity  32 GiB                       │
│  Provider         GCP                          │
│  Capacity mix     100% spot                    │
╰────────────────────────────────────────────────╯

╭─ Utilization ──────────────────────────────────╮
│  CPU                                           │
│  █░░░░░░░░░░░░░░░░░░░  10% used                │
│  0.7 cores used of 7.7 · 6.0 requested (77%)   │
╰────────────────────────────────────────────────╯

╭─ Estimated optops Savings ─────────────────────╮
│  Current spend    $87/mo                       │
│                                                │
│  Rightsizing      $44/mo −49%                  │
│                   requests 15x usage on CPU    │
│                                                │
│  On-demand mix    $163/mo                      │
│                   $76/mo more — already spot   │
│                                                │
│  All-spot (max)   $54/mo −38%                  │
╰────────────────────────────────────────────────╯

Usage

optops analyze                     # current kube-context
optops analyze --context staging   # a specific context
optops analyze -o json | jq        # machine-readable, same figures
optops analyze -o plain            # no colour or box drawing, for CI
optops version

analyze-cluster still works as an alias for analyze.

What it needs

Read access to the cluster. It never writes:

- apiGroups: [""]               resources: [nodes, pods]           verbs: [get, list]
- apiGroups: ["policy"]         resources: [poddisruptionbudgets]  verbs: [get, list]
- apiGroups: ["metrics.k8s.io"] resources: [nodes, pods]           verbs: [get, list]

metrics-server is optional. Without it the Utilization panel is blank and the rightsizing row is omitted — the remaining scenarios work from pod requests.

How the estimate works

Four scenarios, priced against a catalog baked into the binary at build time:

| Scenario | Meaning | |---|---| | Rightsizing | Requests sized to observed usage at a 70% ceiling, then repacked | | On-demand mix | Cheapest on-demand fleet for the same workload | | Spot-friendly | Interruption-tolerant workloads on spot, the rest on-demand | | All-spot | Everything on spot — an upper bound, not a target |

Deliberate properties worth knowing:

• Only rightsizing reads usage. The other three re-pack today's requests unchanged, so on a cluster requesting far more than it uses, rightsizing is usually the largest number by some margin.
• Rightsizing is scaled by 0.85. A single snapshot cannot see burst headroom or seasonal peaks, so the figure is discounted. Both numbers are in the JSON.
• Architecture is respected. An x86 cluster is never offered ARM instances its images cannot start on.
• DaemonSets are a per-node tax, carried on every proposed node rather than treated as movable demand.
• Savings are capped at 60% by platform convention; the raw figure is in the JSON as uncappedSavingsPercent.
• Nothing is modelled that isn't stated. Pod affinity, topology spread, PodDisruptionBudgets and resource limits are not simulated, and the output says so.

Proposed instance types are in -o json under proposedNodes, so every figure can be recomputed by hand.

Figures are estimates from public list prices, not a quote.

Install

npx optops@latest analyze            # no install
npm install -g optops                # or install it
go install github.com/optops-ai/optops-cli/cmd/optops@latest   # or from source

Prebuilt binaries: macOS (arm64, x64), Linux (arm64, x64), Windows (x64).

Licence

Apache-2.0