cccc vs openrig
Group-chat orchestration for coding agents: Claude Code, Codex, ChatGPT Web and others in one durable group with an append-only ledger, read receipts, and Web/IM/mobile ops. — versus — Define a team of Claude Code, Codex and Pi agents in YAML and boot it with one command: persistent tmux-backed seats with roles, shared context and owned work, steered via a lead agent.
Both coordinate Claude Code and Codex as one durable group; cccc via a group-chat ledger, OpenRig via a lead agent over role seats.
| cccc | openrig | |
|---|---|---|
| Stars | 1.3k | 8.7k |
| Forks | 111 | 722 |
| Language | Rust | TypeScript |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | yesterday | yesterday |
| Topics | orchestration, coding | orchestration, coding, agents |
| Curated connections | 8 | 6 |
cccc — the curator's take
Reach for CCCC when the problem is *coordination* between several long-running agents - who owns a task, whether a message was actually delivered/read, what survives a daemon restart - and you want to supervise from a phone via Telegram/Mattermost. The ledger + delivery/read/reply facts are the real differentiator; most multiplexers just tile terminals. Not for a single agent in one repo (herdr or plain tmux is lighter), and not a workflow engine: it doesn't compile plans or DAGs, it routes messages between a foreman and peers. Rust binary, pip-installable, no broker/DB/Docker - but it is a daemon that owns state, so expect one more always-on process.
openrig — the curator's take
Use it when you already live in Claude Code/Codex and want a standing team — lead agent, specialists, stable addresses — rather than one-off sessions. Skip it if you want a hosted platform or Windows-native setup (tmux, macOS/Linux/WSL2 only), and read the permissions section first: the kernel operator runs with broad, prompt-free access by default.