Shelbi vs Conductor

At a glance

Where Shelbi excels

A workspace pool you size and name, not one spawned per task

Conductor's unit is also called a workspace, but it's ephemeral — ⌘N spins up a fresh worktree per task and disposes of it on archive. Shelbi declares a fixed pool of named workspaces in the project YAML; each one owns a persistent worktree at a known path and handles one task at a time. The pool size is the parallelism cap — no accidental fan-out that outruns your RAM, and no git worktree add on the hot path. A new task on bravo is a branch switch in the worktree bravo already owns. (See Workspaces.)

Workspaces across more than one machine

Conductor is explicitly single-Mac: every workspace runs on the laptop the app is installed on, and if the Mac sleeps, everything freezes. Shelbi treats machine as a first-class workspace property. The pool can mix hub-local workspaces with workspaces on any SSH-reachable host — a Linux devbox, a beefy build server, a teammate's idle machine — and tasks can carry a prefers_machine hint that the orchestrator honors when it dispatches. Concretely: route GPU work to your CUDA box, infra changes to a hardened Linux runner, and quick edits to the laptop, all from the same Kanban board. (See Workspaces — local vs. remote workspaces.)

An orchestration loop you can read and edit

Conductor's dispatcher is a closed-source feature inside a closed-source app. Shelbi's orchestrator is just a Claude session in a tmux pane, loaded from a plain-text agent prompt you edit per project at ~/.shelbi/projects/<name>/agents/orchestrator/instructions.md (with project-wide context in agents/_shared/preamble.md). Want it to auto-merge a specific authorized loop? Edit the prompt. Want a different routing rule? Edit the prompt. The scheduler is text. (See Orchestrator — customizing the prompt.)

A plain-text protocol, not a UI

Conductor's workflow is mediated by the sidebar — clicks, contextual action prompts, in-app diff. Shelbi's wire format is two files anyone can tail or grep: an append-only events log at ~/.shelbi/events.log with one line per state change, and a per-workspace review-ready marker the hub poller watches. The workspace never runs a shelbi command — printf '%s\n' <task-id> > .claude/shelbi-review-ready is the entire on-workspace protocol. That is how a remote workspace can ship with nothing installed but tmux, git, and an agent CLI. (See The events log and Workspaces — how a task completes.)

A review column that exists on purpose

Conductor's default loop is workspace → diff → PR → merge → archive, with the user moving through contextual actions. Shelbi makes "ready for human review" its own column. The hub poller promotes a card to review the moment the workspace writes its marker; the sidebar's Ready for Review list mirrors it, and selecting a card there checks the branch onto a dedicated review workspace with a fresh Claude window that boots the app for you to click through. review → done is yours — the orchestrator does not make that move except under explicit authorized loops. (See Workflows.)

Where Conductor excels

A polished native desktop app

If you live in a Mac GUI, Conductor's app is genuinely good — keyboard shortcuts (⌘N, ⌘⇧D, ⌘⇧P), an in-app side-by-side and unified diff viewer, inline comments that pin to lines and feed back to the agent as context, sound and color preferences. Shelbi is a terminal Kanban plus tmux panes; if you don't want to live in a terminal, Conductor's surface is more inviting.

Multi-agent provider support in one place

Conductor speaks Claude Code, Codex, and Cursor through a single model picker, with custom routing through Amazon Bedrock and Google Vertex for enterprise Claude traffic. You can A/B the same task on Claude and Codex in adjacent workspaces and compare diffs. Shelbi runs whatever CLI a workspace is configured for; mixing providers per task isn't its native shape.

First-class GitHub and Linear integration

Open PRs from inside the app (⌘⇧P), follow Actions status on the branch, sync review comments bidirectionally with GitHub, create workspaces directly from Linear or GitHub issues with the issue body pre-loaded as the task prompt. If your workflow already lives across GitHub PRs and Linear tickets, Conductor wires them tighter than Shelbi does today.

Per-workspace dev servers and in-app preview

Conductor assigns each workspace its own CONDUCTOR_PORT so multiple dev servers can run side-by-side without colliding, plus an in-app browser preview for built artifacts. For frontend work where you want five live previews open at once, that's a real ergonomic win.

Choose Shelbi if…

• Your team has workspaces on more than one machine, or you want work to survive a laptop reboot or SSH drop.
• You want the scheduler to be code you can read and override per project.
• A plain-text events log and a file-based handoff protocol matter more than a polished GUI.
• "Don't merge until a human signs off" is non-negotiable, and you want a Kanban column for that review step.
• You're already comfortable in tmux and the terminal.

Choose Conductor if…

• You're on a single Mac and want the most polished desktop UI for running parallel agents.
• You want one surface that speaks Claude Code, Codex, and Cursor with per-task model picking and A/B comparison.
• Tight GitHub-PR and Linear-issue integration is load-bearing for your team's workflow.
• You'd rather pay nothing for the app and bring your existing Claude or Codex subscription than configure a workspace pool yourself.