Analysis updated 2026-05-18
Get AI-suggested cost savings for over-provisioned Kubernetes deployments.
Check proposed scaling changes against safety rules before they run.
See a dashboard of cluster health and which remediation actions were approved or rejected.
| viswa0028/agentbuilders-helmsman | 0xradioac7iv/tempfs | 52191314/web-agent-proxy-sdk | |
|---|---|---|---|
| Stars | 0 | 0 | 0 |
| Language | TypeScript | TypeScript | TypeScript |
| Setup difficulty | hard | moderate | moderate |
| Complexity | 4/5 | 3/5 | 4/5 |
| Audience | ops devops | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
Requires a running Kubernetes cluster (kind is used in examples) and Node.js 18 or newer.
HelmsMan is a tool for managing Kubernetes clusters, the systems many companies use to run their applications across many computers. Normal autoscaling tools only watch numbers like CPU or memory usage and react to them. HelmsMan tries to go further by having AI agents look at the actual state of the cluster and decide what changes, like reducing the number of running copies of an app, are safe to make. The project uses two AI agents that work together. One, called the FinOps Agent, looks for ways to save money, such as spotting deployments that are running more copies than they need. The other, called the Availability Guardian, checks whether a proposed change would put the application at risk, for example by looking at rules called PodDisruptionBudgets that protect a minimum number of running copies. Neither agent is allowed to act alone. Every suggestion from these agents passes through what the README calls a Safety Engine. This part of the system checks the real Kubernetes cluster directly, confirming things like current replica counts and cluster health, before anything is actually changed. If a proposed action would break a safety rule, it gets rejected before it ever reaches the cluster. The idea is that the AI reasoning suggests changes, but a separate, predictable set of checks decides what is actually allowed to happen. The project is built using the Model Context Protocol, or MCP, through something called the NitroStack MCP SDK, and it is written in TypeScript. It connects to real Kubernetes resources, including Deployments, Pods, Nodes, Services, and PodDisruptionBudgets, and it includes a dashboard for watching cluster health, agent decisions, and a record of which actions were approved or rejected. This is aimed at people who manage Kubernetes infrastructure and want to explore AI-assisted, safety-checked automation rather than fully manual or purely metric-based autoscaling.
An AI-assisted Kubernetes tool where agents suggest cost-saving or safety changes, but a separate safety engine checks the real cluster before anything is applied.
Mainly TypeScript. The stack also includes TypeScript, Kubernetes, Node.js.
Setup difficulty is rated hard, with roughly 1h+ to a first successful run.
Mainly ops devops.
This repo across BitVibe Labs
Verify against the repo before relying on details.