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)

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.

Similarity to tmux is the point

I've been dailying this (inside tmux!) for multi-agent orchestration and for state detection for agentic fleet orchestration, it's excellent. Highly recommend!

Can't tell you what it is, brain wired like that or smth.

For me the killer feature is the git worktree management.

But in essence it is tmux on steroid (Specifically for agents)

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.

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

Then I just work through the alerts and handle them as they arrive.

I guess there's an edge case where you don't know if an agent is running in a tab at all (while herdr will show "Agent running") but in practice I'm the one starting agents, and they run until they alert, so I'm not hitting a case where I think an agent is running but it's not.

for the lazy.

Oh wow, that's bad. Copy/paste between terminals is a significant part of my workflow.

Do you know if that's specific to wezterm (my daily terminal emulator) or applicable to any terminal emulator that's using Herdr?

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.

It sets up a bunch of panes for you and tracks your agents' status and everything is clickable. You could probably do much of the same by setting up tmux appropriately. Or you could use this, which is already set up.

I tried herdr today, and it's not bad. Better than my previous many terminal tabs. Copy-and-paste is wonky (and it's ridiculous that copying is documented in multiple places in the docs, but pasting is never mentioned). And when an agent is waiting for a shell command, it shows as "idle", which IMO is wrong. Still, seems OK so far, I'll stick with it for a while.

https://gist.github.com/iaindooley/cc8a61a1ff0fe23526c850906...

You include a script .worktree in your repo that does any copying or symlinking to setup the target directory.

It also has a headless mode so that it does the worktree operations without the tmux which I use for executing pi -p prompts in worktrees.

Can you explain what you struggle to do in tmux with the mouse? I'm using it as we speak and everything is clickable, panes are resizable, right clicking a windows give you a context menu... Not sure what else is missing?

The hitching is compounded for me because I tend to run the agents in squads: the agent I talk to operates a strict no-coding 'producer' mode, it tasks a sub-agent to do the research or coding, then the results go via a file to a critic or review agent; keeps the producer context very minimal and lean. Not convinced it's as necessary as just starting new contexts frequently with Fable etc.

My general rule is that I won't commit code a human hasn't seen/reviewed to production codebases, and I know I won't maintain that rule if I have to read all the slop that gets generated first time round without an AI reviewer pass.

So far my producer skill has survived 4.6 thru fable in succeeding to treat the review/critic output skeptically, as a likely yes-man or team player.

The key is to remember that, as of Fable, the size of the training corpus segment representing people responding to AI-generated content is still relatively tiny. Telling Sonnet 4.6 "this is code an agent produced" has a near decorative effect with no apparent significance, Sonnet 4.8 shows some misgivings, and when I experimented with Fable it seemed to do well at anticipating the kind of slop 4.6 would throw you.

Interestingly, to me, telling Fable that code a previous Fable agent wrote was AI generated seemed to raise some kind of "I'm being benchmarked" flag; expanding the reasoning finds it being evasive and mistrusting; look past the null derefence because this must be a trick question type thing.

I think this is why it's described as "mouse first" terminal.

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).

So for a new worktree the agent can create a tab in zellij with multiple panes, properly named etc.

It works really nicely.

Although since I got the 52 inch Dell monitor I tend to just put everything visible at all once most of the time.

I couldn't click fast enough, then discovered that "Hyper Terminal" has nothing to do with "HyperTerminal" and couldn't click "close tab" fast enough.

How do you manage that? How do you successfully navigate complex merges using ai?

Aside from that, the quality of the project is great. Vibecoded doesn't automatically mean bad.

- 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?

1- https://github.com/dcolinmorgan/herdr-remote Support Cloudflare, Telegram, .. quite buggy to me

2- https://github.com/0cv/herdr-mobile-relay Forked from the original one but improved and usable on phones, however the scope narrowed down to Cloudflare only

I don't think you can avoid those much longer.

You might as well say Herdr runs on 3 billion devices, go all in! 16 billion devices! Every human on earth installed Herdr twice! (source: study amongst users of herdr, n=5)

I generally run a session per project. Then within each session, a window for Claude, a window for running whatever dev server/logs, a window for neovim, and finally a plain terminal window for things like kicking off deploys etc.

Again, you are right about the naming.

I would also say that HyperTerminal is a terminal for Windows. And, you do you! Use what you love, don't use what you don't.

