Use cases
One package per session.
A monorepo already comes pre-split. Point the fleet at it, let the Conductor assign one package to each session, and keep your own attention on the seams where they meet.
Why it fits
Package boundaries are natural task boundaries.
Clean split lines
The Conductor plans your goal into tasks, and in a monorepo the obvious unit is the package. Six real Claude Code sessions each take their own corner of the tree instead of queueing behind one terminal.
Seams in order
Goals become a DAG of tasks, so work on a shared package can come before the packages that consume it rather than racing it. Live activity strips show what every session is doing at the seam.
One workspace, six sessions
Authorize the repo once in the workspace registry and the file explorer, the git panel, and all six sessions switch to it together. No per-terminal cd choreography.
The shape of a mission
Brief once, fan out across the tree.
Describe the change at the repo level and let the Conductor dispatch it lane by lane. It watches every terminal, answers permission prompts, and re-checks each task before it counts as done. The same pattern carries large refactors that cut across packages.
# a goal split along package boundaries
packages/shared session 1, lands first
packages/api session 2
packages/web session 3
packages/cli session 4
packages/docs session 5
packages/e2e session 6, runs lastAfter the fan-out
Review at the root.
One git graph
The source control panel shows the full git graph for the whole repo, so you read what six sessions shipped as one history, not six guesses.
Jump in anywhere
Each session is a real Claude Code TUI in a real terminal. If the api lane needs a human decision, click in and type. The rest keep working.
Verified before done
Loom re-checks work before it counts and catches sessions that declare victory early, which matters most when six lanes finish at different times.
Hand it the work.
Walk away.
macOS, Linux, and Windows. Around 13 MB. Free and open source.