Right-size every pod without fighting your pipeline
Most pod requests are set once, padded for safety, and never touched again. Sedai right-sizes CPU and memory continuously from live behavior and SLOs, in small verified steps, and applies changes as pods are created so CI/CD never reverts them.
Animation: a workload’s CPU request sits flat at 4 vCPU while actual usage stays below 2, leaving most of the request idle. Sedai lowers the request in three small steps, to 3.2, 2.6, and then 2.2 vCPU, verifying latency against the SLO after each one. The request stays above peak usage throughout.
Pod requests are guesses that never get revisited
Research attributes 29% of container spend to workload idle: CPU and memory that pods request but never use. It persists for three reasons.
Set once, at deploy time
Requests come from Helm defaults or a best guess when the service launched. Usage changes; the numbers don’t.
Padded out of fear
Nobody wants to cause an OOM kill or CPU throttling, so requests get padded, and cutting them by hand feels like a risk nobody owns.
Reverted as drift
Change a running workload by hand and your CI/CD pipeline flags it as drift and puts the old values right back.
Right-sized at creation, invisible to your pipeline
With Pod Interceptor, Sedai right-sizes each pod as it’s created instead of editing your deployment spec. Your IaC and spec still agree, so CI/CD sees no drift and nothing gets reverted. Guardrails as Code sets the limits on what Sedai can change.
Sizing that understands the application
Recommendations are easy. Changes you can trust in production are the hard part.
Application-aware, not just resource-aware
Sizing decisions account for latency, error rates, and your SLOs, not CPU and memory alone.
Small, verified increments
Sedai adjusts requests and limits a step at a time, verifies each change against live behavior, and rolls back automatically if anything drifts.
Vertical and horizontal, together
Native VPA and HPA conflict on the same workload. Sedai’s vertical scaling runs alongside HPA and tunes its target, finding the most cost-effective balance of pod size and replica count.
Your level of autonomy
Start with recommendations in Datapilot, approve changes in Copilot, and move to Autopilot as confidence grows.
Rightsizing is where savings start, not where they land
Smaller requests free up capacity in small pieces across every node, but the bill drops only when nodes go away. In a modeled 40-node cluster, rightsizing alone cut node spend by 5%. Adding placement, consolidation, and scaling tuning cut it by 38%.
Bin packing & pod placement
Sedai Scheduler packs your right-sized pods densely onto fewer nodes
Node consolidation
Sedai Compactor clears stranded pods so your autoscaler can remove empty nodes
Karpenter optimization
Accurate requests mean Karpenter provisions fewer, smaller nodes
Native VPA vs. Sedai rightsizing
Same goal. Very different results in production.
| Native VPA and manual tuning | Sedai |
|---|---|
Can’t run alongside HPA on the same workload | Runs alongside HPA and tunes its target |
Manual changes reverted by CI/CD as drift | Applied at pod creation, so nothing drifts |
Sizes on CPU and memory alone | Accounts for latency, errors, and SLOs |
One-time recommendations that go stale | Continuous, in small verified increments |
Freed capacity stays on half-empty nodes | Paired with placement and consolidation |
See how much your pods are really asking for
Compare used and requested capacity across your clusters with a Sedai engineer.
Frequently asked questions
Yes. Native VPA and HPA conflict on the same workload, so most teams turn VPA off in production. Sedai’s vertical scaling runs alongside HPA and also tunes the HPA target.
No. With Pod Interceptor, Sedai right-sizes the pod at creation rather than editing the deployment spec, so your IaC and spec stay in agreement and nothing is flagged as drift.
Use Sedai’s original execution model with IaC loopback, which writes changes back to your infrastructure code. Guardrails as Code limits what Sedai can change under either model.
From live workload behavior and your SLOs. Sizing accounts for latency and error rates as well as CPU and memory, and changes are made in small increments that are verified before Sedai goes further.
Yes. Guardrails as Code sets boundaries such as minimum and maximum values or excluded workloads, and Sedai stays within them.
Yes. Start in Datapilot for recommendations only, move to Copilot to approve each change, and switch to Autopilot when you’re ready.
Smaller requests free capacity on existing nodes, but the pods stay where they are, so no nodes are released. Placement and consolidation turn that freed capacity into nodes your autoscaler can remove.