Loom v0.7.4 is out for macOS, Linux and Windows

Blog

Six is a budget, not a flex.

Loom Conductor runs exactly six Claude Code sessions in parallel. That number was not picked for the marketing page. It is where three real constraints happen to agree.

Three constraints, one number

When you parallelize coding agents, the temptation is to treat the count like a dial that only goes up. Twelve sessions must beat six, and twenty must beat twelve. In practice the fleet size is bounded by three things that have nothing to do with ambition: what your machine can comfortably run, what you can actually review, and how much one Conductor can meaningfully steer. Six is where those lines cross.

The machine has opinions

Each fleet slot is a real Claude Code CLI session in a real native PTY, not a thumbnail of one. Loom renders all of them through WebGL terminals, keeps a CodeMirror 6 editor, a git graph, and an auto-detected web preview alive in the same window, and still ships as a roughly 13 MB Tauri 2 app. The app itself stays light, but the sessions do not. Six agents compiling, running tests, and starting dev servers is a workload a normal development machine handles gracefully. Push past that and the sessions start competing with each other for the same cores and disk, which slows every task to protect none of them.

You still have to review it

Parallel agents do not remove the review step, they multiply its input. Everything the fleet produces lands in git, where Loom's source control panel shows the full graph and the editor lets you walk AI diffs hunk by hunk. Six streams of changes is a volume one person can genuinely read by the end of a session. More streams do not produce more reviewed work. They produce a backlog of unreviewed work, which is the most expensive kind, because you either merge it on faith or re-derive the understanding the agent already had.

One Conductor can only steer so much

The Conductor plans your goal into a DAG of tasks, dispatches them, watches every terminal, answers permission prompts, recovers stalls and rate limits, and verifies work before it counts as done. Each of those jobs scales with the number of sessions. At six, the Conductor can keep a real model of what every slot is doing, and the live activity strips stay readable at a glance for you too. Far beyond that, supervision degrades into sampling. A Conductor that only spot-checks its fleet is not conducting, it is hoping.

More is noise, fewer wastes the login

The other direction matters just as much. The fleet runs on your existing Claude login, no API key required, so a single session leaves most of what you are already paying for sitting idle. One agent working serially is what you had before Loom. Two or three is better, but the whole point of planning work as a DAG is that independent tasks ship simultaneously, and most real missions fan out wider than three.

So six is not a magic number, it is an engineering budget: the most parallelism we can spend before the machine, the reviewer, or the Conductor becomes the bottleneck. To see how a mission actually flows through those six slots, read Anatomy of a mission. To get more out of each slot, start with fleet tips.

The three limits

Where the lines cross.

The machine

Six native PTYs doing real builds and tests is what a normal dev machine runs without the sessions throttling each other.

The reviewer

Six streams of git diffs is a volume one person can read hunk by hunk. Unreviewed parallel work is just deferred work.

The Conductor

Watching, steering, answering prompts, and verifying scale with fleet size. Six keeps supervision real instead of sampled.

Hand it the work.
Walk away.

macOS, Linux, and Windows. Around 13 MB. Free and open source.