Blog
Notes from the engine room.
Eleven engineering posts on how Loom Conductor plans, dispatches, watches, and verifies a fleet of six Claude Code sessions. The decisions, the tradeoffs, and the code that came out the other side.
All posts
Eleven posts, one fleet.
is six
Machine load, reviewability, and how much one Conductor can steer
a mission
The full path from a one-line brief to verified work in git
never sleeps
Detecting stalls and exits, relaunching CLIs, re-sending tasks
safely
How auto-accept answers permission prompts without pressing the wrong one
verified
Why a session claiming done is the start of done, not the end
megabyte app
What Tauri 2 and Rust buy you over shipping a whole browser
one GPU budget
Rendering six live native PTYs with xterm.js and WebGL
Conductor
Picking a reasoning model across 12+ providers, or running local
rate limits
Pooled Claude accounts, parked on usage limits, rotated in round-robin
before build
Why the Design tab settles a theme and a page plan before any code
architecture
Keychain-only keys, secret-path deny-lists, and a proxy that distrusts URLs
How these posts are written
Every post here is grounded in shipped code. Loom Conductor is free and open source under Apache-2.0, so when a post describes the watchdog, the mission DAG, or the auto-accept logic, you can read the implementation in the repository and check our work. Nothing here describes a feature that does not exist in the app.
The posts span the whole surface of the app: how the fleet of six is sized and steered, how missions become DAGs and get verified, why the installer is around 13 MB, and how privacy and key handling are built into the architecture rather than bolted on.
If you want news rather than engineering, the updates page covers releases and announcements, the changelog lists changes version by version, and the documentation explains how to use everything these posts explain how we built.
Hand it the work.
Walk away.
macOS, Linux, and Windows. Around 13 MB. Free and open source.