CCCC

Coordinate your coding agents like a group chat

Read receipts, delivery tracking, remote group bridges, and mobile ops — for Claude Code, Codex, ChatGPT Web, and 13 more runtimes in one durable group.

Run multiple coding agents as a persistent, coordinated team across runtimes, machines, and trusted working groups — not a pile of disconnected terminal sessions.

One install command. No Rust toolchain or infrastructure required.

English | 中文 | 日本語

Why CCCC

Using multiple coding agents today usually means lost context in terminal scrollback, no distinction between a stored message, runtime handoff, Inbox consumption, and a reply, start/stop/recover operations scattered across tools, and no way to check on a long-running group from your phone. That's why most multi-agent setups stay fragile demos instead of reliable workflows.

CCCC runs your agents as one durable, coordinated system:

• Durable coordination — working state lives in an append-only ledger, not in terminal scrollback.
• Visible delivery semantics — routing plus separate stored, runtime-delivery, read, and reply facts replace 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, ChatGPT Web, Grok Build, and the rest of the first-class runtimes can collaborate in one group.
• Group Bridge for remote teams — trusted CCCC groups can exchange explicit messages and, when granted, inspect or work with each other's local resources.
• Local-first operations — one install command, runtime state in CCCC_HOME, and remote supervision only when you choose to expose it.

What CCCC Does

CCCC installs with one command and needs no database, message broker, or Docker. Yet it gives you the pieces fragile multi-agent setups usually lack:

Quick Start

Install

# Stable product distribution (recommended; Python 3.11+)
python -m pip install -U cccc-pair

# RC channel (TestPyPI)
python -m pip install -U --pre \
  --index-url https://test.pypi.org/simple/ \
  --extra-index-url https://pypi.org/simple/ \
  cccc-pair

The PyPI package is the stable, recommended CCCC distribution, with Python as its stable default implementation. On Linux x86-64, Intel/Apple Silicon macOS, and Windows x86-64, its platform wheel also includes a private, version-matched experimental Rust implementation for opt-in performance evaluation with cccc rust. Complete feature and integration parity is not promised; Rust is retained only as a bounded evaluation surface for measured native benefits. Use cccc python for reliability-critical workflows. An optional experimental standalone Rust preview is available for Rust-only deployment testing.

Upgrade

cccc update

Use cccc update --check to inspect the detected installation and update source. The recommended pip install updates the complete cccc-pair product from its detected PyPI channel. Experimental standalone installs update through the GitHub Pages installer. Both paths stop the active Web/daemon pair before replacing files.

Launch

cccc

Open http://127.0.0.1:8848 — by default, CCCC brings up the daemon and the local Web UI together.

In the recommended pip distribution, Python is the stable initial default until an implementation choice is saved. Rust is an experimental, explicit opt-in for performance evaluation. A bare cccc follows the persisted choice. Switch persistently, or switch and run a command in one step:

cccc status            # selected, running, and available implementations
cccc rust              # select experimental Rust, then launch CCCC
cccc python            # select stable Python, then launch CCCC
cccc rust doctor        # select experimental Rust, then run doctor

Switching is an explicit lifecycle operation: CCCC validates the target payload, stops the active Web/daemon pair, and never silently falls back to the other implementation. Agent runtime MCP configurations keep pointing at the stable public cccc launcher, so they follow later switches automatically. Use cccc python to return to the stable implementation at any time.

The experimental standalone distribution contains Rust only, so cccc python and implementation switching are intentionally unavailable there.

Create a multi-agent group

cd /path/to/your/repo
cccc attach .                              # bind this directory as a scope
cccc setup                                 # configure all available runtimes (or select one with --runtime)
cccc actor add foreman --runtime claude    # first actor becomes foreman
cccc actor add implementer --runtime codex # add a peer
cccc group start                           # start all actors
cccc send "Please inspect the repo and propose the first safe task." --to foreman
cccc tracked-send "Please take the first concrete task and reply with validation evidence." \
  --to implementer \
  --title "First concrete task" \
  --outcome "The change and validation evidence are reported"

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 CCCC_HOME rather than inside your repo.

What you should see: in the Web UI at http://127.0.0.1:8848, both actors show as running, the foreman's reply arrives in Chat, and the tracked request displays its delivery and read state on the message. If an actor stays stopped, run cccc doctor to check the runtime, and see the FAQ for common first-run fixes.

Programmatic Access (SDK)

Use the official SDK when you need to integrate CCCC into external applications or services:

pip install -U cccc-sdk
npm install cccc-sdk

The SDK does not include a daemon. It connects to a running cccc core instance.

Architecture

graph TB
    subgraph Agents["Agent Runtimes"]
        direction LR
        A1["Claude Code"]
        A2["Codex CLI"]
        A3["ChatGPT Web<br/>GPT-5.x via MCP"]
        A4["Grok Build"]
        A5["+ 12 more + custom"]
    end

    subgraph Daemon["CCCC Daemon · single writer"]
        direction LR
        Ledger[("Ledger<br/>append-only JSONL")]
        ActorMgr["Actor<br/>Manager"]
        Auto["Automation<br/>Rules · Nudge · Cron"]
        Ledger ~~~ ActorMgr ~~~ Auto
    end

    subgraph Ports["Control Plane"]
        direction LR
        Web["Web UI<br/>:8848"]
        CLI["CLI"]
        MCP["MCP<br/>(stdio)"]
    end

    subgraph IM["IM Bridges"]
        direction LR
        TG["Telegram"]
        SL["Slack"]
        DC["Discord"]
        FS["Feishu"]
        DT["DingTalk"]
        WC["WeCom"]
        WX["Weixin"]
    end

    subgraph Remote["Remote CCCC Groups"]
        direction LR
        RG1["Trusted group"]
        RG2["Another machine/team"]
    end

    A1 <-->|MCP tools<br/>PTY/headless| Daemon
    A2 <-->|MCP tools<br/>PTY/headless| Daemon
    A3 <-->|Browser delivery<br/>Remote MCP| Daemon
    A4 <-->|MCP tools| Daemon
    A5 <-->|MCP tools| Daemon
    Daemon <--> Ports
    Web <--> IM
    Daemon <-->|Group Bridge<br/>messages · read · full| RG1
    Daemon <-->|Group Bridge<br/>messages · read · full| RG2

Key design decisions:

• Daemon is the single writer — all state changes go through one process, eliminating race conditions
• Ledger is append-only — events are