herdr vs cmux, after two months on each

After two months on each, developer herdr 0.7.4 and cmux 0.64.x differ mainly in architecture: herdr runs on the server and attaches via SSH, while cmux is a macOS app with a new SSH daemon. The author prefers herdr for keeping agents on the same machine, despite cmux's June updates adding remote terminal persistence and SSH agent forwarding. herdr offers a third-party plugin marketplace, while cmux's extension API remains in beta.

herdr vs cmux, after two months on each I left cmux for herdr at the start of June because its remote support did not fit how I work. Maybe I should have waited a little longer cmux shipped a daemon that keeps SSH terminals alive across reconnects https://cmux.com/docs/changelog on 1 June, then added SSH agent forwarding on 4 June. I stayed on herdr /posts/herding-agents-with-herdr/ anyway. I’ve now spent about two months with each, moving between Linux boxes and my Mac while running several coding agents at once. | herdr 0.7.4 | cmux 0.64.x | | |---|---|---| | runs on | Linux and macOS stable; Windows preview beta | macOS | | lives where | server you attach to | app you install | | remote | client attaches with --remote | SSH daemon, added June | | plugins | third-party marketplace | extension API in beta | | browser | plugin with its own Chromium; local sessions only | built in, imports sessions | | licence | AGPL-3.0 | GPL-3.0 | Where the agents live where-the-agents-live cmux is a native macOS app with terminal panes. You install it on the Mac in front of you and connect to other machines from there. herdr runs on the machine doing the work, and you attach a terminal client to it. They can look similar locally. Over SSH Secure Shell , that difference matters. herdr is stable on Linux and macOS, which covers the two systems I switch between. Windows support is a preview beta, and the docs warn that it may be reduced or removed. I already use Windows Subsystem for Linux WSL for development on my gaming PC, so that’s how I run it there. Both support the agent CLIs I use, and new ones tend to arrive within weeks. cmux added hooks for OMP https://omp.sh/ , the Oh My Pi coding agent, in June. The support list is not a reason to pick one. The tools differ more in how they detect agent state. herdr checks the foreground process, then uses lifecycle hooks when an agent provides them. Without a full hook, it falls back to a screen manifest that checks the last few terminal lines for known prompts. That still gives it a rough state for agents without a direct integration. Claude Code takes that path because its hooks do not report every state change, so herdr can take a few seconds to recognise a blocked prompt. I mostly run Claude Code with Fable or Opus at the moment, but sometimes use pi with GLM 5.2, which has direct lifecycle hooks. The agent I use most is slower to update in the sidebar. With herdr, the panes and agents stay on the remote box. herdr --remote workbox attaches the local client over SSH. cmux now keeps its remote terminal alive through a detachable daemon and forwards the local SSH agent, so reconnects and Git access work there too. The difference is smaller now, but I still want the multiplexer on the same machine as the agents. Plugins plugins The herdr plugin marketplace https://herdr.dev/plugins/ indexes public GitHub repositories tagged herdr-plugin . A working plugin also needs a herdr-plugin.toml manifest, and herdr plugin install owner/repo installs it straight from GitHub. There is no submission queue. cmux’s extension API, CmuxExtensionKit, is still in preview. Custom sidebars use a Swift interpreter behind the Beta Features flag. I run two herdr plugins. reviewr https://github.com/persiyanov/herdr-reviewr puts the code review loop I use /posts/reviewing-code-you-didnt-write/ beside the agent. I select a line range and write a comment, then keep going through the diff. “Add all to chat” writes each note into the active agent’s input as path:start-end - comment . It never edits the worktree or sends a comment on its own. Its last turn scope limits the diff to changes made since the agent’s most recent turn began. Neither base tool has that view. herdr-browser https://github.com/ogulcancelik/herdr-browser handles local previews. When a dev server prints http://localhost:5173 , I Control-click the link and the plugin opens Chromium in a right split. A normal click still goes to the terminal, and a non-local URL opens in my desktop browser. That browser does not work with the remote setup I prefer. Its README says the image stream sends too much data per frame over SSH. reviewr only draws text in the terminal, so it works over --remote . herdr-browser needs Kitty’s image protocol, which the remote connection does not carry. When I am attached to another box, I use Playwright screenshots to check Flutter and React changes instead. I already had Playwright Model Context Protocol MCP configured, so the agent had two ways to open a browser and tried the wrong one in the screenshot above. The fix is in the herdr-browser README: connect Playwright MCP to the plugin’s Chrome DevTools Protocol CDP endpoint with --cdp-endpoint . That way, Playwright controls the browser beside the agent instead of opening another one. What cmux does better what-cmux-does-better cmux has the better browser. herdr-browser keeps a Chromium profile for each herdr session, so cookies and logins survive pane and daemon restarts. It cannot reuse the Chrome profile I already use. cmux can import browser data and sessions from more than 20 browsers, so its browser panes open already signed in. The native WebKit view also looks much better. I took these on separate runs and different ports, 8099 and 5173. They show the same login page, but not the same run. cmux’s remote support is good now too. I went back and checked the changelog: the detachable daemon keeps terminals alive across reconnects, and SSH agent forwarding lets remote sessions use local keys without copying them to the box. My original reason for leaving no longer applies. Neither project is finished software. herdr is still pre-1.0. The cmux changelog https://cmux.com/docs/changelog includes a June memory leak that grew the app to 4.4 GB over about 23 hours. An earlier Git search bug pushed memory from about 450 MB past 8 GB and triggered the out-of-memory killer. Why I picked herdr why-i-picked-herdr cmux has the better browser, and it fixed the SSH problem that made me leave. I still use herdr because reviewr is now part of how I work. The multiplexer also runs on the same box as the agents, so I get clickable panes and agent state in the sidebar without moving those sessions into a macOS app. If you work locally on a Mac, pick cmux. If your agents run on boxes you attach to, pick herdr. I work the second way, so herdr is the one I kept. Why not just use tmux? tmux already keeps sessions alive. I use herdr because it marks which panes contain agents and which one is blocked, then lets me jump there from the sidebar. Its plugins also use that agent state. If you run one agent and do not need the status, tmux is enough. Can I run cmux on Linux or Windows? No. cmux is a native macOS app built with Swift and AppKit. It can connect from a Mac to Linux or Windows machines over SSH, but the app runs on macOS. Will my tmux shortcuts work in herdr and cmux? Not automatically. herdr uses Ctrl-b as its default prefix https://herdr.dev/docs/keyboard/ , and some bindings will feel familiar, but its keymap is not tmux’s. cmux defaults to macOS Command shortcuts, though it supports two-step chords https://cmux.com/docs/keyboard-shortcuts so you can recreate the bindings you use. Neither imports your .tmux.conf . If you run tmux inside either tool, give one layer a different prefix so they do not both consume Ctrl-b . I'm on a Mac and work locally. Which should I pick? Pick cmux. It runs natively on macOS, and its browser panes can import your existing sessions. Pick herdr if you want the multiplexer to remain inside the terminal.