Xum: a desktop multiplexer for parallel coding agents

The problem Xum targets: many agents, one repository

Running one coding agent against a working copy is manageable. Running three or four at once against the same checkout is not, because they overwrite each other's files and you lose track of which change came from which run. Xum's answer is to give each agent its own workspace and then present the divergence centrally. The README describes the product as a coding agent multiplexer and lists isolated workspaces with a central view on git divergence as the first feature. The audience is therefore engineers who already drive agents from a terminal or an editor and have hit the point where concurrency, not capability, is the bottleneck. It is a desktop application, not a library, and the README points to pre-built binaries rather than a package install. The project was renamed from Mux to Xum after Mux.com raised a trademark concern; the README states that the rename was chosen rather than continuing the dispute. That history matters for anyone searching for older documentation, since links in the README still point at mux.coder.com.

Three runtimes decide where an agent actually writes

The isolation model is the part worth understanding before installing. Xum offers three runtimes, and they differ in where the agent's edits land. Local runs directly in your project directory, which means no isolation at all beyond what the agent itself does. Worktree creates git worktrees on your local machine, so each agent gets a separate checkout backed by the same repository. SSH runs the agent remotely on a server over SSH. That spectrum is a sensible design: the worktree option is the one that makes parallel agents safe on a single machine, because git already knows how to keep two checkouts of the same repository apart. The README frames the central view as tracking git divergence, which is the natural companion to worktrees. It does not explain in the README how conflicts between worktrees are surfaced or resolved, and the linked runtime documentation is where that detail would live. Treat the runtime choice as the main configuration decision, not the model choice.

Models, the agent loop, and what is borrowed from Claude Code

Xum ships a custom agent loop, and the README is explicit that much of the core UX is inspired by Claude Code. Familiar features listed include Plan/Exec mode, vim inputs and /compact, alongside additions such as opportunistic compaction and mode prompts. Model support is described as multi-model, with identifiers given as sonnet-4-*, grok-*, gpt-5-* and opus-4-*, plus Ollama for local LLMs and OpenRouter for what the README calls the long tail of LLMs. Two things follow from this. First, the tool is not tied to a single vendor, which is unusual among agent front ends and is the strongest argument for choosing it over an editor plugin locked to one provider. Second, the loop is theirs, so behaviour will not match Claude Code exactly even where the feature names do. The README also mentions rich markdown output including mermaid diagrams and LaTeX, and screenshots show a costs tab tracking token consumption, a context management dialog, and agent status reported through a sidebar. A VS Code extension is listed for jumping into Xum workspaces from the editor. There is also a server mode with a responsive UI for mobile, according to a screenshot caption.

Install and the configuration surface you will touch

Installation is deliberately plain: the README says to download pre-built binaries from the releases page for macOS and Linux, and points to a documentation page for more on installation. There is no npm or Homebrew command in the README, so do not expect one. Development setup is not in the README either; it defers to AGENTS.md in the repository for setup and guidelines, which is a reasonable place to look if you intend to build from source rather than use a binary. The configuration keys that appear in the README are the model provider options, with documentation anchors for Ollama local and OpenRouter cloud under a config/models path. The runtime documentation is split by mode: local, worktree and SSH each have their own page under a runtime path. Beyond those, the README does not enumerate config file locations or key names, so anyone planning to automate setup should read the documentation site rather than infer from the README. The VS Code extension has its own integrations page.

Version numbering, nightlies and the cost of tracking this project

The release pattern is the clearest signal about maturity. Recent tags include v0.28.6-nightly.17, v0.28.5 and v0.28.4, with the nightly published hours before the last push and the numbered releases spaced roughly a week apart. A project that publishes nightly builds of a 0.28 line is moving quickly and expects users to accept churn. That has a direct maintenance cost: if you install a nightly, you are opting into a build that exists to test the next numbered release, and the README's install instructions send you to the releases page without distinguishing the two. Pin to a numbered release unless you are deliberately testing. The upgrade cost is otherwise low, since the app is a downloaded binary rather than a dependency in your build, but the documentation URLs in the README still use the old mux.coder.com host, so link rot is a live concern after the rename. There is no migration or changelog guidance in the supplied material, and I cannot say from it whether config files carry across versions.

Where Xum is the wrong tool, and what to use instead

Xum assumes a git repository and a desktop environment. If your work is not in git, the worktree runtime has nothing to work with, and the local runtime gives you no isolation at all, which removes the reason to use a multiplexer. If you work on Windows, the README lists binaries for macOS and Linux only, so you would be building from source with no documented procedure in the README. If you want one agent and one conversation, the added workspace machinery is overhead. The honest alternative for a single-agent workflow is the terminal tool you already use, or an editor-integrated assistant, because Xum's value comes from running several agents side by side and watching their divergence. The difference in approach is architectural: an editor plugin typically attaches one agent to one open workspace and leaves concurrency to you, while Xum treats the workspace as the unit of isolation and the git divergence view as the control surface. That also means Xum is the wrong choice if you want the agent embedded in your existing editor session rather than in a separate application, even though a VS Code extension exists for jumping between the two.

Licence position and what it means for adoption

Xum is licensed under AGPL-3.0, copyright Coder Technologies, Inc., and the README reproduces the standard grant to redistribute and modify under version 3 of that licence. The practical consequence is the network clause: if you modify Xum and expose it to users over a network, the AGPL's source-availability terms are generally understood to apply to your modified version. Xum does have a server mode with a mobile UI, so that scenario is not hypothetical for this project. If you are a company that forbids AGPL in its toolchain, or you intend to embed Xum in a product you distribute under other terms, this licence is a blocker and you should get your own legal advice rather than rely on this summary. For internal use where you do not distribute modifications, the licence is unlikely to be an obstacle. Note also that the README's licence text covers the application; the status of the docs images and the VS Code extension is not stated in the supplied material.

Editorial conclusion

Adopt Xum if you already run more than one coding agent at a time and want their edits kept apart by git worktrees, SSH targets or plain project directories, with a single view of divergence. Do not adopt it if you need a stable 1.0, a Windows build, or a permissive licence for a closed product, because the project is at 0.28.x, the README lists binaries for macOS and Linux only, and it is AGPL-3.0. Before committing, verify that the worktree runtime behaves correctly against your repository's branch layout, that your chosen model endpoint (including Ollama or OpenRouter) is accepted by the config, and that the release you install is a numbered release rather than a nightly tag.

Official sources

1. coder/xum on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases