Saggar vs herdr
Different layers of the same problem. You can run both.
herdr is a multiplexer for coding agents — tmux's idea, rebuilt for the way agents behave. A background server owns the sessions, every pane is marked working, blocked, or idle, and agents can spawn panes and wait on each other through a socket API.
It is Apache-2.0, it runs on macOS, Linux, and Windows, and it has been installed a very large number of times. Its durability is the best of anything on this page: sessions outlive a dropped network, a closed lid, and a restart, and you can reattach over SSH from anywhere.
Saggar is not a multiplexer. It is a Mac app, and it competes on what a Mac app can do that a terminal program cannot.
What herdr does well
- Sessions live in a background server, so agents keep working through sleep, network drops, and reboots.
- Reattach from any terminal, on any machine, over SSH.
- Working, blocked, and idle state per pane, detected rather than guessed.
- Agents drive it directly: they can split panes, start each other, and block until another agent is genuinely stuck.
- Around twenty agent CLIs recognised out of the box.
- Apache-2.0, cross-platform, and free.
Where Saggar takes a different line
- A Mac window rather than a terminal UI: real menus, split panes, search, a command palette, prompt jumping, and themes that follow your system.
- One ordered queue of sessions waiting on you, walked with ⌘J, rather than a status you read off each pane.
- A first-party phone client. Read a terminal, answer its prompt, or interrupt a runaway from a browser, without an SSH session and a phone keyboard.
- A project workspace around the terminals — branch, worktree, dirty files, listening ports, docs, notes, and startup commands, per codebase.
Side by side
YesPartlyNo
| Saggar | herdr | |
|---|---|---|
| Native Mac appA real Mac window with menus, keyboard shortcuts, split panes, and themes — not a text UI or a web view. | Yes. Swift and SwiftUI, built against macOS 26.Swift and SwiftUI, built against macOS 26. | No. A session server and CLI, drawn inside whichever terminal you already use.A session server and CLI, drawn inside whichever terminal you already use. |
| Status without lookingEach session says what it is doing, so you don't read five transcripts to find the one that stopped. | Yes. Needs you, working, idle, finished, or failed, re-read every two seconds.Needs you, working, idle, finished, or failed, re-read every two seconds. | Yes. Every pane is marked working, blocked, or idle.Every pane is marked working, blocked, or idle. |
| One ordered attention queueEverything waiting on a decision, collected in priority order and walkable from the keyboard. | Yes. Prompts, failures, and finished work form one queue. ⌘J walks it.Prompts, failures, and finished work form one queue. ⌘J walks it. | Partly. Blocked panes are called out, and agents can wait on each other through the socket API.Blocked panes are called out, and agents can wait on each other through the socket API. |
| Answer from your phoneRead a terminal and reply to its prompt while you are away from the Mac. | Yes. The Companion runs in any browser. Pair once by scanning a QR code.The Companion runs in any browser. Pair once by scanning a QR code. | No. No first-party mobile client. Community projects fill the gap over SSH.No first-party mobile client. Community projects fill the gap over SSH. |
| Work survives a disconnectAgents keep running when the network drops, the lid closes, or the machine restarts. | Partly. Sessions and scrollback are restored, and idle sleep is held off while work needs you. A closed lid still stops it.Sessions and scrollback are restored, and idle sleep is held off while work needs you. A closed lid still stops it. | Yes. Best on this page. A background server keeps sessions through drops, sleep, and restarts.Best on this page. A background server keeps sessions through drops, sleep, and restarts. |
| Project workspaceBranch, worktree, dirty files, listening ports, notes, and startup commands, kept per codebase. | Yes. Tracked live, and stored in .saggar/ beside the code where agents can read it.Tracked live, and stored in .saggar/ beside the code where agents can read it. | Partly. Worktree and session conventions, driven from the CLI.Worktree and session conventions, driven from the CLI. |
| Works without an accountInstall it and use it without signing in to anything. | Yes. The Mac app needs no account. Sign in only when you want your phone to reach it.The Mac app needs no account. Sign in only when you want your phone to reach it. | Yes. No account needed.No account needed. |
| Open sourceYou can read the code, fork it, and keep it if the company stops. | No. Closed source.Closed source. | Yes. Apache-2.0.Apache-2.0. |
| Runs beyond macOSLinux and Windows, for people who don't work on a Mac. | No. macOS 26 Tahoe or later, on Apple silicon.macOS 26 Tahoe or later, on Apple silicon. | Yes. macOS and Linux, with Windows in beta.macOS and Linux, with Windows in beta. |
Claims about herdr come from its own documentation and were last checked in August 2026. If something here is out of date, tell us and we will fix it.
Which one
Pick herdr
Choose herdr if agents absolutely must survive your laptop closing, if you work on Linux or Windows, or if you want agents orchestrating each other programmatically. Its persistence is genuinely better than Saggar's.
Pick Saggar
Choose Saggar if you work on a Mac and want a supervision surface rather than another thing to attach to — and if answering a prompt from your phone should not mean SSH.
Other comparisons
Saggar vs cmux
The closest comparison on this site, and the hardest one to win.
Saggar vs Warp
Warp rebuilds the terminal. Saggar organises what you run in it.
Saggar vs tmux
tmux is not wrong. It was built before anything in a pane could ask you a question.
Saggar vs an IDE terminal
The panel is fine for one agent. It was never a supervision surface.
Saggar vs Claude Code
Not a competitor. Saggar's whole job is running this well.