Herder 0.9.5: What's New for Running Coding Agents Across Machines
Herder 0.9.5 adds multi-machine SSH support, faster reconnects, reboot-proof persistence, and agent self-reporting. Here's what changed.
What is Herder, and what changed in 0.9.5?
Herder is a terminal multiplexer built specifically for running coding agents, similar in spirit to tmux but aware of what each agent is actually doing: working, blocked on a question, or finished. Version 0.9.5 is the latest in a run of fast updates (0.9.2 through 0.9.5 shipped within days of each other) that add multi-machine management, quicker SSH reconnects, crash-safe session persistence, and a way for agents to report their own status instead of Herder guessing from the screen. The project has close to 49,000 stars on GitHub and describes itself as “the runtime your coding agents live on.”
TL;DR
- Multi-machine mode lets one Herder window manage your local machine and every saved SSH host at once, showing agents from all of them in a single sidebar list.
- The new dash-machine flag runs any Herder command against a saved remote host without opening a Herder window, which means an agent on one machine can launch and monitor an agent on another.
- Client-side rendering moves the terminal UI into each connected client rather than the server, so two devices attached to the same server can watch different workspaces independently.
- Update safety means a client update no longer has to kill the server and every running agent pane; Herder now asks before replacing a remote server and tells you which servers still need restarting.
- Persistence improvements save session state before a reboot or shutdown, write saves atomically to avoid corruption, and keep up to 48 layout snapshots for manual recovery.
- Agent self-reporting lets any agent tell Herder its own state and resume command, removing the need for Herder to maintain built-in integrations for every new coding agent.
- Several quality-of-life fixes address CPU usage with many panes, stray escape characters interrupting agents, and multi-key prefix support.
How does multi-machine support work?
Before this update, Herder’s remote mode tied one client to one SSH host for the entire session. That meant juggling separate windows if you worked across a laptop, a desktop, and a dev server.
In 0.9.5, a single Herder window tracks your local machine plus every machine you’ve saved via herder machine add. Running that command against an SSH target adds the host to the sidebar, right under “local.” If Herder detects a session already running on that host, it offers to attach to the existing one instead of starting a duplicate. Hosts no longer need manual labels either; Herder just uses the SSH hostname.
The agent list merges everything into one view. An agent running Claude Code locally and one running Codex on a remote server both show up together, with the same notifications when either one gets blocked waiting for an approval. Each machine reconnects independently, so a dropped server connection doesn’t interrupt local work. Keyboard navigation moves across machines in sidebar order, highlighting the target before you press enter, which helps avoid sending a command to the wrong box by accident.
On the connection side, herder machine status checks every saved machine without prompting, and herder machine reconnect handles logins that need a password or MFA directly in the terminal. Clients recheck failed machines automatically every 30 seconds. Windows SSH hosts are now supported, and SSH connections use compression; typing and pane switches no longer resend the full screen, and scrolling only transmits the rows that changed. That bandwidth work matters if you’re streaming build logs over a weak connection.
What is the dash-machine flag for?
The --machine flag lets you run any Herder command against a saved remote host without opening a Herder window at all. For example, herder --machine <name> agent list returns the agents running on that server directly in your local terminal.
The practical use case is agent-to-agent orchestration: an agent running on your laptop can use this flag to start another agent on a remote server, send it a prompt, wait for a response, and read the output back, all without a human opening a second session. Both machines need to be running an updated version of Herder for this to work, and if a remote command fails, Herder does not fall back to running it locally. That’s a deliberate safety choice to avoid accidentally running a remote-intended command on the wrong machine.
How does client-side rendering change multi-device use?
Herder moved the terminal UI rendering into each client rather than running it on the server. The visible effect is that multiple devices attached to the same server can now look at different workspaces and tabs simultaneously. A laptop can stay on a front-end project while a desktop watches backend agents running on the same remote box. Each client keeps its own theme, menus, and copy mode, so changes on one screen don’t affect the other.
Why does the update process matter now?
Auditable. Scalable.
Previously, updating Herder often meant stopping the server, which killed every pane and every agent running in it, a significant problem for anyone running long agent sessions. In 0.9.5, a client update can leave a compatible server and its running agents untouched. If the server is missing a feature the new client expects, only that specific action gets disabled rather than forcing a full restart. If Herder determines a remote server genuinely needs replacing, it asks first, and the default answer is no. After running herder update, it reports which running servers are still on an older version, gives the exact restart command for each, and reminds you to update saved machines too.
What’s new in session persistence?
Persistence is one of the more invisible but consequential updates. Herder now saves session state before the operating system starts closing apps during a restart or shutdown, so agents come back in their prior state. Saves are written to disk and swapped in atomically, which prevents a crash or power cut from leaving a corrupted session file. Herder keeps up to 48 layout snapshots in a session snapshots folder as a manual recovery option. On Mac and Linux, closing the shell that launched Herder no longer kills the server, and if the system runs low on processes or threads, the server stays up rather than taking every pane down with it. When a session restores, agents now start one at a time (100 milliseconds apart by default, configurable via the startup_per_agent_delay setting), which reduces CPU spikes when restoring sessions with many agents at once.
What does agent self-reporting add?
Previously Herder needed either a built-in integration for a given coding agent or had to read the terminal screen and infer status. The new approach lets an agent report its own state directly, via a documented process referred to as adding Herder support to an agent. An agent can tell Herder it’s working, blocked, or idle, and supply the exact command needed to resume its session. After a restart, Herder reruns that command in the same pane and folder, restoring the conversation without requiring built-in support for that specific agent.
This shifts Herder’s model from maintaining integrations for every agent to letting agents integrate themselves, which is the core of its “runtime” positioning. Detection for Muse and additional agents was added in this release, along with status-reporting fixes for Claude Code, Codex, OpenCode, Antigravity, Grok, and Kiro, among others.
Is Herder worth using over Panda Code?
The two tools solve different problems. Herder is a terminal: every agent gets a real terminal pane, so anything that runs in a terminal works, including agents that don’t exist yet. Panda Code is a desktop app that talks to specific supported agents (Claude Code, Codex, Kimi Code, OpenCode, GLM) through their own interfaces and shows each as a chat thread rather than a raw terminal.
For multi-machine work, Herder relies on SSH; Panda Code has an opt-in multi-machine mode plus a serve command for running on a spare machine, and cloud sandbox options for single long tasks. For status and approvals, Herder shows raw terminal state (or now, self-reported state); Panda Code renders approvals as buttons and cards. For persistence, Herder restores actual terminal sessions after a reboot; Panda Code saves conversations in a local database and can resume automatically once a usage limit resets.
If most of your work happens in a terminal, across SSH boxes, or with agents that lack dedicated app support, Herder is the stronger fit, especially with these reliability updates. If you’d rather review diffs, run multi-agent teams, and click through approvals in a GUI, Panda Code fits better. Using both isn’t unreasonable: long-running jobs in Herder on a server, day-to-day review in Panda Code on a laptop.
Frequently Asked Questions
What version is Herder currently on, and how mature is it?
Herder is on version 0.9.5 and has not yet reached a 1.0 release. Recent versions have shipped rapidly, with 0.9.2 through 0.9.5 released within days of each other, and some regressions (like Codex status detection) appearing and needing manual fixes as a result.
Does Herder work with agents it doesn’t officially support?
Yes. Because every agent runs in a real terminal pane, Herder can run any CLI-based agent. The new self-reporting system also lets agents provide their own status and resume commands without Herder needing a dedicated built-in integration.
Do both machines need to be updated for multi-machine features to work?
Yes. The --machine flag and cross-host agent orchestration require an updated version of Herder on both the local and remote machine. If a remote command fails, Herder does not fall back to running it locally.
What happened with Codex support in 0.9.5?
Herder stopped installing Codex turn hooks to remove a startup warning, which means Codex status is now read from the screen again rather than reported directly. Users need to run herder integration install codex to restore more accurate status tracking.
Is Herder a replacement for Panda Code?
Not exactly. Herder is a terminal-based runtime for any agent, while Panda Code is a GUI app built around specific supported agents with features like diffs, task boards, and agent teams. Many users run both depending on the task.
