🎼 Open-source MCP · zero dependencies

Attention is the new bottleneck

Ten terminals running Claude Code, no idea which one is stuck or waiting on you. Conductor reads all of them — and lets you reply — from one window.

$ claude mcp add conductor --scope user -- node ~/conductor/mcp.js
🎼 conductor — 4 windows · last 10 min
WORKING NOW
Build SOAG agent trading grid with character art conv-fix · 4s ago
SOAG · Grid
Read: src/characters.js
Refactor the settlement engine managed x402-pact · 11s ago
x402 · Pact
Running tests — 21 passing
WAITING ON YOU
Deploy degenscreener to production? gated survivors · 1m ago
DegenScreener
“Ready to run npm run deploy — confirm?”
Yes, deploy No Review first
OPEN
Tech week NYC schedule planning main · 17h ago
Good Rooms
Done. Here's what I built…
0deps
Zero runtime dependencies. One Node file per surface, Node ≥18.
No build step, no daemon, no database.
1 cmd
Open a fresh window and ask Conductor to sort out all the others.
CLI table · web cockpit · MCP server — same engine.
windows
Watches every Claude Code window — plus trading bots, MEV searchers, validators.
Pluggable adapters on one supervisory core.
The problem

You're outnumbered by your own agents

Agentic coding flipped the ratio. One person now runs five, ten, fifteen autonomous windows at once — and the scarce resource stopped being compute. It's your attention. Which one finished? Which one is wedged on a failing test? Which one is silently waiting on a yes/no before it can ship? You find out by alt-tabbing through all of them, one at a time.

No new infrastructure

Read the trail they already write

Every Claude Code window logs a live .jsonl transcript under ~/.claude/projects/. Conductor streams those files — never loading 8 MB into memory — and pulls each session's own title, latest prompt, recent tool calls, and last action.

  • Filters by modification time, so thousands of historical sessions don't drown the live ones.
  • Excludes subagent threads so each window counts once.
  • Groups by session, reports one row per window — Working now / Waiting / Open / Idle.
~/.claude/projects/<dir>/<session>.jsonl
# discover → liveness → parse → group → status → sort $ conductor # one row per live window, problems first Build SOAG grid conv-fix · 4s Refactor settlement x402 · 11s Deploy to prod? GATED · 1m Tech week planning main · 17h
The safety model

Continuing is automatic. Approving is human.

Watching is always-on and free. Control is opt-in — and the moment it could do something irreversible, Conductor stops and hands the decision back to you. An orchestrator can drive ordinary work end-to-end; it can't quietly ship a deploy or move money.

✓ AUTO-CONTINUE
“Tests pass — shall I update the README and commit?”
reversible → sends “continue”, work keeps moving
⛔ GATED → HUMAN
“Ready to deploy to prod / send the email / spend 0.4 SOL?”
touches deploy·send·delete·spend → refuses, returns reason

The bias is to stop when unsure: a false gate costs one manual reply; a false pass can ship a bad deploy or move real funds. The irreversibility gate lives in policy.js — auditable, no model in the loop.

Three surfaces, one engine

Glance, drive, or wire it into an agent

A source-agnostic supervisory core owns grouping, status ranking, and sectioning. You pick the surface.

📊

The cockpit

Run conductor up for a live web dashboard. Every window a card, color-coded by status, auto-refreshing. Managed windows get one-tap Yes / No / Continue / Review replies.

🔌

The MCP server

Conductor speaks the Model Context Protocol over stdio. Any agent can call list_sessions, whats_left, pending_questions, and the gated control tools to watch and drive your windows.

💬

The skill

Drop in the Claude Code skill and any window can summarize the rest in plain English: “sort out my windows” → a doing-now / done / what's-left report per session.

🎛️

Opt-in control

Launch managed windows through tmux, or adopt an existing one (forked, history intact). Then reply from the CLI or cockpit. Read-only stays read-only.

The abstraction

If it narrates itself to disk, Conductor can watch it

Conductor is supervisory awareness over a fleet of semi-autonomous workers that already emit an append-only trail. Claude Code is one adapter. Swap the adapter, keep the engine — grouping, status, and all three surfaces come free.

Adapter
Reads
Control
claude-code
Your ~/.claude/projects transcripts; liveness from a live claude process
tmux send-keys (managed)
fleet
Trading-bot events.jsonl; derives wedged orders & drawdown, session PnL
pause · resume · flatten
mev-searcher
Searcher event logs; derives feed-dead, losing-every-race, bleeding-after-gas
pause · kill · unwind (gated)
validator-fleet
The chain itself — one batched RPC poll learns delinquency, catchup, skip-rate
observe-only by default

