ChesterRa / cccc

CCCC Local-first Multi-agent Collaboration Kernel **A lightweight multi-agent framework with infrastructure-grade reliability.** Chat-native, prompt-driven, and bi-directional by design. Run multiple coding agents as a **durable, coordinated system** — not a pile of disconnected terminal sessions. Three commands to go. Zero infrastructure, production-grade power. **English** | 中文 | 日本語 --- Why CCCC • **Durable coordination**: working state lives in an append-only ledger, not in terminal scrollback. • **Visible delivery semantics**: messages have routing, read, ack, and reply-required tracking instead of best-effort prompting. • **One control plane**: Web UI, CLI, MCP, and IM bridges all operate on the same daemon-owned state. • **Multi-runtime by default**: Claude Code, Codex CLI, Gemini CLI, and the rest of the first-class runtimes can collaborate in one group. • **Local-first operations**: one , runtime state in , and remote supervision only when you choose to expose it. The Problem Using multiple coding agents today usually means: • **Lost context** — coordination lives in terminal scrollback and disappears on restart • **No delivery guarantees** — did the agent actually *read* your message? • **Fragmented ops** — start/stop/recover/escalate across separate tools • **No remote access** — checking on a long-running group from your phone is not an option These aren't minor inconveniences. They're the reason most multi-agent setups stay fragile demos instead of reliable workflows. What CCCC Does CCCC is a single with zero external dependencies — no database, no message broker, no Docker required. Yet it gives you the pieces fragile multi-agent setups usually lack: | Capability | How | |---|---| | **Single source of truth** | Append-only ledger ( ) records every message and event — replayable, auditable, never lost | | **Reliable messaging** | Read cursors, attention ACK, and reply-required obligations — you know exactly who saw what | | **Unified control plane** | Web UI, CLI, MCP tools, and IM bridges all talk to one daemon — no state fragmentation | | **Multi-runtime orchestration** | Claude Code, Codex CLI, Gemini CLI, and 5 more first-class runtimes, plus for everything else | | **Role-based coordination** | Foreman + peer model with permission boundaries and recipient routing ( , , ) | | **Local-first runtime state** | Runtime data stays in , not your repo, while Web Access and IM bridges cover remote operations | How CCCC looks Quick Start Install > **Requirements**: Python 3.9+, macOS / Linux / Windows Launch Open **http://127.0.0.1:8848** — by default, CCCC brings up the daemon and the local Web UI together. Create a multi-agent group You now have two agents collaborating in a persistent group with full message history, delivery tracking, and a web dashboard. The daemon owns delivery and coordination, and runtime state stays in rather than inside your repo. Programmatic Access (SDK) Use the official SDK when you need to integrate CCCC into external applications or services: The SDK does not include a daemon. It connects to a running core instance. Architecture **Key design decisions:** • **Daemon is the single writer** — all state changes go through one process, eliminating race conditions • **Ledger is append-only** — events are never mutated, making history reliable and debuggable • **Ports are thin** — Web, CLI, MCP, and IM bridges are stateless frontends; the daemon owns all truth • **Runtime home is ** (default ) — runtime state stays out of your repo Supported Runtimes CCCC orchestrates agents across 8 first-class runtimes, with available for everything else. Each actor in a group can use a different runtime. | Runtime | Auto MCP Setup | Command | |---------|:--------------:|---------| | Claude Code | ✅ | | | Codex CLI | ✅ | | | Gemini CLI | ✅ | | | Droid | ✅ | | | Amp | ✅ | | | Auggie | ✅ | | | Kimi CLI | ✅ | | | Neovate | ✅ | | | Custom | — | Any command | Messaging & Coordination CCCC implements IM-grade messaging semantics, not just "paste text into a terminal": • **Recipient routing** — , , , or specific actor IDs • **Read cursors** — each agent explicitly marks messages as read via MCP • **Reply & quote** — structured with quoted context • **Attention ACK** — priority messages require explicit acknowledgment • **Reply-required obligations** — tracked until the recipient responds • **Auto-wake** — disabled agents are automatically started when they receive a message Messages are delivered to actor runtimes through the daemon-managed delivery pipeline, and the daemon tracks delivery state for every message. Automation & Policies A built-in rules engine handles operational concerns so you don't have to babysit: | Policy | What it does | |--------|-------------| | **Nudge** | Reminds agents about unread messages after a configurable timeout | | **Reply-required follow-up** | Escalates when required replies are overdue | | **Actor idle detection** | Notifies foreman when an agent goes silent | | **Keepalive** | Periodic check-in reminders for the foreman | | **Silence detection** | Alerts when an entire group goes quiet | Beyond built-in policies, you can create custom automation rules: • **Interval triggers** — "every N minutes, send a standup reminder" • **Cron schedules** — "every weekday at 9am, post a status check" • **One-time triggers** — "at 5pm today, pause the group" • **Operational actions** — set group state or control actor lifecycles (admin-only, one-time only) Web UI The built-in Web UI at provides: • **Chat view** with autocomplete and reply threading • **Per-actor embedded terminals** (xterm.js) — see exactly what each agent is doing • **Group & actor management** — create, configure, start, stop, restart • **Automation rule editor** — configure triggers, schedules, and actions visually • **Context panel** — shared vision, sketch, milestones, and tasks • **IM bridge configuration** — connect to Telegram/Slack/Discord/…