How is this different from k8sgpt and HolmesGPT — and where are they better?

[MSKazemi]

We already run k8sgpt and have looked at HolmesGPT. What does KubeIntellect do that they don't, and — more usefully — what do they do better? I'd rather not migrate twice.

[MSKazemi]

The honest one-line version: k8sgpt and HolmesGPT diagnose; KubeIntellect diagnoses and can act, with the acting deliberately made hard. If you never want the tool to touch the cluster, that difference is a cost to you, not a benefit — which is a real reason to stay where you are.

There is a longer, maintained comparison in the wiki: KubeIntellect vs Alternatives, including a section on where this project is weaker. The summary:

What is genuinely different

• It can execute, behind a hard gate. Scale, restart, patch, delete — each pauses at a server-side chokepoint for explicit human approval, with RBAC underneath and a dry-run diff to approve against. Read-only tools cannot close the loop from "here is the cause" to "here is the fix, applied"; this can, and it makes that the slow path on purpose. See #81.
• Evidence correlation across three sources in one answer — kubectl state, Prometheus (PromQL) and Loki (LogQL), fanned out to subagents and reconciled. The differentiator is the correlation, not the individual queries.
• Zero-token detection. A detector engine over a kubectl --watch sensorium fires findings without invoking an LLM, so continuous monitoring is not continuously billed. The model is spent on investigation, not on watching.
• A hash-chained flight recorder. kq replay <session-id> reconstructs what happened and exits non-zero if the chain is broken. When you have to explain an incident to someone else, that is the artifact you want.
• Peer-reviewed architecture — Journal of Grid Computing, 2026. The design and evaluation were reviewed; that is not the same as operational maturity.

Where they are genuinely better

I would rather you weigh this properly than migrate and regret it:

• Maturity and community. k8sgpt is a CNCF Sandbox project with a real contributor base and governance behind it. KubeIntellect has one maintainer and five contributors total. That is the most important line here.
• Install channels. k8sgpt ships Homebrew, Krew and distro packages. This is pip + container + Kind. Our Homebrew formula is broken and unmaintained.
• Licence. k8sgpt is Apache-2.0; KubeIntellect is AGPL-3.0-or-later (with a commercial option). For some organisations AGPL is disqualifying on its own, and that is a legitimate reason to choose otherwise.
• Operator/in-cluster ergonomics. k8sgpt's operator pattern is more established for continuous in-cluster analysis.

How I would actually decide

• You want a read-only second opinion, integrated with a CNCF-shaped stack → stay with k8sgpt. Genuinely.
• AGPL is a problem for you → stay with k8sgpt, or talk to us about the commercial licence.
• You want the diagnosis and the fix in one governed loop, with an auditable record of who approved what → that is the case this project is built for, and no read-only tool will get there.
• They are not mutually exclusive. Nothing stops you running k8sgpt for continuous scanning and KubeIntellect for interactive incident work. Several of the design decisions here assume you already have an observability stack — it queries the tools you run rather than replacing them.

If you evaluate and stay with k8sgpt, saying why on #52 is more valuable to us than a star. "We'd switch if X" is the most actionable thing a roadmap can receive.