Once you get it set up, Emacs is a pretty damn good "agent" multiplexer as well. I use agent-shell with Projectile on Doom Emacs as my main workflow these days, and it works very well even if I have 6 projects open or whatever.<p>Claude and Codex are also both quite good at working with Emacs as well. Depending on your isolation/sandboxing strategy, they can either run commands against your session via emacsclient (a bit scary) or dump elisp in the REPL for you to evaluate. Both are really efficient in terms of giving you a fast feedback loop.
The utility is not obvious, but I've been using herdr for a few weeks after a friend recommended it, and it's been a great tool.<p>I had about a dozen different terminal windows, each one with multiple tabs, which was becoming a mess to manage; multiple agents and harnesses running that I could only inspect by remote access/VNC away from home.<p>With this, I can keep things more organized (project workspaces, tabs), because it's backed by a persistent process, I can ssh into the machine, with tailscale, run <i>herdr</i> and see all active sessions, do some debugging and one-off prompts.<p>Even better, I can do that from my phone and iPad using Prompt/Termius. It gives me the best part of 'xxclaw' harnesses with none of the complexity.
Will people really need a bunch of different agents?
Even using two codex session for different project make me feel a bit overwhelmed, or may be i just old
I found that a good tool helps a lot once I switched to Github Copilot app. It solved the friction and mental tax for me. I easily manage 4 sessions in parallel on same or different projects while 2 was max in the past. The bottleneck now is only in review and decision making.
I often have many active. Bug investigations, writing code, reviewing, checking logs after deploys and so on.
Same. I haven't been able to see how people let agent loops run without significant steering and produce good quality software. VS Code with one or two integrated terminals running is fine for me. Or a couple of VS Code instances if I'm working one a couple of projects concurrently. The advantage of VS Code is the code / diff visibility if you like to be hands on.
yeah I also don't really see a use case for me, like do ppl really run that many agents in parallel that they cannot comfortably multiplex them using just a terminal emulator
Getting a lot of flack in all these comments, I really like this tool. Have been super easy to use and scale to multiple agents. I've had a ton of issues with tmux and copy and paste, this just works. I was using warp terminal, and even working on my own fork of it with it's recent open source status, but this has won me over.
I switched from tmux to Zellij a while back, and lately added a stop hook that sends a terminal ping to the correct tab when the agent is done (and I'm not looking at the tab). It has been pretty convenient so far.<p>Added an example here:<p><a href="https://johnny.chadda.se/zellij-stop-hook/" rel="nofollow">https://johnny.chadda.se/zellij-stop-hook/</a>
How does it compare with <a href="https://github.com/agent-of-empires/agent-of-empires" rel="nofollow">https://github.com/agent-of-empires/agent-of-empires</a>
How do people use terminal multiplexers together with vim?<p>Ctrl+B is so hardwired in my fingers for scrolling back one screen that there's no way I'm remapping that one in vim itself. So then you have to remap that in your terminal multiplexer, while at the same time there's a bunch of people saying never change the leader key...<p>Curious what vim users especially do about this?
I'm using tmux + zoxide+ <a href="https://github.com/joshmedeski/sesh" rel="nofollow">https://github.com/joshmedeski/sesh</a>. Then on Ghostty, I have keybinds for my workflow. Cmd+k to open/switch workspace. Each workspace is just a new tmux session.
I use tmux with vim and configure it to use Ctrl-a. Not for vim, but because I started with GNU screen that used this key. For the cases when I need actual Ctrl-a, tmux is configured to send it when I do “Ctrl-a a”.
><i>Ctrl+B is so hardwired in my fingers for scrolling back one screen that there's no way I'm remapping that one in vim itself.</i><p>Give it a month and whatever you remapped will be "hardwired" too.<p>In any case, no reason to keep Ctrl-B in tmux either, you can remap that just as well.
As a vim user, I just remap C+B to C+A. It's much easier on the fingers too. Issue arises when I ssh somewhere that doesn't have the leader remapped but that's usually pretty rare when I have to vim in a tmux session on a remote host so not really an issue
does it support a setup where each agent can be in a different SSH session? or must they all run in the same place.<p>it seems to support running a remote herdr over SSH but unclear if it can add remote agents (each agent has its own sandbox where its installed and you first SSH into it and then start the agent there)
Each work pane gives you a new terminal session, you can ssh into a remote and it will be kept alive. Should work fine.
Same question.<p>I usually have one local clause orchestrating multiple remote Claude in different tmux . And then another orchester and remote vm worker sin tmux for another repo etc...<p>It gets a bit hard to keep the overview but I don't want to give up my parallelism, your too might help
afaik, you should be able to use named session to achieve this: <a href="https://herdr.dev/docs/persistence-remote/" rel="nofollow">https://herdr.dev/docs/persistence-remote/</a>
This is way to complex... Why don't just use some harness which manages all that and give u a good UI?
I have been actively searching for such a thing for months without finding it.<p>Some are OS X only.<p>Some will not work well with VMs/isolated agents.<p>Currently using emdash, which is going in a great direction but somewhat new and buggy still.
Nimbalyst does a pretty good job. Some gaps but I can manage multiple agents across multiple projects well enough.
What is your top chart? I am using GUI harnesses from model providers and not happy with any of them.
for example…?<p>I don’t believe any current harness offers this level of organization and running bare shell sessions inside.
nice, not dissimilar to what i built for <a href="https://github.com/storozhenko98/beehive" rel="nofollow">https://github.com/storozhenko98/beehive</a>
I'd suggest adding a few screenshots on the Github README, otherwise I wouldn't have enough attention to imagine how it looks. I had to go to the website to appreciate your work, otherwise I'm like "what is it?"
How do you use multiple agents in one project? Isn't there race conditions? or is this for 2 separate projects at once?
Tried this for a couple days, but conductor.build is way better IME. Running _in_ the terminal is a flex, but doesn't actually bring any advantage.
I was just looking at conductor and was not very jazzed about the fact that it was running the agents directly on the host. Being able to launch from a terminal means this one can (hopefully) run from inside the sandboxing setup I use for coding agents.
Running in the terminal means I can access it via ssh on my phone (& tailscale). Do any of the other solutions let you do this?
mac only. closed source.
conductor.build is Mac only ..
I need a shepherd for my terminals.
At least one of us needs to up our dosage.
Just use tmux no?
[flagged]