How to Run Coding Agents Across Multiple Machines with Herder
A practical guide to Herder's machine mode, showing how to manage and script coding agents across SSH hosts from one terminal.
What is Herder’s machine mode?
Herder is a terminal multiplexer built specifically for coding agents. It tracks whether each agent is working, blocked on a question, or done, and shows that status in a sidebar instead of making you tab through panes. Machine mode, added in a recent update, lets one Herder window manage your local machine and every saved SSH host at the same time, instead of limiting you to one remote connection per session. Agents on different computers show up in a single list, with unified status and notifications.
TL;DR
- Machine mode merges your local session and all saved SSH hosts into one Herder window, so agents everywhere show up in a single sidebar list.
- The herder machine add command registers a new SSH target, detects existing Herder sessions on that host, and uses the SSH hostname as the label automatically.
- The dash-machine flag lets you run any Herder command against a saved machine without opening a Herder window, which means agents can script other agents on remote servers.
- Reconnection is automatic: dropped machines reconnect on their own, failed connections get rechecked every 30 seconds, and
herder machine reconnecthandles passwords or MFA prompts. - Bandwidth got lighter: SSH connections now use compression, pane redraws only resend changed rows, which keeps things usable over slow connections like hotel Wi-Fi.
- Updates no longer kill your agents: a client update can leave a compatible remote server and its running sessions untouched, and replacing a server now requires explicit confirmation.
- Both ends of the connection need to run the same Herder version for dash-machine commands to work, and failed remote commands never silently fall back to running locally.
How do you set up a remote machine in Herder?
You register a remote host with herder machine add, pointing it at an existing SSH target (the same kind of target you’d use with a normal ssh command). Run it interactively and Herder checks the host for any Herder sessions already running there, letting you attach to one instead of accidentally spinning up a duplicate. There’s no need to assign a custom label either: Herder just uses the SSH hostname, which keeps naming consistent if you’re managing several servers.
Once added, the machine appears in the sidebar underneath your local session. Agents running there, whether that’s Claude Code, Codex, or something else entirely, show up in the same agent list as your local agents. If a remote agent gets blocked waiting on an approval, you get the same notification you’d get locally. Each machine also reconnects independently, so if the SSH connection to a server drops, your local agents and panes keep running unaffected.
Keyboard navigation extends across machines too. Moving through the sidebar highlights the target pane before you hit enter, which matters once you’re juggling panes across two or three hosts and don’t want to send a command to the wrong box.
What does the dash-machine flag actually do?
The --machine flag runs a Herder command against a saved remote host without requiring an open Herder window on that host at all. For example, running herder --machine <name> agent list prints the agents running on that server directly into your local terminal, no attaching required.
The more interesting use case is that agents can call this themselves. An agent running on your laptop can invoke a Herder command with --machine to start another agent on a remote server, send it a prompt, wait for the result, and read the output back into its own context. That turns Herder into something closer to a control plane: one agent orchestrating others across machines, scripted through the CLI rather than through a human switching panes.
Two caveats matter here. First, both the local and remote machine need to be running the same Herder version, or the remote commands won’t work correctly. Second, if a remote command fails for any reason, Herder does not fall back to running it locally. That’s a deliberate safety choice: you don’t want a command meant for a production server silently executing on your laptop instead.
How does Herder handle flaky or slow connections?
A few changes specifically target the pain of managing agents over SSH on unreliable networks. herder machine status checks every saved machine without prompting for anything, so you get a quick health check across all your hosts. If a machine needs a password or multi-factor authentication to reconnect, herder machine reconnect lets you complete that login step right in the terminal instead of restarting the whole session. Open Herder clients also recheck failed machines automatically every 30 seconds, so a connection that comes back online doesn’t require any manual intervention.
● Reading src/server.ts
● Editing 3 files
+ import { limit } from 'rate'
- app.use(cors())
✓ Tests passed · ready for PR
On the data side, SSH connections now use compression, and redraws are smarter: typing and switching panes no longer resend the entire screen, and scrolling only transmits the rows that actually changed. For anyone watching an agent stream build logs over hotel Wi-Fi or a slow mobile connection, that’s a meaningful difference in usability. Windows SSH hosts are also now supported as connection targets, which wasn’t possible in earlier versions.
Does updating Herder disrupt running agents?
This used to be a real pain point. Previously, updating Herder could require stopping the server process, which killed every pane and every agent running in it, remote or local. That’s changed: a client-side update can now leave a compatible, already-running remote server and its agents untouched. If the older server is missing a specific feature the new client expects, only that one feature gets disabled rather than forcing a full restart.
If Herder does need to replace a remote server entirely, it asks for confirmation first, and the default answer is no. After running herder update, the tool also tells you which running servers are still on an older version, gives you the exact restart command for each, and reminds you to update any saved machine configs as well. For anyone running long-lived agent sessions on a server they don’t want to disturb, this matters more than it sounds.
How does session persistence work across machines?
Herder now saves session state before a system shutdown begins, rather than risking a session being torn down mid-write. Saves are written to disk and swapped in as a completed file, so a crash or power loss shouldn’t leave you with a corrupted session. The tool also keeps a rolling history of up to 48 layout snapshots in a session snapshots folder, giving you a manual recovery path if something still goes wrong.
On Mac and Linux, closing the shell that originally launched Herder no longer kills the server process. And when a session with many agents restarts, those agents now start one at a time (100 milliseconds apart by default) instead of all at once, which noticeably reduces CPU spikes if you’re running something like 20 agents in one session. That delay is configurable through a startup-per-agent-delay setting.
A related change lets agents report their own state and their own resume command directly to Herder, instead of Herder needing a built-in integration or having to read the terminal screen and guess. After a restart, Herder can run that reported resume command in the same pane and folder, restoring the conversation even for agents it has no dedicated support for.
Is Herder worth it compared to a desktop agent manager?
It depends on your workflow. Herder’s core model is a terminal: every agent runs in a real pane, which means anything that works in a terminal, including brand-new CLI agents that don’t have dedicated integrations yet, works in Herder on day one. That’s valuable if you live on SSH boxes and want one control surface across all of them.
Tools built as desktop apps, by contrast, typically wrap agents in a chat-style interface with diffs, approval buttons, and GUI features like browser integration or taskboards, which suit people who’d rather click through decisions than work in raw terminal panes. The tradeoff is that such tools only support agents they’ve explicitly integrated, so support for very new CLI agents can lag.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
If you’re managing several agents across multiple machines via SSH and want full CLI scriptability, Herder’s machine mode is a solid direct fit. If you want more visual review tooling and don’t want to deal with SSH hosts at all, a GUI-first option may suit you better. Using both isn’t unreasonable either: long-running jobs on a server through Herder, day-to-day review work through something else.
Frequently Asked Questions
What is the difference between Herder’s machine mode and its earlier remote mode?
Earlier versions of Herder supported one SSH connection per session: a single client connected to a single remote host. Machine mode allows one Herder window to manage the local machine and multiple saved SSH hosts simultaneously, with all agents across them appearing in one unified sidebar.
Do I need the same Herder version on every machine?
Yes. The dash-machine flag and related remote commands require both the local and remote machine to run the same Herder version. Mismatched versions can prevent remote commands from working correctly.
Can an agent control another agent on a different machine?
Yes. Using the dash-machine flag, an agent running locally can invoke Herder commands to start another agent on a remote server, send it a prompt, wait for completion, and read the result back, enabling basic agent-to-agent orchestration across machines.
What happens if a remote command fails?
Herder does not fall back to running the command locally if the remote target fails. This is intentional, so a command meant for a specific server never ends up executing somewhere unintended.
Does updating Herder stop my running agents?
Not necessarily anymore. A client update can leave a compatible, already-running remote server and its agents untouched. If the server genuinely needs replacing, Herder asks for confirmation before doing so rather than restarting it automatically.
