Once it was running, we barely had to touch it.
Platform Engineering team, Global SaaS company
Both platforms automate Kubernetes optimization. The difference is what they require to do it and what they optimize for.
CAST AI takes control of node provisioning at the cloud-provider level, then uses bin-packing and spot orchestration to pursue deep infrastructure savings. That model is powerful when teams want a vendor to run their nodes and are comfortable granting standing cloud-account write access.
PerfectScale™ starts read-only and keeps node control inside your IAM boundary. It right-sizes workloads with stability-first guardrails, supports in-place changes without pod restarts, adds automated commitment purchasing, and attributes shared infrastructure and AI spend to customers, features, and agents without tagging.
Where the platforms genuinely differ, and where CAST AI’s direct node control remains a strength.
PerfectScale™ observes clusters through get, list, and watch permissions. Its exporter cannot launch or terminate instances and holds no cloud-provider credentials. CAST AI also begins with a read-only phase, but its node optimization requires a second phase with cross-account cloud IAM permissions to create and destroy compute.
// SECURITY BOUNDARY
PerfectScale™ balances savings with resilience signals such as OOM kills, CPU throttling, and under-provisioning. PodFit uses workload history and policy-specific headroom so teams can tune non-production, balanced, and mission-critical services differently instead of applying one savings target everywhere.
// RIGHTSIZING MODEL
On Kubernetes 1.33+ with in-place resize enabled, PerfectScale™ can update CPU and memory without restarting a pod. It raises constrained resources immediately, reduces excess gradually, and reverts a change if the new request leaves the workload unschedulable. CAST AI also supports in-place rightsizing, while its broader savings model uses eviction and node removal to compact the cluster.
// AUTOMATION SAFETY
PerfectScale™ improves workload requests and analyzes the configuration of Karpenter, Cluster Autoscaler, and GCP Autopilot. InfraFit recommendations improve bin-packing and node-pool efficiency while your existing autoscaler remains the authority. PerfectScale™ also automates Spot adoption for AWS Auto Scaling Groups, including mixed-instance policies and On-Demand fallback, without replacing the Kubernetes node autoscaler. CAST AI replaces the node layer with its own provisioning, compaction, and spot control. That can suit teams seeking outsourced node management, but standards-based integration preserves more portability and control.
// NODE STRATEGY
A global SaaS platform running GKE and EKS at scale evaluated PerfectScale™ and CAST AI over eight months, from non-production through full production rollout. Both platforms delivered similar cost savings. The decision came down to production confidence. PerfectScale™ ran the entire evaluation with zero production resiliency issues, required minimal operational effort after deployment, and automated safely across every environment tier.
// EVALUATION RESULTS
CAST AI imports existing Reserved Instances, Savings Plans, CUDs, and capacity reservations so its autoscaler can consume them efficiently. PerfectScale™ goes further by continuously sizing and executing new AWS Savings Plans, AWS Database Savings Plans, and Google Cloud CUD purchases with laddering, hourly re-evaluation, and optional approvals.
// COMMITMENT LAYER
CAST AI provides strong Kubernetes allocation by cluster, workload, namespace, label, and allocation group. Its Kvisor agent adds eBPF-based network cost visibility across workloads and zones. PerfectScale™ goes from infrastructure dimensions to business unit economics. Its lightweight eBPF sensor observes runtime consumption and maps shared cluster, database, network, GPU, and AI cost to the customer, feature, team, or agent that drove it. This runtime approach does not rely on tagging.
// UNIT ECONOMICS
PerfectScale™ publishes a per-vCPU model and includes a free Community tier for up to 300 monthly vCPUs. CAST AI’s paid optimization is commonly sold through savings-based and CPU-based fees, with exact commercial terms varying by agreement. A flat model keeps the vendor bill predictable as infrastructure and realized savings grow.
// COMMERCIAL MODEL
The platforms operate at different layers, so evaluation carries no switching risk. A common pattern keeps CAST AI managing node provisioning while PerfectScale™ takes over workload rightsizing, with CAST AI’s workload autoscaler disabled to avoid conflicting changes. You can compare resiliency and savings on real production workloads before making any larger decision. Start with the read-only agent: one Helm install, no cloud IAM changes, no credit card, and cost and resilience analysis in about five minutes. Let it observe for a week before enabling automation so recommendations reflect real usage. The Community tier covers up to 300 monthly vCPUs free.
// EVALUATION PATH
PerfectScale™ is part of DoiT Cloud Intelligence, connecting Kubernetes optimization with multicloud cost allocation, commitment management, anomaly detection, runtime cost attribution, and GenAI cost. DoiT Forward Deployed Engineers and FinOps consultants add hands-on expertise when teams need more than software. CAST AI remains a focused Kubernetes automation platform with support and customer success.
// PLATFORM DEPTH
kubernetes network attribution
Network is often 20 percent or more of Kubernetes spend, and it is the part nobody can explain. Cross-AZ replication, inter-cluster traffic, and NAT egress land as anonymous line items because there is no tag on a packet.
PerfectScale traces every traffic path to the customer and feature behind it. When cross-AZ cost jumps 27 percent, you see which feature caused it and which account to have the conversation with, instead of averaging the bill across everyone.
A practical comparison based on current public product documentation and each platform’s operating model.
| Capability | PerfectScale™ | CAST AI |
|---|---|---|
| Architecture & permissions | ||
| Default observability footprint | Read-only agent Kubernetes get, list, and watch permissions; no cloud credentials. | Read-only Phase 1 Initial monitoring does not modify the cluster. |
| Cloud-account write access for workload rightsizing | Not required Workload automation stays inside Kubernetes RBAC. | Required for node automation Phase 2 uses cross-account permissions to create and terminate compute. |
| Node provisioning approach | Native autoscaler integration Works with Karpenter, Cluster Autoscaler, and GCP Autopilot to preserve flexibility. | CAST-managed provisioning Replaces the standard autoscaler, drains workloads, and removes nodes. |
| Workload & node optimization | ||
| Workload rightsizing | PodFit Policy-driven CPU and memory recommendations and automation. | Workload Autoscaler Rightsizing with gradual rollout controls. |
| JVM-aware rightsizing | Automatic Java detection With JVM collection enabled, heap, non-heap, and GC metrics inform sizing; explicit heap parameters are respected. | JVM optimization when enabled Uses heap, non-heap, GC, and thread metrics via JMX auto-instrumentation or Prometheus. |
| In-place resize without pod restart | Kubernetes 1.33+ | Supported |
| Node strategy | Standards-based and portable InfraFit improves Karpenter, Cluster Autoscaler, and GCP Autopilot configurations. | Vendor-owned node control Uses CAST AI’s autoscaler and Evictor for provisioning and compaction. |
| Spot orchestration | AWS ASG spot automation Configures mixed-instance policies, provisions Spot, and falls back to On-Demand. | Automated spot with fallback Strong fit for interruption-tolerant workloads. |
| Automation safety & resilience | ||
| Resource reduction strategy | Gradual reductions Constrained workloads scale up immediately; waste is removed gradually. | Gradual rollout Rightsizing changes can respect disruption controls. |
| Unschedulable-change recovery | Automatic rollback Reverts to the previous valid request when capacity is unavailable. | Scheduling and fallback controls Safety centers on provisioning and workload disruption configuration. |
| Resilience analysis | 30+ risk types Includes OOM, CPU throttling, and under-provisioning. | Reliability metrics Includes spot interruption prediction and cluster health signals. |
| Commitments & rate optimization | ||
| Automated commitment purchasing | Risk-aware execution Autonomous or approval-gated purchases with laddering and guardrails. | Not offered CAST AI imports and consumes commitments purchased elsewhere. |
| Commitment coverage | AWS and Google Cloud Savings Plans, Database Savings Plans, and Google Cloud CUDs. | Imported commitments Commitment-aware autoscaling uses existing RIs, SPs, CUDs, and reservations. |
| Continuous commitment sizing | Hourly re-evaluation Fresh usage validates each next purchase step. | Manual purchase strategy Sizing and buying new commitments remain with the customer. |
| Savings outcome reporting | ESR, utilization, and coverage | Imported commitment utilization |
| Cost attribution & unit economics | ||
| Kubernetes cost allocation | Infrastructure and runtime dimensions Cluster and workload views extend to customer, feature, team, and agent. | Allocation Groups Groups Kubernetes cost by cluster, workload, namespace, and label. |
| Per-customer and per-feature cost | Runtime attribution Maps shared consumption to the business entity that generated it without tags. | Metadata-defined groups Public documentation centers allocation on Kubernetes namespaces and labels. |
| Network cost visibility | Workload and business attribution Attributes egress and shared network cost to workloads, customers, and features. | Kvisor eBPF monitoring Traffic and cost by cluster, namespace, workload, and availability zone. |
| Shared database, GPU, and AI unit economics | Customer, feature, and agent Observed runtime use connects shared infrastructure and model calls to demand. | Infrastructure-level visibility Public materials focus on Kubernetes, GPU, and network infrastructure costs. |
| Observability & governance | ||
| Multi-cluster cost and waste views | Cost, waste, idle, risk, and carbon | Cluster, namespace, and workload cost |
| Policy-driven governance | SLA/SLO-aligned policies Respects LimitRange and ResourceQuota and records every revision. | Optimization policies Includes workload controls, allocation groups, and organization reporting. |
| Workflow integrations | Jira, Slack, Teams, and Datadog | Alerts and platform integrations |
| Pricing & onboarding | ||
| Paid pricing model | Published flat per-vCPU | Commercial terms vary Commonly described as savings-based plus CPU-based fees. |
| Free tier | Up to 300 monthly vCPUs | Free monitoring tier |
| Time to initial visibility | About five minutes Single Helm install with no cloud IAM setup. | Fast read-only connection Cloud IAM setup is added for node automation. |
| Platform & expertise | ||
| Kubernetes coverage | EKS, GKE, AKS, OpenShift, KOPS, Rancher, on-prem | EKS, GKE, AKS, OCI, and Anywhere |
| Broader FinOps platform | DoiT Cloud Intelligence Multicloud cost, commitments, data platforms, and GenAI. | Kubernetes-centered portfolio Expanded with Database Optimizer and AI Enabler. |
| Human expertise | Forward Deployed Engineers and FinOps consulting | Support and customer success |
Decision guide
In evaluations where both platforms deliver similar savings, the deciding factors tend to be production stability, operational overhead after deployment, and confidence in the roadmap.
You want a vendor to fully manage node provisioning, bin-packing, and spot orchestration; your workloads can tolerate the resulting movement and interruptions; you manage commitment purchases separately; and you are comfortable granting standing cloud-account write access.
You want to retain your IAM boundary, prioritize production resilience, automate workload rightsizing without giving up your node control plane, manage commitment purchases with guardrails, and connect Kubernetes cost to broader DoiT unit economics.
Once it was running, we barely had to touch it.
Platform Engineering team, Global SaaS company
PerfectScale cut 40% off our total EKS spend, and the automations handle what used to take our team 20 hours a month. Now we spend that time on reliability and performance instead of chasing cost metrics.
Caio Cristo, Director of Infrastructure/SRE
PerfectScale allowed us to grow capacity without growing cost. We effectively absorbed 30% more usage for free.
Thomas Comtet, Senior Staff Engineer
I believed in the product the first time I saw it. I still show it to everyone. It was the only solution that combined smart automation with real cost savings, without putting performance at risk.
Joao Soares, Platform Engineering Lead
PerfectScale gave us the answers we needed on a silver platter. The insights saved us time and money.
Jason Berk, Platform Operator
Yes. Both optimize Kubernetes workloads, but PerfectScale™ emphasizes stability-first rightsizing while keeping node provisioning inside your existing autoscaler and IAM boundary. CAST AI’s broader automation model directly manages the node layer.
Yes. Keep CAST AI managing nodes while PerfectScale™ handles workload rightsizing, with CAST AI’s workload optimization disabled to prevent conflicting changes. This supports a production comparison without a rip-and-replace migration.
No. CAST AI can import Reserved Instances, Savings Plans, CUDs, and capacity reservations, track their utilization, and make its autoscaler consume them intelligently. It does not size and buy new commitments for you. PerfectScale™ automates AWS Savings Plans, AWS Database Savings Plans, and Google Cloud CUD purchases with laddering, hourly re-evaluation, approval options, and spend guardrails.
PerfectScale™ detects Java containers and uses heap, non-heap, and garbage collection behavior in its recommendations. When heap parameters are explicitly set, automation does not apply a change that would violate them and risk JVM OOM failures.
Yes. PerfectScale™ uses runtime consumption to map shared Kubernetes, database, network, GPU, and AI costs to the customer, feature, team, or agent that generated them. Its eBPF-based approach does not depend on complete tagging.
Yes. In an eight-month GKE and EKS evaluation, both platforms delivered similar savings; PerfectScale™ recorded zero production resiliency issues and was selected for stability and low operational overhead. The evaluation measured about 52% lower infrastructure cost, 72% less waste, 30% fewer performance alerts, and 72 engineering hours saved each month.