Compare · Ciroos
CHA vs. Ciroos
Ciroos has a strong multi-agent + KG architecture but is closed-source SaaS-only. Their 'Autopilot' slider doesn't document a safety brake. Our safety envelope is in code you can read before you install.
| Dimension | CHA | Ciroos |
|---|---|---|
| Where it runs | In your cluster — operator + CronJob + Deployment | Ciroos SaaS, "zero-copy" queries to customer observability |
| Safety brake on autonomy | Named whitelisted fixers + dry-run + signed-JWT approval URLs | "Automate / Augment / Autopilot" slider; no documented brake |
| Open source | Apache-2.0 — full OSS feature set | Proprietary, private GitHub Enterprise |
| Pricing transparency | Published list prices for OSS / Team / Enterprise | Contact sales only |
| Named customer logos | None public yet (honest; neither does Ciroos at 12mo) | None — only "design partner" / "energy customer" references |
Autonomy you can audit.
Ciroos's "Automate / Augment / Autopilot" slider is good marketing. But what does the slider do? Their docs don't say. For an SRE evaluating whether to give a tool write access to production, that's the wrong answer.
CHA's safety envelope is named, scoped, and Apache-2.0. Whitelisted fixers have explicit GVR scopes. Protected namespaces are allowlisted out. Dry-run mode logs every fix without applying. AI-tier proposals require a signed-JWT click. Audit it before you install.