I've been using tmux historically and it eventually became too cumbersome since my typical workflow started being a lot more AI-agent heavy. I now run over 10 agents at the same time and they're all working on some multi-hour workstreams that I occasionally need to check in on or unblock. Tmux was not making this particularly easy and I would occasionally lose an agent or forget about it until much later only to realize it's been sitting idle waiting for me to approve something for a few days.
I've tried Cmux, but it didn't do it for me, since the agent statuses were displayed on the workspaces and having multiple agents in the same workspace would sometime produce confusing results.
I've been using Herdr since the start of the week and so far it's been the best in terms of visibility of what my agents are doing and which of them need attention. The only wart I've noticed so far is that the performance is not always great — sometimes I see the text appearing with a noticeable delay as I type it.
In a multi-pane tabbed interface like cmux (I made my own), I found it sufficient for agents to always alert when they are done or awaiting my input, and then the tab shows a badge that counts the number of unacked alert panes inside it.
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.
I've been using cmux for a long time too but am pretty happy with it. It's not perfect but much better than plain tmux/ghostty. I'll give herdr a shot too.
Take a look at zellij as well
I thought that was where I was going to end up, but that's where Claude's remote control or copilot's agents tab spared me.
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 wish Claude's remote control sessions were longer running. If I forget about a conversation it's been cognitively difficult for me to track down which tmux tab = the correct remote control session in the Claude GUI. Remote control does come in super handy for pasting images in when some shell environments where pasting doesn't work for...reasons. The output in the GUI is also so much easier to read.
Curious, are you using the 10 agents for personal projects or for work?
Work.
What's an example of what the 10 agents would be doing in parallel? I've never used more than 2 in parallel before.
We have a skill that takes a well defined Jira ticket and basically drives it to completion until it produces a human-review ready PR. This process is coded into a bunch of gates that the agent needs to clear before it can advance to the next stage, like fully understanding of the context/problem, fully solidified design (or several), implementation, critic review, submit PR, address CI issues and automated review comments etc.
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.
Not the above person, and I usually max out around 5 although I have definitely had 10 or more at some point.
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.
> I'll spin up a "quality pass" agent that will make sure all tests/lint etc. pass
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?
The quality pass:
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.
Some tasks could take a while, especially with /goal mode. At work we often have multiple agents running on different tasks, and each could spawn subagents that you may or may not want to track. With the herdr skill you can have subagents be managed via tabs or panes, which gives them more visibility and could also explode your terminal :)
Lower-priority backlog items. TODOs atop your new PRs. Code reviews. Exploratory work where you can discuss a design sync and then dispatch one or more agents to prototype async. Any workstream where you can define a loop and let the agent hill-climb towards the goal.
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).
Say you have something easily paralelizable, like 150 decompiled binaries, and you want to produce documentation for what each does. You can run 50 subagents in parallel (eg. kimi swarm) to analyze it all in a few minutes in 3 batches instead of doing it serially which would take half a day.
i created a little calude hook that updates the status bar