Xum vs Conductor
Xum and Conductor both offer parallel coding agent management with isolated workspaces, but they represent different deployment models. Conductor was a managed commercial service; Xum is self-hosted and open source.
Conductor shuts down on 2026-11-20. Teams that built workflows on Conductor should plan their migration before that date.
| Feature | Xum | Conductor |
|---|
| License | AGPL-3.0 | Proprietary |
| Self-hosting | Yes | No |
| LLM providers | Claude, GPT, Grok, Ollama, OpenRouter | Proprietary selection |
| Pricing | Free (self-hosted) | Subscription |
| Platforms | macOS, Linux, SSH server | Managed service |
Xum's parallel-agent model mirrors Conductor's core workflow: each agent runs in an isolated workspace, and you review changes across agents in a central view. The migration path is conceptually straightforward, with Xum adding LLM flexibility that Conductor did not offer. Conductor users who relied on GPT or Claude can keep those models; those who want to test local Ollama models for cost control can do that too.
The practical differences are infrastructure and ownership. With Xum, source code stays on your machine or server. There is no vendor to call when something breaks, which means your team owns both the upside (full configuration control) and the downside (you manage the binary and updates). Conductor's managed experience meant less operational overhead, but that trade-off disappears when the service ends.
For teams evaluating alternatives now, Xum is the strongest direct replacement in the parallel coding agent category: it matches the core workflow, runs where you need it, and carries no ongoing subscription cost.