Use cases

A graphical Muse Code client earns its place when the number of agent threads exceeds what you can hold in your head. These pages cover the situations where that happens: Windows setup friction, parallel agents across repositories, remote execution, client work, monorepos, and maintainers reviewing what an agent did.

Last updated 19 September 2026

If none of these describe you, the terminal is probably still the right answer.

• Windows developersAn auto-updating installer (not code-signed yet), native Windows Muse Code with PowerShell, and WSL2 path translation for when you need it.
• macOS power usersSeveral repositories, several threads, and a history that outlives the terminal. A DMG for each Mac chip, a session sidebar, inline diffs and a cost view.
• Running agents in parallelIsolated worktrees, one sidebar, and clear marks for which thread is running, finished, or blocked on you. Plus the cost of all that parallelism, per thread.
• Remote developmentRun the daemon and the muse CLI on the machine that holds the repository, then supervise from a browser on a laptop. Same UI, same sidebar, same approvals.
• Open source maintainersMany repositories, short bursts of attention, and a need to see exactly what an agent did before it touches a project other people depend on.
• Freelancers and consultantsSeveral clients, several codebases, and a real need to know what each piece of work actually consumed. Projects, sessions and cost, separated by directory.
• MonoreposOne repository, many packages, and agents that need isolation. Worktrees as projects, a remote daemon for the heavy machine, and diffs you can actually read.
• If you like the terminalKeyboard first, no mouse required, no migration, and the CLI keeps working. What a graphical client adds that a terminal structurally cannot.