I wanted to mention that `zmx` is a beautiful piece of minimal software that basically has gotten rid of my tmux and zellij use. Uses a ghostty-based terminal emulator for each session, supports pretty much all of these features by leveraging ghostty. I truly don’t see the benefit of something like herdr over this minimal, robust setup. If I really wanted a lot of customization for AI assistants, I’d consider using Orca, but my current zmx approach works OOB and it’s solid. Great software!
Thank you for mentioning zmx. Reading through their repo, it’s like someone read my mind, took my instinctive, almost pre-verbal, half-formed/quarter-baked preference for `screen` over `tmux`, beautifully and precisely formalized it into an actually lucid opinion, and then instantiated it as an actually real piece of software. I’ve used it for an hour and it already feels like second nature; I somehow have muscle memory for features that I didn’t even know it had until I instinctively used them and they were right where I expected them to be. Seriously, thank you.
My pleasure. Make sure you check out the thriving ecosystem of tools around it as well. I’ve seen a few projects building on it in a prettt creative way.
I really want to like this. Ideologically I'm on board. Who wouldn't want to avoid all this multiplexing complexity and pitfalls? But deferring the window management to the OS sounds great in theory, but in practice it falls short (at least for me).
I work on both MacOS and Linux. Even if I were to figure out a perfect window management approach, I'd have to do it twice, and then figure out a way to "attach" to a layout of windows essentially. And then make it cross-platform... or live with zero organization, or at best some kind of flat structure. That's a immediate non-starter. Even if I focused only on a single OS, I still don't consider this a viable approach. It would be like removing browser tabs, and saying let's let the OS manage all this nasty UI stuff.
So then the next immediate idea is let's just have the Terminal itself manage UI. Ghostty supports tabs, splits etc. Great. But if I need to restart Ghostty for whatever reason, my entire layout vanishes and I have to set it all up again?
For me tmux is not just about the attach/detach part. A session is a personal "layout" of the workspace I've organically landed on for this task. Maybe it's a few windows with splits. Maybe it's just the single window with or without a split. Maybe it's a more browser-like just X amount of windows (tabs). If/when things get overwhelming I branch off into a new session for one (or more) sub-tasks. Little fzf-based utilities allow for nice fuzzying over sessions and what not. Or maybe you just run the different sessions in actual different physical OS windows. You can mix and match however you feel that day.
So if I'm in project x, working on feature y, and I detach and walk over to my other computer I can SSH over and continue as if nothing at all changed and retain the exact layout of what I was using before. Simultaneously in another physical window (or a tab) I can just switch to another local (or not) session and instantly be mentally in a different context, working on a different project or feature. Or I can SSH into a server and resume a debugging session left (intentionally) open for a while (which may consist of a few splits/windows/what not).
Maybe I'm missing something. I'm curious how your day-to-day workflow looks like. I imagine if I was 100% bound to a single machine, I could make it work with a tiling wm. But even then Ghostty crashes or something else happens and poof your entire work layout is gone and needs to be re-created (even if the individual pieces are safe).
If you do most of your work on a central server and treat your other devices as thin clients, then (afaik) Tmux/Zellij are the way to go – not to mention if you want to multiplayer with colleagues.
(I know Wezterm has remote session multiplexing in beta, but I’d be surprised if you can re-attach from a different machine.)
Lately I’ve been experimenting with embracing the total scriptability of my favorite terminal, Kitty. Its creator is famously outspoken about non-native multiplexers, precisely because of the pitfalls you mentioned and because they hold back the terminal ecosystem.
Couple of recent issues I’ve had: washed-out colors in Claude Code, desktop notifications not passing through, scrollback weirdness, and image protocol mismatches.
I used to treat Zellij as an OS to build my own IDE in. Now it’s Kitty.
I save layouts as a Kitty session. Important limitation: this doesn’t persist running processes. And so enter zmx. Whenever I need a process I can reattach to I wrap it in zmx.
A terminal agent can interact with the kitty cli to create splits and such. I’m still on the fence as to whether that’s safe. Probably not. Also, tmux is likely better represented in the training data. Currently experimenting with running claude inside tmux (multiplexing) inside nono (sandbox).
Niri is a perfect window manager approach, in my opinion. I don’t need tmux. Just Niri + Foot (terminal) and it’s perfect for the way my brain works. If you haven’t tried it, I highly recommended it.
Huh. The person you're replying to specifically mentioned they connect to the same tmux session from different computers. Niri is great, but how's it relevant here?
seamlessly jumping from local to remote sessions is something ive been hoping for in zellij for quite a while so if herdr supports this it could be interesting.
Until I try it, though, I don't think I'll understand why it needs a specific feature for running an agent tool in a side panel, which is appartently one of it's main selling point.
From what I can figure it is actively calling itself a multiplexer, so pretty closely linked to something like tmux (one of the review videos on the page calls it a "tmux rewrite").
But they seem to be targeting very different scopes use wise.
I think if you use this to do stuff like, edit files, run htop, drop into an interactive shell, compile some code, my guess is you're gonna be fighting uphill and have a bad time.
On the other hand, if you're only using tmux so that you can have a bunch of terminal windows for agents. Then this is probably going to make your workflow a fair bit smoother.
What? Do y'all even try it before saying things like this?
I use it primarily as a replacement for tmux to do terminal stuff, not use agents. It's awesome. It worked out of the box, has actually good, working mouse support, quickly ships fixes, and the defaults are sane with obvious behaviors represented in an intuitive TUI.
I haven't tried it (I thought my comment made that clear, but sorry if it didn't). I definitely did look at the page and watch some of the videos though. Maybe I'm missing something but to me:
- It describes itself early in the page as an "Agent multiplexer" (not a terminal multiplexer)
- It describes itself in the videos as "tmux for agents" (again, suggesting that it's designed for use specifically for agents, rather than as a general purpose multiplexer)
- The "compare" page of the website box is focused extremely heavily on integration with agents
Sorry if I'm coming across as snarky, but your reply seems to be making out that I didn't read any of the content and just made a drive by "this seems to be designed for integration with agents, rather than as a general purpose mutliplexer" comment without any research - but that's literally the entire sell of this project as far as I can see? I'm not arguing you wouldn't be able to use it as a general purpose multiplexer, but that clearly isn't their intention, and the web page and associated videos and content make that really clear.
Are you seeing anything on the website at all that does suggest they have the use case of "general purpose multiplexer" in mind?
Yeah, I use tmux all day. Technically great, but the UX for tmux smux.
You end up having to wrap everything in adapter scripts because it is so verbose as well as so unmemorable, along with that, it has no built in help, not even -h
Would usuability (for what herdr is optimized for) not be the bigger use case for users?
I never heard of this project but in 5 minutes I got the features that I wanted without having to introduce muscle memory. I just wanted a dead simple way to point and click to select different terminals. The only thing I neeed to remember now is "ctrl-b + v" to create a new pane.
I also quite like that it has a decent CLI and skill for agents to use too.
Quite handy to apply since you can instruct models to run devservers in herdr panes or workspaces rather than doing long running shell commands or scripts in the agent session.
(You could probably do the same with tmux and others but I've had better success with monitoring herdr state)
I think that just enables xterm mouse support, and allows for various mouse key bindings in tmux. I think the deal is that it's turned on by default, and lots of the UI elements by default are configured with mouse bindings. Not just selecting and resizing panes, you can right click on a pane or a workspace and one of those display-popups pops up with a "rename" dialog box.
I think this is why it's described as "mouse first" terminal.
I've been dailying this (inside tmux!) for multi-agent orchestration and for state detection for agentic fleet orchestration, it's excellent. Highly recommend!
The example I saw of "mobile support" was connecting via a mobile terminal emulator. I don't see how that is any different than using tmux with the same mobile terminal emulator.
Herdr supports mobile-friendly layouts seamlessly, just like responsive web pages. On a narrow terminal, the sidebar is automatically hidden, and the tab bar is replaced with a status line (current workspace name, current tab name, and agent statuses). Everything else is tucked into the hamburger menu.
- everything is mouse clickable
- tmux style display-popups are used for friendly UI interactions everywhere
- it has a UI for agents running in panes, with a cool status (idle/working) display
- has opinionated defaults like automatic clipboard copy on mouse text select
- makes nested sessions easier & has default affordances for remote SSH attach
- is generally prettier
- uses display-popups for notifications
Otherwise it seems exactly like tmux.