Agent Deck

You will want this the first time you try to run two agents on one repository and they trip over each other. The deciding trait is a git worktree per session: each agent gets its own checkout, so parallel work stops being a stunt and becomes ordinary. Switching between Claude Code and Codex is a keystroke, not a new window.

It is wrong for you if you only ever run one agent at a time, because then it is a terminal with extra steps. Pick it if you keep four things in flight. Pick a plain tmux config if you keep one.

The failure mode is convergence. Six agents in six worktrees produce six branches, and the manager stops at the point where they have to become one commit history. Nothing in the row describes conflict handling, ordering, or a merge queue. The work that parallelism creates lands on you, serially, after the fast part is over.

What it does right is refuse to invent a protocol. It drives the vendor CLIs as they ship, so a session behaves the way that agent behaves elsewhere and there is no translation layer to blame.

1. Isolation is achieved structurally rather than by policy. A separate working tree per session means two agents cannot observe each other's uncommitted state, which removes an entire class of interference without a lock. 2. A sandbox option and a browser view sit beside the session, so the observation surface and the execution surface are the same window.

2. No evaluation is published and none is required, since the claim is organisational rather than capability-bearing. Written in Go and shipped as a prebuilt binary, the tool keeps no runtime of its own between the user and the agent.

839 stars, one GitHub handle, no company and nothing to charge for. That is not a failure of ambition, it is a category observation: session managers are the connective tissue between products other people fund, and connective tissue rarely gets its own cap table.

Pricing power: none, because the price is zero and the substitutes are numerous. Likely path: one of the vendors whose CLI it wraps ships the same feature, and the project becomes a preference rather than a tool. Position: adopt freely, and do not let it become the interface your team names in a runbook.

Nothing per seat, so the cost is the model spend behind sixty developers running several agents in parallel instead of one, which is the line item nobody forecasts. There is no SSO, no audit log and no central policy, because there is no server: sixty laptops, sixty configurations.

It does not run in a pipeline, so it never appears in CI and never becomes a metric. Releases cover macOS and Linux, with Windows through WSL, which my Windows contingent will notice. Approved with conditions: an agreed spend ceiling per developer before anyone runs four sessions at once.

MIT, so the fork is mine if the maintainer moves on. MCP is supported at the manager level, which means the servers I already run are available to whichever CLI I dropped into the pane rather than being configured five separate times. That is the right place to put it.

Model choice is not this layer's to give. It inherits whatever the CLI underneath already authenticates with, which suits me, because those logins are mine. What I cannot do is point it at weights on my own box, since the backends it drives are all vendor CLIs.