ccmanager

You will feel the benefit within an hour if you already juggle parallel sessions. The status indicator beside each session is the trait that decides it, because the expensive part of running several agents is not starting them, it is noticing that one has been sitting idle waiting for your answer for twenty minutes. Switching between them never leaves the terminal, and several projects sit in one interface.

Pick it if you live in a shell and want a dispatcher rather than another agent. Pick Conductor when you want the same idea with a real window, or Claude Squad if you want it smaller still.

The risk is the interface, not the code. Worktrees are created, merged and deleted from inside the app, so destructive git operations become shortcuts in a screen where you are also switching contexts under time pressure. Nothing on the row describes a confirmation step or a recovery path. The failure is not a crash. It is a merge you did not mean to run and a branch you had not finished reading.

What it does right: documented devcontainer integration runs a session inside a container, so the agent's blast radius is a decision rather than a default.

Two points worth recording. 1. Editing is performed entirely by the managed command-line agents, so this layer neither gathers context nor applies changes; its verification surface is whether a session is in the state the display says it is in. 2. Status-change hooks expose that transition to external scripts, which is the correct primitive: it lets an operator instrument the thing rather than watch it.

Documentation is a single repository page and no evaluation is offered, which is proportionate for a program with this narrow a remit. The scope discipline is the notable design choice.

This is a personal project published under a permissive licence by a named individual with no vendor behind him. There is no pricing page to have power over, no hosted tier, and no structure that could take money if someone offered it. Roughly twelve hundred stars is distribution of a sort, and distribution without a business model is a resume line.

The realistic outcomes are steady hobby maintenance or a quiet archive when the maintainer's own workflow changes. No acquirer wants this; they would rebuild it in a week. Position: adopt without hesitation and without dependency, because the cost of it stopping is one afternoon.

Sixty seats cost nothing, which is where my interest usually starts and here also where it ends. There is no headless mode, so this cannot run in a pipeline and produces no artefact my release process could consume. Supported platforms are macOS and Linux, and a third of my engineers are on Windows laptops, so a standard rollout is off the table before security is even involved. No SSO, no audit log, nothing to attach to our directory.

Onboarding is twenty minutes for whoever wants it. Approved with conditions: individual installs only, and it stays off the standard image.

MIT with the licence file right there, and I can run it through npx without putting anything permanent on the machine. The part I like is the preset model: the agents it supports are not compiled in, they are commands I configure, so pointing it at a binary the author has never heard of takes a config entry rather than a pull request. My provider credentials stay with whichever agent CLI I launch.

It is small enough that I could read the whole thing on a train, which is the only real test of whether a fork would survive its author.