ccteam

Each coding CLI is brilliant alone but works in isolation — one terminal, one context, no colleagues:

• Claude Code — plans the deepest
• Codex — grinds long jobs without wobbling
• Grok — answers fastest
• Kimi — bulk work on a tiny bill
• DSH — hires live inside your own DeepSeek Harness web space, side by side with you
• Pi — one CLI over many providers (anthropic/…, openai/…), on your own machine

ccteam is the connective tissue they lack — identity, routing, delivery guarantees, guardrails, a cost ledger — and leaves how the team organizes itself to prompts you version.

Usage

1 · Remote control from Telegram / Lark

Paste a bot token once (Settings → Access) and the chat becomes a full console — completion notifications, HITL [approve] [deny] buttons, and shipped files all land in the same thread. Dispatch at midnight, close the laptop, find the result at breakfast:

/cd demo                        # pick a project; your next message talks to it
/new codex effort=high          # more sessions: /new [vendor] [role] [model=…] [effort=…]
@s2 run the test suite          # address any session directly
/status  /sessions  /stop s3    # health · fleet · cost · stop
/inbox +30m remind me …         # schedule a one-shot user turn; /inbox lists · cancel dN

2 · Remote control from the web console

The installer runs the daemon; ccteam status reprints your link (http://<lan-ip>:7331/?token=…) — open it from any device on your LAN. It's a chat shell, not a dashboard:

• six formation playbooks (commander & crews, driver & advisor, cross review, bake-off, research triangulation, cost pyramid) that prefill the launcher with a vendor lineup
• a Chat tab per session (plus a byte-faithful terminal where applicable), including a clock on the composer to queue delayed user turns above the input
• a Team page: the live delegation topology — vendor, the model and reasoning effort each session is actually running, cost, every row a real link so a parent and its delegate open side by side — plus a division-of-labor charter (the per-project routing.md agents read via status) edited in place
• a DSH page that opens DeepSeek Harness Web inside ccteam: the daemon authenticates the request, starts or attaches the right local DSH web instance, and gives each logged-in user a separate DSH home
• a cost pill with daily budget caps
• a per-project ⋯ menu in the sidebar: start a session there, copy its path, or take the project out of ccteam (deregister + stop its live sessions — your directory and code are never touched)
• marketplace and settings

Everything the console does is also /api/v1 (OpenAPI at /api/docs).

3 · Orchestrate a team from inside a claude session

Any registered session can hire the others — say it in plain language and session_spawn / dispatch / collect run under the hood (with an honest working / idle signal, so nobody guesses from silence):

Spawn a codex session, have it implement RFC-12 and run the tests; report back when green.

Plan this refactor, then delegate: codex implements, grok profiles the hot path in
parallel, kimi sweeps the rename across the repo. Collect everything into one summary.

Spawn a claude reviewer on s2's diff — I'm not merging until it signs off.

4 · Many machines, one console

Register a satellite with a join token (Settings → Access) — it dials out to your daemon, so a laptop behind NAT works fine. Projects are bound to a host and run where they live: spawn into the GPU-box project and its tests run on the GPU box, while transcripts, cost, and the team view stay in one console. Switching machines is just switching projects.

Satellite execution currently runs Claude sessions; the other vendors run on the daemon's machine.

Under all four modes are the same eight MCP tools, available to every session, to your plain hand-started CLIs once registered, and to any external agent that presents an enrollment credential over POST /mcp — one credential per vendor config or per copy-button, and the daemon issues each process its own identity when it connects, so two agents sharing a config are still two callers with their own ledger rows and their own children:

session_spawn · session_dispatch · session_collect · session_list · session_stop
status (+ its discovery alias grok_claude_codex_kimi) · chat_send_file

The daemon routes and records — at-least-once notifications across restarts, idempotency keys, a child's turn written to disk before its parent is told, guardrails that refuse runaway fan-out with a reason. When a web-driven session finishes autonomous work while nobody is watching the console, the final answer is mirrored to your IM; the IM /status card shows your session's working children at a glance. It never schedules; when to delegate lives in prompts you version.

• Plain-language walkthrough → orchestration guide
• Every command → manual (English · 中文)

Inside DeepSeek Harness

ccteam also lives natively inside DeepSeek Harness's own web UI, as one DSH client plugin — @ccteam/ccteam-ui, not a port of the console above, built with DSH's own slots, primitives and locale. Installing it once gives you three faces and an engine supervisor:

Install it with dsh plugin --profile web add @ccteam/ccteam-ui and restart dsh web: the plugin brings the engine, starts the daemon, and picks up your console token from ~/.ccteam on the same machine — nothing to paste. If your DSH is already running through ccteam (/new dsh, the ccteam DSH page, or session_spawn with vendor:"dsh"), the plugin and its credentials are materialized for you. Either way it is one daemon shared with the CLI and ccteam web: the plugin attaches to a running one, never starts a second one against another ~/.ccteam, and never stops it when DSH restarts. The full setup (both install paths, coexistence rules, troubleshooting) is in the DSH plugin guide (中文).

Install

Runs on macOS, Linux, and Windows (via WSL).

[!IMPORTANT] Bring your own coding CLI — install and authenticate at least one before you start. ccteam is the bridge, not the agent: it spawns the vendor CLIs already on the machine a project is boun