mmux vs Solo

What is Solo?

Solo calls itself "the meta-harness for coding agents" [1]. It is a desktop app built with Tauri that runs next to the CLI agents you already use, such as Claude Code, Codex, OpenCode and Pi, and gives them shared processes, context and tasks. You describe the project's dev server, queue workers, tunnels and similar commands once in solo.yml, which you can commit, and humans and agents then share those processes instead of starting duplicates [1][4]. Solo can also suggest processes for stacks such as Laravel, Next.js, Django and Rust [1].

Agents run in real terminals inside the app. Solo shows whether an agent seems to be working, idle or waiting for permission (the site says this detection is heuristic), and a lead agent can spawn, message and wait for agents in other harnesses [1]. Agents reach Solo through an MCP server, a localhost-only HTTP API or the solo CLI; the MCP tools cover projects, processes, output, agents, scratchpads, todos, prompt templates and more [1][6]. The HTTP API needs the desktop app to be running [1].

Solo is published by Try Hard Studios. Version 0.10.1 (September 2026) is a beta for macOS 11+ and Windows 10 1809+, with Linux listed as coming soon [2][3]. It is free for up to 4 projects and 20 processes; Pro is $99 per year [1].

Where Solo is better

• Process supervision. A process in solo.yml can set auto_restart to come back after it exits unexpectedly, and restart_when_changed to restart when files matching a glob change [4]. mmux has neither: you restart a process yourself with r or mmux restart.
• A real GUI. Solo is a desktop window with a sidebar that shows CPU and memory per process, keyboard palettes and no prefix keys to learn [1][8]. mmux is a terminal UI with mouse support, but it is still a terminal UI.
• MCP and HTTP for agents. Agents that prefer MCP get typed tools, for example get_process_output, search_output and get_process_ports, which lists the localhost ports a process listens on [5]. mmux only offers a CLI, and has no port detection.
• Windows. Solo ships a 64-bit Windows beta with Windows and WSL execution profiles [2][3]. mmux supports macOS and Linux.
• Shared context for agents. Scratchpads, todos with dependencies and prompt templates are built in and reachable over MCP [1][6]. mmux has nothing comparable.
• A trust gate for committed commands. New or changed commands from solo.yml can be blocked until you approve them [1][4], which matters when you pull a teammate's change to that file.

Where mmux is better

• Sessions survive closing the terminal and SSH drops. mmux runs in a per-directory tmux session, so agents and dev servers keep running after you close the window or lose the connection. Run mmux or mmux attach to rejoin. Solo stops its processes when you quit it normally [7].
• Remote and headless machines. mmux works the same on a laptop and on a Linux box you reach over SSH, and it still raises native desktop notifications on your machine when an agent finishes. Solo's own tmux comparison says it does not run on headless servers [8].
• Restore after quit. When you reopen a directory after a quit, a crash or a restart-to-update, Claude, Codex, Pi and Grok agents resume their conversations and terminals reopen where you left them.
• Git panel and worktrees. A native git panel commits with an AI-suggested message and can schedule commits. w opens a git worktree as its own project box with its own agents and processes, only one checkout runs a given process at a time so ports stay the same, M merges back, and finished worktrees clean themselves up.
• Answering agents from scripts. mmux wait blocks until an agent is done or asks something, and mmux answer picks an option on its permission prompt, so another agent or a script can drive it end to end.
• Linux, free and open source. mmux is a single Rust binary for macOS and Linux (arm64 and x86_64), licensed GPLv3, with no project or process limits.

When to use which

Moving from Solo to mmux

1. Install mmux and run mmux init in the project. It writes an mmux.yaml and lets you pick your agent harnesses.
2. Copy each entry under processes: in solo.yml into mmux.yaml. command becomes cmd plus args, working_dir becomes cwd, auto_start becomes autostart (note that mmux defaults it to false, Solo to true), and env stays env.
3. auto_restart and restart_when_changed have no mmux equivalent. If you need them, run the command under your own watcher.
4. Optionally add a stop: teardown such as docker compose down, which runs when you stop the process or quit mmux.
5. You can keep solo.yml committed for teammates who use Solo. mmux ignores it.

A Solo process like Web: { command: npm run dev } becomes:

# mmux.yaml
name: storefront
processes:
  - name: Web
    cmd: npm
    args: ["run", "dev"]
    autostart: true

Then open it, and give your agents the CLI they will use instead of Solo's MCP tools:

mmux
mmux read "Web" -n 80
mmux restart "Web"