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.

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

• Windows developersA signed installer, native Windows Muse Code with PowerShell, and WSL2 path translation when you need it. The Windows setup tax, paid once by the app instead of by you.
• macOS power usersSeveral repositories, several threads, and a history that outlives the terminal. A universal DMG, 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.