Pod Rightsizing Pricing: What Automated Kubernetes Rightsizing Software Costs

Almost nobody in the Kubernetes rightsizing market publishes a price. Of the main automated vendors, PerfectScale by DoiT is the only one with a published entry point, free up to 200 vCPU per month and then priced per vCPU. StormForge by CloudBolt publishes a trial rather than a price: full optimization on one cluster for thirty days. Zesty prices against realized savings and publishes no figures. CAST AI, ScaleOps, Sedai, and Kubex all quote from sales. So the real work of budgeting for this category is not comparing list prices, it is understanding which of four pricing models you are being sold and what each one scales with.

This matters more than it sounds. Two vendors quoting what looks like the same annual number can behave completely differently in year two, because one grows with the cluster you are trying to shrink and the other only earns when the bill falls. Below is what each model does to your budget, what the published numbers actually are as of August 2026, and the arithmetic to take into the first call.

How much do Kubernetes rightsizing tools cost?

Four models cover the whole market. Free and open source costs nothing in licence and a real amount in engineering time. Per vCPU subscription charges on the compute you run. Savings share charges a percentage of measured reduction. Quote-only enterprise pricing tells you nothing until you take the call, which is where most of this category sits.

Which pod rightsizing vendors actually publish a number

Checked against vendor primary pages on 22 August 2026. Where a row says a vendor does not publish a price, that is what their own site says, and figures found in third-party comparison articles for these vendors should be treated as unverified.

One correction worth making explicitly, because it still circulates: CAST AI no longer publishes pricing. Their pricing page now says the model depends on factors specific to your environment and asks you to get in touch, and the form wants cluster count, GPU usage, and product interest. Any per-CPU figure for CAST AI in a comparison article, including several published by direct competitors, is stale. Do not build a budget on it.

Why per vCPU pricing quietly works against you

Per vCPU is the friendliest model to approve because it produces a number you can put in a spreadsheet. It also has a structural oddity: you are paying a rate on the compute you run, to a vendor whose job is to reduce the compute you run. Within a single term that is aligned, because as the fleet shrinks the bill shrinks with it. Across renewals it is not, because the list rate is what gets renegotiated and your cluster is usually growing for reasons that have nothing to do with waste.

The practical move is to model the cost at three sizes before signing: today, at your rightsizing target, and at the growth number in next year plan. If the vendor fee at the growth number is a meaningful fraction of the savings, negotiate a rate that steps down with volume rather than a flat per-unit price. PerfectScale free tier at 200 vCPU per month makes this easy to test cheaply, because you can run it on a real namespace and see the recommendation quality before any of this becomes a negotiation.

How savings-share pricing works, and the one clause that decides it

Savings share sounds like a free option and is not. You pay a percentage of measured reduction, so the vendor carries the burden of proof, which is genuinely attractive when finance will not approve a fixed cost against an unproven saving. Zesty takes this position explicitly, stating that pricing is based on actual usage and realized savings and that it will never be more than the value delivered.

Everything then depends on the baseline, and the baseline is defined in the contract, usually by the vendor. Four questions decide whether the deal is good:

What counts as a saving? Reduced requested CPU is not the same thing as a smaller invoice, and a contract that pays on the first while you are being measured on the second is a bad contract. Insist that the measured unit is cloud spend, or at minimum node hours.

Against which reference period? A single high month makes a permanent baseline that flatters every subsequent invoice. A trailing three-month average is harder to game. Ask what happens if the reference month contained a one-off migration or a load test.

For how long does a saving keep being billed? A reduction that happens once in month one can be charged for thirty-six months if the contract says so. Some vendors bill against a rolling recalculated baseline, which is fairer to you; some do not.

What happens when the cluster grows for unrelated reasons? If you launch a product and the bill doubles, does the model treat that as lost savings, and does the fee follow? Get the answer in writing before the trial, not after it produces a number you like.

What free actually costs

The open-source path is real and most teams should walk it first. The Vertical Pod Autoscaler produces recommendations from observed usage, Goldilocks puts a dashboard on top so you can read them per namespace, and Kubecost free Foundations covers unlimited clusters up to 250 cores with 15-day metric retention so you can see the same gap in dollars. Two weeks of this gives you the number that justifies everything else, and it costs a licence fee of zero.