A domain fits when it has all four: many units with intent · a trail that already exists · a liveness signal · supervise-by-exception status. Write one file at adapters/<name>.js and every surface works with --adapter <name>.

Conductor V2 · swarms

Design the formation, then fire it

V1 watches windows you opened by hand. Its sibling Conductor V2 flips the order: pick a formation, set one purpose, press FIRE — and a fleet of Claude Code windows launches into tmux and coordinates through two dumb, reliable channels: a shared swarm directory for artifacts and a per-swarm swarm-say helper for one-line handoffs. The formation decides who talks to whom and who starts.

🏛

Hierarchical

Orchestrator → workers
      ┌─ ORC ─┐
  ┌───┼───┬───┼───┐
  w1  w2  w3  w4

One orchestrator decomposes the mission, delegates a task per worker, collects reports, and synthesizes. Best when the work splits into independent chunks.

Pipeline

Sequential stages
s1 ─▶ s2 ─▶ s3 ─▶ s4
 each stage hands
 off to the next

Stages run in order; each consumes the previous stage's output and hands off. Best for a natural assembly line — recon → audit → verify → report.

🕸

Mesh

Peer-to-peer
  p1 ─── p2
   │ ╲ ╱ │
   │ ╱ ╲ │
  p3 ─── p4

Equal peers self-organize: each claims a distinct angle, works it, and broadcasts findings to the rest. Best for breadth — sweep a space from several directions at once.

Fire it from any agent. The V2 MCP exposes list_formations, plan_swarm (dry-run), fire_swarm, list_swarms, and stop_swarm — plus presets for deep research, market-bot sweeps, and web3 security reviews.
Conductor V2 →
# register the V2 swarm MCP $ claude mcp add conductor2 --scope user -- node ~/conductor-v2/mcp.js # then, from any session: plan a mesh swarm of 4 to research x402, then fire it
Local-first by design

It only reads your own machine

Watching is read-only observation of trails that already exist — nothing leaves your laptop. The cockpit binds to 127.0.0.1 only.

  • Reads your own ~/.claude — never another user's transcripts.
  • State-changing requests require a local origin + CSRF header.
  • Destructive control (flatten / broadcast / close) needs a confirm token.
  • No destructive broadcast — ever. The desk-wide button is always a safe stop.
honest limits — v1
Control is managed-only. Plain terminal windows you opened yourself stay read-only — there's no reliable way to inject input into them.
“What's left” is inferred from the transcript, not a real todo list. Best-effort, honestly labelled.
“Live” = recently touched. Per-row time always shows true last activity.
Get started

Two ways to run Conductor today

Free · open source

Add the MCP server

Wire Conductor into Claude Code at user scope and it's available in every session. Ask “what's left across my windows?” or run an orchestrator that triages, continues the safe work, and stops on anything irreversible.

# clone once $ git clone https://github.com/yksanjo/conductor ~/conductor # register the MCP (user scope = everywhere) $ claude mcp add conductor --scope user \ -- node ~/conductor/mcp.js
Get the MCP →
Visual · 1 command

Launch the cockpit

Prefer to watch? npm link puts a global conductor on your PATH — no build, no dependencies — then one command opens the live web dashboard in your browser, grouped by status and refreshing every 4s.

$ cd ~/conductor && npm link $ conductor # glance: table $ conductor up # the visual cockpit $ conductor say soag yes # reply
Read the docs →
FAQ

Frequently asked questions

How is this different from just opening each tab?

Opening tabs is the problem. Conductor reads every window's transcript at once and floats the one that needs you — wedged, waiting, or done — to the top, so you supervise by exception instead of polling fifteen terminals by hand.

Does it need me to instrument my agents?

No. It reads the .jsonl trail Claude Code already writes under ~/.claude/projects/. Zero instrumentation, zero new infrastructure, zero dependencies. Other workers (bots, validators) just need a small adapter file.

Can it ship something on its own?

Not anything irreversible. Ordinary work auto-continues, but the moment a window's question — or a proposed reply — touches deploy, send, delete, or spend, the gate in policy.js refuses and returns the reason so a human decides. Approving an irreversible action is always your call.

Is my code or my transcripts sent anywhere?

No. Everything is local-first. The cockpit binds to 127.0.0.1, reads only your own ~/.claude, and state-changing requests require a local origin plus a CSRF header. Run it for yourself, not as a service.

What about windows I opened by hand?

Watched, always. Controlled, only if you adopt them — Conductor forks the session into a managed tmux window (full history intact) so it can inject replies. Plain terminals the OS won't let anything type into stay read-only, by design.