ccteam: a Rust daemon that turns your separate coding CLIs into one dispatchable team

The isolation problem ccteam is built around

The README states the premise directly: each coding CLI is strong alone but works in isolation, one terminal, one context, no colleagues. It then assigns each vendor a temperament. Claude Code plans the deepest, Codex grinds long jobs, Grok answers fastest, Kimi does bulk work cheaply, DSH hires inside your own DeepSeek Harness web space, and Pi is one CLI over many providers on your own machine. Those are the project's own characterisations, not measured results, and you should treat them as editorial rather than benchmarked.

The audience follows from that framing. If you run exactly one agent CLI, ccteam adds a daemon, a token, a port and a Telegram bot to a workflow that already works. The product only pays for itself when you have at least two vendors in play and want one session to hand work to another. The stated gap is the connective tissue: identity, routing, delivery guarantees, guardrails, a cost ledger. The README is explicit that ccteam leaves how the team organises itself to prompts you version, which tells you where the project draws its own boundary.

What actually sits between the sessions

The mechanism visible in the material is a daemon that holds sessions as first-class objects and exposes them to each other. Sessions are registered, addressable (the Telegram example uses @s2 to address one directly), and carry a working or idle signal so a parent does not have to infer state from silence. That signal is the piece that makes delegation tractable: without it, a spawning session either polls or guesses.

Inside a Claude session, the README says the tools agent and agent_read run under the hood when you ask for delegation in plain language. The example prompts are ordinary sentences, so the routing decision is made by the model reading your request, not by a schema you fill in. The Team page renders the result as a delegation topology: vendor, the model and reasoning effort each session is actually running, cost, and a parent to child edge for every delegation. That edge is the architectural claim worth noting. A delegation is traceable, not fire and forget.

Cross-machine behaviour is described as follows: you register a satellite with a join token from Settings → Access, the satellite dials out to your daemon so a laptop behind NAT works, and projects are bound to a host. Spawn into a project bound to a GPU box and the tests run there while transcripts, cost and the team view stay in one console. The README then states the constraint plainly: satellite execution currently runs Claude sessions, and the other vendors run on the daemon's machine. That single sentence limits how distributed the setup really is today.

Getting a daemon, a console and a bot token in place

The README's installation path is short. The installer runs the daemon, and ccteam status reprints your link in the form http://<lan-ip>:7331/?token=…, which you open from any device on the same LAN. The web surface is described as a chat shell rather than a dashboard, and the launcher works as a single pill where you pick project, host, role, vendor and model, then type. There is no create session form; the session is born on your first message. Six formation playbooks (commander and crews, driver and advisor, cross review, bake-off, research triangulation, cost pyramid) prefill that pill with a vendor lineup.

Telegram and Lark use the same daemon. You paste a bot token once under Settings → Access, after which the chat becomes a console. The documented commands are /cd to pick a project, /new with optional vendor, role, model and effort arguments, @sN to address a session, /status, /sessions and /stop, and /inbox for a one-shot scheduled user turn with /inbox cancel dN to remove one. Completion notifications, human-in-the-loop approve and deny buttons, and shipped files land in the same thread. The README's own scenario is dispatching at midnight, closing the laptop, and reading the result at breakfast, which is a fair description of what the notification path is for.

Everything the console does is also exposed as /api/v1, with OpenAPI at /api/docs. If you would rather not use the bundled UI, that is the surface to build against.

Flows: orchestration as a script instead of a sentence

When the shape of the work is already known, ccteam offers a second path. A flow is a plain JavaScript script the ccteam runner executes, built from agent(), parallel(), pipeline() and phase() over cross-harness hires, with every leaf its own session on the ledger. The documented commands are ccteam flow new branch-review to scaffold a script plus the API it can call, ccteam flow run branch-review.flow.js --args '{"base":"main"}' --budget 5 to execute it under a budget, and ccteam flow eval <run-id> to grade a finished run with a flow of your own.

Two details matter more than the API shape. First, the budget flag is enforced at the run level, which is a different control from the daily budget caps on the cost pill. Second, the README says runs are journaled so a run survives a daemon restart, though the supplied text cuts off mid-sentence at that point. I cannot confirm from this material what the journal covers, how resume is triggered, or whether a partially completed leaf is replayed or skipped. If you intend to run long flows unattended, that is the first thing to read in the repository rather than assume.

The division of labour between the two paths is clear enough. Use plain language when the work is exploratory and you want the model to decide who does what. Use a flow when you already know the graph and want it versioned next to the code.

The routing charter and what versioning prompts really costs

The Team page includes a per-project routing.md, described as a division-of-labor charter that agents read via status and that you edit in place. This is the project's answer to the question of who decides the team structure: not ccteam, and not a fixed algorithm, but a file you maintain per project. The README frames it as leaving how the team organises itself to prompts you version.

