runcastle vs Conductor

Both tools solve the same first problem: one Claude Code session at a time is a bottleneck, and running several by hand means juggling git worktrees in a pile of terminals. Conductor and runcastle both give every agent its own branch and its own checkout. What differs is what surrounds the agents — and which operating systems you can run them on.

What each one actually is

Conductor describes itself as a way to “Run parallel Claude Code, Codex, and Cursor agents in isolated workspaces on your Mac”, and its docs add OpenCode to that list. The unit of work is a workspace: “Each task gets its own workspace, branch, files, terminal, diff, and review path.” Underneath, that is git — “When you create a workspace, Conductor creates a Git worktree for that workspace and checks out a branch inside it” — with the app automating the parts you would otherwise do by hand: creating the branch and worktree, copying the local files you allow, running setup and run scripts, keeping the diff visible, tracking pull request state, and archiving the workspace when the task is done. When the work is finished, “Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”

runcastle is an opinionated programming system layered on Claude Code — the IDE to Claude Code's text editor. Every feature gets a persistent session that walks six phases: ideation, spec, tickets, build, review, shipped. You get grilled on an idea until a spec and a set of tickets fall out; sandboxed AFK agents burn those tickets on the feature's branch; you test drive the result and merge. Human in the loop at only the two ends. It runs entirely on your machine — a Bun server plus a browser UI at http://localhost:4512, with no runcastle account and no hosted backend.

Side by side

The real difference: where the tool starts

Conductor's model begins at the task. You have something you want done, you make a workspace for it, an agent works in that worktree, and the app carries it to a pull request. That is a genuinely hard surface to build well — the diff view, the checks, the PR state, the setup scripts that make a fresh worktree actually runnable — and Conductor is built around getting it right for several sessions at once.

runcastle begins one step earlier and ends one step later. Before any agent runs, a real Claude Code terminal argues with you until the idea is concrete, writes the decisions to docs/features/<slug>/ in your own repo, and cuts them into atomic tickets in a dependency order. That order is what makes the build parallel: everything unblocked starts at once. Then you click burn and close the tab — the tickets are burned headless inside a container, committing to the feature branch, with no session for you to sit and watch. At the other end, two gates are the only places the pipeline stops for you: the ticket review before the burn, and the merge after the test drive.

So the honest framing is not “which one runs agents better”. It is: do you want a great cockpit for sessions you are steering, or a pipeline that takes an idea and hands back a branch? Conductor invests in the first. runcastle invests in the second, and deliberately does not rebuild the chat UX at all.

Platform is a real dividing line

Conductor is Mac-only today; its install page says plainly that it “is not available for Windows or Linux yet” and offers a waitlist. That is not a knock on the product — a native Mac app is part of why it feels good — but it settles the question for a lot of people before any feature comparison starts. runcastle runs on macOS, Windows and Linux, because it is a Bun server and a browser tab rather than a desktop binary.

When Conductor is the better choice

• You want agents other than Claude Code. Conductor runs Claude Code, Codex, Cursor and OpenCode side by side. runcastle drives Claude Code and nothing else. If your workflow mixes models or you want to race two agents on the same task, that is Conductor's win outright.
• Your work is already shaped. A queue of well-understood bugs, chores or small PRs does not need to be grilled into a spec. runcastle's pipeline is overhead when the thinking is already done; Conductor's per-task workspace is exactly the right size for it.
• You live in GitHub pull requests. Conductor's flow ends in a PR, with checks and PR state visible in the app. runcastle's flow ends in a local merge to your feature branch, which is a worse fit if review happens on GitHub with other humans.
• You want a team or cloud story. Multiplayer, cloud workspaces, an admin portal and SSO exist on Conductor's paid plans. runcastle has no account and no hosted anything by design, so there is nothing there to share.

When runcastle is the better choice

• You are not on a Mac. Today this is the whole decision.
• The expensive part is deciding what to build. The failures that hurt in agent work are the ones where a lot of code got written against a plan nobody checked. runcastle spends its ceremony there, on purpose.
• You actually want to be away. Burns are unattended: containers, a dependency order, commits landing on the branch while you are elsewhere. The pipeline asks for you twice and otherwise leaves you alone.
• You want the record in your repo. Spec, decisions, research and notes are plain markdown under docs/features/<slug>/ — versioned, diffable, and still useful if you stop using runcastle entirely.

Sources

Everything above about Conductor was checked against its own site and docs on 10 August 2026, against release 0.79.0. Products move; if you are reading this much later, check the originals.

• conductor.build — product description, supported agents, Mac-only positioning, current version.
• Conductor docs — introduction — the workspace model and the review-to-merge flow.
• Conductor docs — install — macOS availability, the Windows and Linux waitlist, GitHub and agent-provider requirements.
• Conductor docs — git worktrees — how workspaces map to worktrees and branches.
• Conductor pricing — Free, Pro, Teams and Enterprise plans.
• Conductor changelog — release 0.79.0 and the Cloud releases.

Claims about runcastle come from its README and CONTEXT.md, and are documented in more depth under the docs.