Xum: a desktop multiplexer for running coding agents in parallel

The problem Xum targets: several agents, one working tree

Running one coding agent in your project directory is straightforward. Running three is not. They edit the same files, they fight over the same git index, and when one of them runs a build or a test suite it changes state the others can see. The usual workaround is to clone the repository two or three times, or to create git worktrees by hand, and then keep track of which terminal belongs to which checkout. That bookkeeping is the actual cost, not the agent calls.

Xum, described in its package.json as a "coding agent multiplexer", is aimed at that bookkeeping. The README frames the core feature as "isolated workspaces with central view on git divergence", and the screenshots include a git status view captioned as keeping you looped in on changes and potential conflicts. The target user is someone already comfortable running an agent from a terminal and now wants several of them in flight without losing track of which branch has what.

It is a desktop application first. The repository lists desktop.html and terminal.html at the top level, and the package.json carries a desktopName of xum.desktop. There is also a server mode: the Dockerfile builds an image it calls the Xum server, and the README screenshot set includes a responsive mobile UI for that mode. So the product is not only a window on your laptop.

Three runtime modes and what each one isolates

The isolation mechanism is the runtime, and the README names exactly three: Local, Worktree and SSH. Local runs the agent directly in your project directory, which means no isolation at all beyond whatever the agent itself does. Worktree creates git worktrees on your local machine, so each agent gets its own checkout backed by the same object store. SSH executes remotely on a server over SSH.

The distinction matters more than it first appears. Worktree isolation is cheap because git shares history between worktrees, but it is still your machine: CPU, disk and any global toolchain state are shared. SSH moves the compute elsewhere, which is the option you want if the agents run long builds, but it also moves the filesystem, so the divergence view has to compare states across a network boundary. Local is the mode to pick when you are debugging the agent itself and want it to see exactly what you see.

The README links each runtime to its own documentation page, which is a reasonable sign that the differences are documented rather than implied. The README does not describe what happens when two worktree agents touch the same file, nor how conflict resolution is presented beyond the phrase "potential conflicts" in a screenshot caption. That is a gap worth closing before you rely on it for a repository with a lot of shared configuration.

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

Xum has its own agent loop, and the README is direct that much of the surrounding UX is inspired by Claude Code. Familiar items are listed by name: Plan/Exec mode, vim inputs, and /compact. Two things are presented as additions rather than borrowings: opportunistic compaction and mode prompts, each with its own documentation link.

On models, the README lists sonnet-4-*, grok-*, gpt-5-* and opus-4-* as supported, with Ollama for local LLMs and OpenRouter for what it calls the long tail. The dependency list in package.json backs this up at the provider level: separate AI SDK packages for Anthropic, OpenAI, Google, Amazon Bedrock, DeepSeek, Moonshot AI and xAI, plus openai-compatible for anything that speaks that shape. That is a wider provider surface than most single-vendor agent tools, and it is the main reason to prefer Xum over a tool tied to one model family.

The .env.example file shows the practical side: ANTHROPIC_API_KEY, OPENAI_API_KEY and OPENROUTER_API_KEY are the variables named there, and the comment notes they are required for integration tests when TEST_INTEGRATION=1. The README does not state how credentials for the other providers are supplied, so if you intend to use Bedrock or DeepSeek, check the configuration docs rather than assuming the three variables above are sufficient.

Installing Xum and starting a server

The README's install section is short and points at pre-built binaries. It says to download them from the releases page for macOS and Linux, and links to a fuller installation page. Windows is not mentioned in that section, even though package.json defines a dist:win script, so treat desktop Windows support as unconfirmed by the README.

For the server path, the repository ships a docker-compose.yml whose quick start is a single command. The compose file maps port 3000 and keeps data in a named volume, and its comments note that legacy service, container and volume identifiers stay stable for existing automation.

docker compose up -d

Adding a project goes through the server binary rather than a UI step, according to the compose file's own comment. The command below is quoted from that file; the path is the container-side location, so you would mount your repository there first by uncommenting the volume line.

docker compose run --rm mux-server --add-project /projects/my-repo

If you expose the server beyond localhost, the .env.example defines XUM_SERVER_AUTH_TOKEN as an optional bearer token for HTTP and WebSocket auth, with MUX_SERVER_AUTH_TOKEN still accepted as a compatibility alias. When it is set, HTTP clients send an Authorization: Bearer header and WebSocket clients pass the token as a query parameter or a Sec-WebSocket-Protocol header value. Leaving it empty means no auth, which is fine on a loopback interface and not fine anywhere else.

The Dockerfile also documents a direct run, with the volume mounted at /root/.mux. Note that the container path keeps the old name deliberately, per the Dockerfile comment, so existing volumes upgrade in place.

docker run -p 3000:3000 -v ~/.xum:/root/.mux xum-server

The rename, and why it shows up in your commands