What it costs instead is the application step. VPA default way of applying a recommendation is to evict the pod, and its in-place path, InPlaceOrRecreate, is an alpha feature gate that is disabled by default and has to be enabled on both the updater and the admission controller. The underlying primitive, in-place pod resize, reached stable in Kubernetes v1.35, but memory changes commonly still restart the container because many runtimes cannot adjust memory allocation dynamically. So the free stack gives you excellent numbers and a genuinely awkward rollout, and the engineering hours you spend closing that gap are the actual price. For a small estate that is cheap. For four hundred services across nine teams it is a project, and that is the point at which a commercial tool starts to look inexpensive.

The arithmetic to take into the first sales call

Work it out before anyone shows you a deck, because a vendor savings estimate built on their own benchmark data is not a forecast of your bill. Take a worked illustration with the assumptions stated, and substitute your own numbers.

Suppose Kubernetes compute costs 50,000 dollars a month. VPA and Goldilocks show that requested CPU across the fleet exceeds observed p95 usage by roughly 40 percent. You will not recover all of that, because headroom for spikes is not waste and some workloads cannot be touched, so assume you realistically recover 25 percent of the bill: 12,500 dollars a month, or 150,000 dollars a year.

Against that, a savings share at 25 percent costs 3,125 dollars a month and nets you 9,375. A per vCPU subscription is a fixed number you can now sanity-check: if the quote comes back above roughly 3,000 dollars a month for this fleet, it is competing with the savings-share option on worse terms. And the free path costs nothing in licence but requires somebody to apply and monitor the changes across the estate, which you can price in engineer-days and compare directly.

That single page of arithmetic changes the character of every vendor conversation, because you arrive with a ceiling rather than discovering one. It also protects you from the most common failure in this category, which is paying for rightsizing and seeing no change on the invoice. Requests are a scheduling reservation, not a charge. If nothing consolidates workloads onto fewer nodes afterwards, you have converted allocated capacity into idle capacity at identical cost. Measure node count and cost per core, not requested CPU, and make sure the contract measures the same thing you do.

The cost that never appears in the quote

Aggressive rightsizing has a failure mode, and it is not subtle: memory limits set too close to real usage produce OOM kills, and CPU requests cut too far produce latency that nobody attributes to the cost project for several days. Kubernetes documents the specific version of this risk for in-place resizing, noting that when decreasing memory limits the kubelet makes only a best-effort attempt to prevent OOM kills and provides no guarantees, and that the resize is skipped entirely if usage already exceeds the new limit.

The cheap insurance is to have an independent signal that tells you a service stopped answering, rather than relying on the same platform doing the optimizing to report on itself. An external check that hits your public endpoints and APIs on a short interval, of the kind an uptime monitoring service provides, catches the regression from outside the cluster and timestamps it, which is exactly what you need when the argument is whether Tuesday latency spike came from the rightsizing rollout or from something else entirely. Budget for it, alongside a rollback plan and a rollout that widens by namespace rather than by flipping the whole fleet at once.

Is a paid rightsizing tool worth it?

It is worth it when the gap between recommendation and application is where your program dies, which is most of the time. Free tooling tells you what the requests should be. Paid tooling applies the change continuously, coordinates with the horizontal pod autoscaler so vertical and horizontal scaling do not fight, and drives node consolidation so the reduction actually reaches the invoice. If you have one cluster and a patient platform engineer, the free stack is genuinely sufficient. If you have dozens of clusters and hundreds of services, the licence is smaller than the salary cost of doing it by hand, and the honest comparison is not tool versus free, it is tool versus the engineer-months you are currently spending or the savings you are currently not capturing.

The sequence that works: measure free for two weeks, calculate your own ceiling, take the PerfectScale free tier or the StormForge thirty-day cluster trial to test recommendation quality on real workloads, then negotiate with a number in hand. For the full vendor-by-vendor comparison including scope, autonomy, and how each one applies a change, see our guide to Kubernetes rightsizing tools. If the wider question is visibility and allocation rather than automated resizing, the best Kubernetes cost tools comparison covers that set instead, and Kubernetes cost optimization walks through the steps that come before you buy anything.