That is a real design position and it has a real cost. A charter that tells a planner which vendor to prefer for profiling versus bulk renames is a document that drifts as models change, as your vendor mix changes, and as your own conventions move. Nothing in the material suggests ccteam validates routing.md against anything, so a stale charter will be followed confidently. The same applies to the formation playbooks: they prefill a lineup, and a prefill is a starting point, not a guarantee about what the sessions then do.

The honest reading is that ccteam supplies plumbing and observability, and you supply the judgement. Teams that want the orchestration policy to be a tested, supported artefact rather than a markdown file will find that gap uncomfortable. Teams that already keep prompts in version control will find it familiar.

Where ccteam is the wrong tool

The satellite constraint is the sharpest limitation in the material. Only Claude sessions run on satellites today; Codex, Grok, Kimi, DSH and Pi run on the daemon's machine. If your reason for wanting a distributed setup is to spread non-Claude work across hosts, ccteam does not do that yet, and the README says so without hedging.

Platform support is macOS, Linux and WSL. Native Windows is not listed. The web console is reached over your LAN at port 7331 with a token in the query string, which is convenient and also means the link is a credential; the README does not describe TLS or a reverse proxy in the supplied text, so how you expose that beyond a trusted network is your problem to solve.

There is also a category of user for whom this is simply the wrong shape. If you want one agent, one repository and one terminal, the daemon, the bot token and the routing charter are overhead. If you need hard isolation between vendors, for example because different clients' code must never share a process or a home directory, the material does not describe a sandbox boundary per vendor. The DSH page does say each logged-in user gets a separate DSH home, which is user separation rather than vendor separation. And if you need a stable public API contract, note that the project shipped v0.10.3, v0.10.5 and v0.11.0 within roughly a month, so pin your version and read the release notes before upgrading.

How this differs from a single-vendor agent framework

The obvious comparison is a single-vendor agent framework, the kind that ships with one model provider and treats other models as plugins. The difference is in what ccteam assumes about the leaves. In a single-vendor framework, sub-agents are usually the same model with a different prompt and a fresh context window, and the framework owns the loop. In ccteam, a leaf is a separate coding CLI with its own harness, its own authentication, and its own idea of what a session is. The README's example of spawning a codex session to implement RFC-12 while grok profiles the hot path and kimi sweeps a rename only makes sense if those are genuinely different tools with different billing.

The cost ledger and the delegation topology follow from that assumption. If everything ran on one provider, a single usage number would do. Because the team is heterogeneous, ccteam tracks cost per session and per delegation edge, and offers a daily cap plus a per-run budget flag. The trade-off is that ccteam cannot reason about a leaf's internals. It can tell you a session is working or idle and what it cost, and it can route a message to it, but the quality of what comes back is whatever that vendor's CLI produces. A framework that owns the loop can constrain the loop. ccteam deliberately does not.

Maintenance surface and licence

ccteam is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is not legal advice; read LICENSE in the repository and get your own counsel if the distinction matters to you. The practical implication of MIT here is that you can vendor the daemon into an internal toolchain or fork it without a copyleft obligation on your own code.

The maintenance surface is worth counting before you commit. You are running a daemon, a LAN web endpoint on port 7331, a bot token stored in Settings → Access, a join token per satellite, a per-project routing.md per project, and possibly a set of flow scripts. Each of those is something that can go stale or be misconfigured independently. The upgrade cadence is the other half: three releases between late August and early September 2026 in the supplied list, with a minor version bump at v0.11.0. Nothing in the material describes a compatibility guarantee for the flow API or for /api/v1, so treat both as moving until you read the release notes for the version you deploy.

On the positive side, the project ships a CI workflow, targets macOS, Linux and WSL explicitly, and exposes the same operations through the console and the HTTP API, which means a broken UI is not a hard stop. The Runs tab, which lists every ccteam Flow run alongside the sessions it hired, is the surface to check when a scheduled job produces something you did not expect.

Editorial conclusion

Adopt ccteam if you already pay for two or more coding CLIs and want one place to dispatch, watch and budget their work, and if you can accept that satellite execution currently runs Claude sessions only while the other vendors stay on the daemon's machine. Do not adopt it if you need a per-vendor sandbox boundary, run on Windows outside WSL, or want the orchestration logic itself to be a supported product surface rather than prompts you version in routing.md. Verify first that the agent/agent_read tool names and the /api/v1 surface match what your own sessions expose, that the daemon's LAN link and Settings → Access token handling fit your threat model, and that a Flow run survives the daemon restart you are actually going to have.

Official sources

1. firstintent/ccteam on GitHub
2. Issues
3. License: MIT
4. README
5. Releases