Xum was previously called Mux. The README explains the reason plainly: Mux.com raised a trademark concern, and rather than spend time on the dispute the project renamed itself. The README also makes the honest observation that "Mux" is a common abbreviation of "multiplexer" and that confusion between the two projects is not expected.

The consequence for anyone adopting it is that the old name is still load-bearing in places. package.json declares two binaries, xum and mux, both pointing at dist/cli/index.js, so the mux command still works. The compose service is named mux-server and the container is mux-server. The data volume is mux-data and the in-container path is /root/.mux. The auth token variable accepts MUX_SERVER_AUTH_TOKEN as an alias. The documentation domain referenced throughout the README is mux.coder.com, not xum.coder.com, even though the repository's homepage field points at xum.coder.com.

None of this is a defect. It is what a rename looks like when you refuse to break existing automation, and the comments in docker-compose.yml and the Dockerfile say so explicitly. But it means you should not assume that a guide, a script or a Stack Overflow answer using the name Mux is stale. In several of these cases it is deliberately still correct.

Where Xum is the wrong tool

The clearest limitation is platform coverage. The README's install section offers binaries for macOS and Linux. Nothing in the repository's documentation describes a supported Windows desktop build, despite the dist:win script in package.json. If your team is on Windows, the README does not give you a path.

The second is the licence. Xum is AGPL-3.0-only per package.json, and the README carries the standard AGPLv3 notice. If you are embedding an agent tool inside a product you distribute, the AGPL's network-use terms are a different proposition from a permissive licence, and this is a consideration to raise with whoever handles licensing at your organisation rather than something to reason about from a README.

The third is subtler. Xum is a multiplexer, which means its value scales with how many agents you run. If you run one agent at a time, the workspace isolation, the divergence view and the agent status sidebar are overhead you are paying for and not using. A plain terminal and one checkout will be less to learn. The costs table screenshot suggests the app also tracks token consumption, which is useful, but it is not a reason on its own to adopt a multi-agent workflow.

Finally, the README does not document rollback of agent-applied changes, and it does not describe how the worktree runtime handles conflicts when two agents edit the same file. Those are the two questions I would want answered before pointing this at a repository with a large shared configuration surface.

How Xum differs from a single-agent CLI

The obvious comparison is Claude Code, and Xum's own README invites it by naming the borrowed features. The difference in approach is architectural rather than cosmetic. A single-agent CLI assumes one session against one working directory; its context management, its permission prompts and its output are all scoped to that session. Xum assumes several concurrent sessions and builds the surrounding furniture accordingly: a sidebar where agents report status, a git divergence view across workspaces, a costs table, and a context management dialog that consolidates compaction controls in one place.

That reframing is the product. The /compact command exists in both, but Xum adds opportunistic compaction, which the README links to its own documentation page. The README does not explain the mechanism in the repository text, so the linked page is the place to look.

The other axis is model choice. A tool built by a model vendor will be best at that vendor's models. Xum's dependency list spans Anthropic, OpenAI, Google, Bedrock, DeepSeek, Moonshot AI and xAI, with Ollama for local models and OpenRouter for the rest. If your constraint is that different tasks should go to different models, or that some work must stay on a local model, that breadth is the reason to pick Xum over a first-party CLI.

Maintenance, releases and what the cadence tells you

The last push to the repository was on 2026-09-10. The most recent releases are v0.28.5 on 2026-09-09 and v0.28.4 on 2026-09-02, with a nightly build v0.28.6-nightly.17 published on 2026-09-10. The version in package.json is 0.28.5, which lines up with the latest stable tag.

Two things follow from that. First, the project publishes nightlies alongside stable releases, so if you want to track it closely there is a channel for that, and if you want stability you should pin to the tagged versions rather than the nightly line. Second, the version number is still in the 0.28 range, which is worth noting when you plan upgrades: at that point in a project's life, minor versions can carry behaviour changes. The README does not document an upgrade procedure or a compatibility policy between versions.

The build setup is not trivial. package.json pins packageManager to [email protected], while the Dockerfile installs [email protected] for the server image, and the build depends on a patches/ directory that the Dockerfile notes bun install fails without. The Dockerfile also installs an optional electron package because tsgo typechecks sources that import it, even though the server image never runs Electron. If you build from source rather than downloading a binary, expect to deal with that toolchain.

Editorial conclusion

Adopt Xum if you already run more than one coding agent at a time and you want the isolation boundary handled by the tool rather than by hand-created git worktrees and terminal tabs. Skip it if you work on Windows, if a single agent session is enough, or if AGPL-3.0 is incompatible with how you distribute your own product. Before committing, verify two things: that the runtime you intend to use behaves as documented for your repository layout, and that the model provider you want is reachable through the configuration path the docs describe. The rename from Mux to Xum also means older links, scripts and bookmarks may point at the previous name.

Frequently asked questions

Official sources

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