I picked Hyper as a base because it's written in Electron and was cross platform capable. That said, I've changed a LOT in it to match my workflows and it hasn't given me any issues of late. I've literally seen it crash once the entire time I've been running the installed version (dev is a bit different). It's definitely not the same Hyper, is what I'm saying.

You seem intent on your opinion, and have every right to it.

Build on!

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.

But I do have many years of experience working in a larger team and it's the same problem there (just that people want to merge after some days of working). I'm not sure if AI changes the picture much vs working in a team.

Either way one has to plan ahead a bit and select tasks that are not going to trample on each other. I can typically imagine roughly what the code generated is going to be (at least what files will likely be involved in what way) and when selecting tasks to work on I take into account if it's going to likely cause conflicts.

In my experience if different branches work on different things, Claude have no issue doing "trivial" merges where you just ended up changing different aspects of the same lines. Of course, if two branches rewrite the same pieces of code there's a problem -- so don't do that..

echo “resolve conflicts” | runpi

Where runpi is my pi -p wrapper. I’ve never had a regression from it, but it gives me a report at the end so I can double check the decisions if I need to.

The skill is basically don’t use automatic resolvers, err on the side of including both sides, refer to recent commits, missions and runfiles for context and in your report to me use real branch names not HEAD and incoming because I can never remember what those refer to.

So I will start a workspace for each different thing I'm working on, label it "Studio Shed Packet", "Teapot game", "Mux experiment". Then in each one I run a Claude Code. Then I can see the status of my Claude Codes just by glancing at the sidebar, rather than having to switch between screens to see what is waiting next.

I've been using it around a week so far.

(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).

But I think git worktrees are a bit more ergonomic, I don't have to think about local vs upstream there's just one place to push.

I like to organize my projects like this:

    myproject/.repo/git  # bare repository .. my own convention..
    myproject/main       # worktrees from ../.repo/git
    myproject/feature1
    myproject/feature2

Hopefully any of those get some traction

I've seen VCs very much encourage this (and shadier) behavior. There's a line between hustling / being an entrepreneur and actively trying to mislead people... clearly we don't all see that line being in the same place (:

edit: to be clear, I didn't mean to make such a broad statement about VCs. I'm sure plenty of people do this on their own

Anyway, I think multi-session management is a reasonable thing that this thing might improve over tmux, so fair enough.

So, I no longer use worktrees, and just copy and existing/clone a new folder.

I think all my problems go away with jujustu.

Runs agents in tmux in sandboxes.

A lot of this is personal taste but the general thing I get most value from is asking an agent to speculatively build every idea, instead of writing down ideas in some backlog for later (it never happens later).

In practical terms it often means that you can give the agent a ticket and it'll work on it for several hours until the PR is ready. Occasionally it'll run into some question that it needs you to clarify something or make some directional choice, but overall it's pretty autonomous.

Because this takes so long, you normally run 3 or 4 of those in parallel.

Then between shepherding those session, you also run several PR review sessions at the same time. Those also run for quite some time when doing deep investigations.

And then you also have long running discovery/design sessions for various other projects or problems you're working in between.

Claude code exposes a bunch of hooks you can use to have tmux commands execute. This is invaluable if you are multi-tasking and need to see at a glance what needs attention.

Gondolin is sand boxes done right...

Assuming I'm working on one repo, I'll have different worktrees, each for a related area. For example, one worktree for each of: ui, small bug fixes, feature A, feature B, and so on.

Each worktree will have one active write agent, but I have a special docs/plans folder where I can have additional agents doing research and saving their findings. Agents in "plan mode" are write restricted to just that folder.

So look at a bug fix worktree. I could easily have 5 agents doing RCA into various bugs, each in plan mode. One at a time will get promoted to write mode to fix its specific bug while I continue discussion/RCA with the others. After fixing several bugs I'll spin up a "quality pass" agent that will make sure all tests/lint etc. pass and then give me a list of touched surfaces to manually verify before merging the branch and closing the worktree.

Note, I'm working solo at the moment so there's no PRs needed, but it would look quite similar if I had to make a PR for each bug fix, just probably with more worktrees.

Why would you need an agent more than one time to create a script then use one command to launch it? What's the added value of the agent there?

1. Merges in the dev branch

2. runs the various tests and static checks

3. Fixes any small issues with the context of what was fixed on this branch

4. Stops and reports if there's any major issues

Or

5. Handles the merge back to dev if all is green.