Cost optimization

The cost_optimization skill turns "where is this cluster wasting money?" into an evidence-gathering session: usage vs. requests, idle workloads, orphaned storage — ending in recommendations, with any destructive follow-up parked behind the approval gate.

An end-to-end session

Illustrative session — output shortened for readability

$ kopilot ask "Review the staging namespace for cost savings"

[cost_optimization] kubectl top pods -n staging
NAME                        CPU(cores)   MEMORY(bytes)
api-7d9c6bf4b6-l2xkw        19m          212Mi
api-7d9c6bf4b6-tr8fz        23m          198Mi
worker-5f6d8b79d-qv4tp      6m           88Mi
reports-64d5c9b87-x8mzn     1m           38Mi

[cost_optimization] kubectl get deploy -n staging \
  -o custom-columns='NAME:.metadata.name,READY:.status.readyReplicas,DESIRED:.spec.replicas'
NAME      READY    DESIRED
api       2        2
worker    1        1
reports   <none>   1

[cost_optimization] kubectl get pvc -n staging
NAME           STATUS   VOLUME   CAPACITY   AGE
reports-data   Bound    pv-101   50Gi       241d

Findings
- api requests 500m CPU / 1Gi per replica; sustained usage is ~20m /
  ~210Mi. That is under 5% CPU utilization of the request.
- reports has 0 ready replicas and a 50Gi PVC still bound. No pod
  has mounted it recently.

Recommendations
1. api: lower the CPU request toward 100m and memory toward 384Mi,
   monitor for CPU throttling, then adjust limits.
2. reports: confirm with the owning team, then remove the deployment
   and reclaim the PVC. Both actions are destructive:

   kubectl delete deployment reports -n staging
   -> APPROVAL REQUIRED (high). Pending approval id 'e3a1f0b2c4d5'.
   kubectl delete pvc reports-data -n staging
   -> APPROVAL REQUIRED (high). Pending approval id '9f4c21d807aa'.

The analysis and the recommendation happen autonomously; the two deletes wait in the approval queue until a human decides. Denying them costs nothing — the findings are already in the answer and the audit log.

Prompt patterns that work

Goal	Prompt	What to expect
Right-sizing	`kopilot ask "Find over-provisioned deployments in staging and suggest safer requests"`	Usage vs. requests comparison and concrete target values, with the caveats that matter (restarts, throttling history).
Idle review	`kopilot ask "Which workloads in staging look idle enough to review?"`	A review list — candidates ranked with evidence, not deletions.
Orphaned storage	`kopilot ask "List PVCs not mounted by any running workload"`	PVC status, age, and namespace context; cleanup queued behind approval if you ask for it.
Action plan	`kopilot ask "Recommend the next three cost actions for staging, ordered by confidence and risk"`	An ordered plan that separates safe changes from approval-gated ones.

What Kopilot will not do automatically

Delete PVCs or workloads because they merely look idle — low usage is evidence for review, not authorization to destroy.
Rewrite deployment resources without surfacing the evidence and the proposed target first. kubectl patch and scale are destructive-classified and approval-gated.
Touch protected namespaces destructively — those commands are refused, not queued.
Batch several risky actions into one opaque step; each destructive command gets its own approval id.

Accurate right-sizing needs metrics: kubectl top requires metrics-server (or equivalent) in the cluster. Without it, Kopilot can still inspect requests, replicas, and object references, but usage-based findings will be limited — and it should say so in its answer.