Yeah that copy is pretty bad. My understanding (someone correct me if I'm wrong), but the herdr native app is an improvement over the existing TUI multiplexer, with a new API for facilitating comms between agents. Herdr is really useful if you've not tried it. I'll be giving this a go (I hadn't really been using agent comms between panes anyway, more just for workspace navigation). Seems you can think of herdr as a 'harness for your harnesses'!
I can't speak to the GUI, just the TUI compared to tmux.
herdr is very flexible, but it shines when you are working with multiple projects, with multiple worktrees, and multiple agents within those projects.
1. herdr uses workspaces to help organize tabs. Conceptually, a workspace probably maps to a project, but it doesn't have to.
2. herdr has native worktree support, and can create a nested workspace per worktree with a keyboard or CLI command. It can check out worktrees for you
3. herdr identifies agents across tabs and workspaces and pulls them out into an extra navigational pane. It shows the status of those agents (e.g. idle, working, waiting, done), and can play a sound when they change state. This helps you track multiple agents across multiple projects and quickly switch to them when they need help without needing to remember "claude is running in space 2, tab 3"
4. herdr integrates with your agents, which can control herdr's UI and rename tabs based on their status.
5. All this is scriptable via the herdr CLI, and agents are very good at it. But it also has full mouse support, if you're new to multiplexers its very easy to start interacting with it.
I usually keep one tmux session per Python worktree, with a local Postgres test container in another pane. The status view sounds useful here; does Herdr detect waiting via agent hooks or infer it from terminal output?
> What's useful about Herdr compared to tmux and claude code or codex's built in sub-agents?
Agent status detection. Single view over local and remote agents. /herdr skill that lets agents list other agents, peek into their panes, send keys (yes, you can make a lot of it work with tmux and some elbow grease, but herdr provides nice cli/api for it and works out of the box) including to remote ones.
In my mental model, subagents are also different from top level agents in tabs: subagents are only great as temporary workers you never want to interact with.
It also lets you message between Claude Code and Codex sessions. If you're using Claude Code, their built-in messaging system only can see/message other Claude Code sessions (for obv reasons).
This is an unlock, because these companies will (prob) never build this feature.
I think i built something similar after herdr was released but i can say the reason is at least
tmux is definitely usable but moving between workspaces/repos can be annoying if youre managing mahy many things at once. and difficult to organize. more over having agents manage other agents via tmux can lead to garbled input/output
i havent used codex. claude subagents i think arent the right comparison - the closer comparison would be claude managed agents. but i imagine one reason herdr might be better would be that you’re not stuck in the anthropic ecosystem
If you prefer tmux orchestration you could give my plugin a try.
It's just a few bash scripts enabling agents to message each other. Works with the desktop apps as well so you could have a Codex or Claude desktop app orchestrate tmux sessions.
Integrated experience. You can connect to multiple machines and access terminals on them through spaces in the left nav. Agents across all spaces are listed in a dedicated section for quick access.
Each space is persistent contains persistent terminals like tmux, so disconnections do not affect them.
I'm also curious, if you just ask Codex, Claude etc already do subagent management on their own, and if instructed, can certainly set up a structured communication system for the group. Why these Herdr, Pi etc products on top?
Is Codex, Claude Code mismanaging when no tokens left? Or any other specific reason?
> Codex, Claude etc already do subagent management on their own
What about together? Can you reasonably do agent to agent interactions across harnesses? herdr makes that easy.
One of my favorite reasons for using herdr is what I'll call "everything is a pane". Running a new agent? Runs in a herdr pane. sshing into a system? Runs in a herdr pane. Anything that runs in a herdr pane, your agents can interact with. I will often do things like ssh into a system in one pane, and then ask pi in another pane to help me do diagnostics on that system. It never has to try to ssh in directly in the harness with my credentials, it just sends keyboard input to the pane, and reads the content of the pane. I can watch the interactive session as it goes by.
Another workflow that I have sometimes is I'll kick off some work in an agent, and instead of making a new sub agent, I'll actually make a new parent agent if I get worried that it's going down an unnecessary rabbit hole. I'll tell the new agent something like "periodically watch the agent in pane X, it is working on Y but I am concerned that it is losing track of its tasking. Periodically review what it's doing, and make sure it doesn't go off the rails. If it does seem to be going off the rails, give it guidance to bring it back on track" and that seems to have helped.
Subagent spends more tokens. It can be just separate sessions, just a new codex or claude session it doesn't have to be subagents that have to coordinate
It adds some abstractions and a plugin architecture for extensions. I checked it out but ended up not using it. I run my own harness of harnesses over tmux centered around tasks rather than sessions.
I suppose it is just the convenience of having an opinionated app that works with agents out of the box, tmux could be more powerful but similar to vim vs vscode, you need to tune it in.
