Platform engineers are responsible for keeping production stable under dynamic demand: monitoring resource contention, maintaining capacity buffers ahead of traffic spikes, and ensuring workloads don’t starve when it counts. Those resources are provisioned deliberately. They exist because the cost of an SLO breach is higher than the cost of the resource buffer that prevents one.
The problem is that the same provisioning logic gets applied everywhere. Dev namespaces that run intermittently and carry zero user traffic get the same resource floor as your most critical production APIs. Not because anyone decided to treat them equally, but because no existing tool makes it practical to enforce different rightsizing strategies per environment at the scale most teams operate.
The 2026 State of Kubernetes Optimization Report covering tens of thousands of clusters reflects the result: the overwhelming majority of clusters over-provisioned, with CPU utilization averaging 8% and memory at 20%. CPU overprovisioning rose to 69% year over year, while memory overprovisioning stands at 79%. That’s the price of uniform provisioning when your cluster has many environments and none of them are the same.
Two Environments, Two Entirely Different Goals
In production, the optimization goal is stability first. You want minimum replicas guaranteed, resource buffers that absorb traffic spikes without triggering the autoscaler, and conservative scaling behavior. Stability is a feature, and in this context some over-provisioning is acceptable.
In dev and staging, the math flips. Workloads run intermittently, no real user traffic hits them, resources sit idle for hours. The cost of over-provisioning in dev is purely waste. Aggressive rightsizing and lower minimum replicas are the right call. The worst-case consequence of a resource boundary being too tight is a failed test, not a customer incident.
Most platform engineers understand this distinction. The problem is that it never gets encoded into actual infrastructure. Resource requests get set once during initial deployment and never updated, because changing app-owned Deployment manifests means tickets, approvals, and touching configuration owned by application teams with different priorities. The Kubernetes VPA can recommend resource changes, but in its default Auto update mode it evicts and restarts pods to apply them, and it has no concept of policy abstraction. You can’t tell it to apply conservative recommendations to stateful workloads and aggressive ones to stateless deployments. And manual rightsizing at any serious cluster size is a maintenance job no one signed up for. The root cause is always the same: static rules authored by operators go stale the moment workload behavior changes, and no amount of tooling around them closes the gap between what a rule assumes and what the cluster actually needs.
From Static Policies to Autonomous Decisions
Goldilocks shows you what VPA recommends. Kubecost shows you what you’re spending. Recommendation engines built on static, operator-authored rules show you what to change and wait for a human to act. But that human has a backlog, and their policies are going stale before they’re applied.
Cast AI’s OpsPilot closes that gap. Instead of requiring you to manually design policies, OpsPilot interprets your cluster’s signals (workload behavior, resource usage, stability patterns) and generates policies calibrated to what it actually finds.
Set your intent once: what to prioritize (savings vs. reliability vs. balanced), what kind of workloads are running (production, non-production, mixed), and optionally which namespaces to leave alone.
OpsPilot takes it from there. It takes a real-time snapshot of the cluster, covering every workload, recent resource usage history, and current policy assignments, then uses it to generate custom policies, each tailored to the workloads it actually found in your cluster.
These are not pre-defined templates. The policies are shaped by what OpsPilot detected: workload behavior, resource usage patterns, stateful vs. stateless characteristics, namespace context. No rules to write, no templates to configure, no policies to maintain as workloads evolve.
A typical output looks like this:
| Policy (AI-generated) | Policy (AI-generated) | Policy (AI-generated) |
|---|---|---|
| Stateful ( Conservative) | Databases, queues, caches identified by workload type and behavior | Generous headroom (high cost of getting these wrong) |
| Production (Balanced) | Stateless production services with stable usage patterns | Real savings without introducing risk |
| Cost-saving-deployments | Deployments running stateless application services: APIs, web servers, workers; where aggressive rightsizing toward observed usage is safe | Tight rightsizing based on actual resource consumption patterns (maximum savings where the blast radius of a miscalculation is low) |
The critical design decision: Cast AI OpsPilot groups by risk profile, not just by namespace. A stateful database and a stateless API in the same namespace get different policies because they carry different risks. That’s what makes OpsPilot more useful than a template picker. The AI reasons about each workload’s actual behavior and assigns it to the right group.
Every recommendation comes with a rationale explaining why OpsPilot chose those settings for that group. You review everything, which workloads land where, what percentiles are set, what constraints apply, then click Apply policies. That single click creates all policies and assignment rules using the same APIs you’d use manually, and displays everything on the Policies page where it’s all visible, editable, and reversible.
OpsPilot improves as your cluster matures. Deployed new services? Re-run it. More usage history available? Re-run it. Better data means better recommendations.
Available Now, for All Cast AI Customers
- Go to your Cast AI Console.
- Click “Try OpsPilot” on the workload optimization page.
- Answer the three questions.
- Review the AI recommendations.
- Click Apply.
If you want to be cautious, apply the policies in disabled mode first so you can see the recommendations without any changes being applied to workloads. Once you’re confident, enable them.
As your cluster evolves, re-run OpsPilot anytime. Each run starts fresh with the latest data. This is what Kubernetes workload management looks like when the tuning is continuous and the policies write themselves.
New to Cast AI? Start a free trial and connect your first cluster.
