herdr gegen tmux: Was der neue Multiplexer wirklich anders macht

tmux ist seit bald zwei Jahrzehnten der Standard, wenn Sitzungen auf einem Server überleben sollen. herdr ist neu, in Rust geschrieben und für KI-Coding-Agenten gebaut. Beide sind Terminal-Multiplexer mit Client-Server-Architektur — der Unterschied liegt woanders.

Das Wichtigste in Kürze

• Gemeinsam: Client-Server-Modell, Sessions überleben das Terminal, Panes, Tabs, Präfix-Tasten.
• herdr kann mehr: Agent-Zustände (arbeitet, blockiert, fertig), Mausbedienung, Agenten-Steuerung per CLI.
• tmux kann mehr: Reife, Verbreitung, Skriptbarkeit, läuft überall.
• Kurz: tmux für Server-Arbeit, herdr für parallele KI-Agenten.

Was beide gleich machen

Ein verbreiteter Irrtum vorweg: tmux hat ebenfalls eine Client-Server-Architektur. Auch dort läuft ein Server im Hintergrund, auch dort verbindet sich ein dünner Client über einen Unix-Socket, auch dort überleben Sitzungen das Schließen des Fensters. Wer behauptet, das sei der Unterschied, hat tmux nicht verstanden.

herdr hat die Präfix-Taste bewusst auf ctrl+b gelegt. Der Umstieg kostet also nicht die Muskelerinnerung.

Wo herdr vorne liegt

1. Agent-Zustände

Das ist der eigentliche Daseinsgrund. herdr erkennt, ob ein Prozess gerade working, blocked, done, idle oder unknown ist, und zeigt das in der Seitenleiste.

In tmux sieht man ein Fenster mit einem Sternchen, wenn sich dort etwas getan hat — mehr nicht. Ob der Agent arbeitet oder seit zwölf Minuten auf ein „ja“ wartet, steht nirgends. Bei einem Agenten ist das verschmerzbar. Bei vieren wird es zum Zeitfresser.

Über zwanzig Agenten sind ab Werk bekannt, darunter Claude Code, Codex, Gemini, Cursor und Copilot. Mit installierter Integration meldet der Agent seinen Zustand sogar aktiv, statt ihn erraten zu lassen:

2. Eine CLI, die Agenten selbst benutzen können

Beide lassen sich skripten, aber mit verschiedener Zielrichtung. tmux schickt Tastenfolgen:

tmux send-keys -t sitzung:0 "make test" Enter
tmux capture-pane -p -t sitzung:0

herdr bietet eine Socket-API mit JSON-Ausgabe und Begriffen, die auf Agenten zugeschnitten sind:

herdr agent list
herdr agent read <ziel>
herdr agent wait <ziel> --state blocked
herdr workspace create --cwd ~/api-service --label "api-service"

herdr agent wait hat in tmux keine Entsprechung: Ein Skript hält an, bis ein Agent einen bestimmten Zustand erreicht. Damit lassen sich Abläufe bauen, die auf mehrere Agenten warten, statt in einer Schleife die Ausgabe abzugrasen.

3. Die Oberfläche ist anfassbar

herdr ist vollständig mit der Maus bedienbar — Panes anklicken, Workspaces wechseln, Trennlinien ziehen. tmux kann das mit set -g mouse on ansatzweise, bleibt aber tastaturzentriert.

4. Projekte statt Fensterlisten

tmux kennt Session → Window → Pane. herdr schiebt eine Ebene dazwischen: Session → Workspace → Tab → Pane → Agent. Ein Workspace ist ein Projekt mit eigenem Arbeitsverzeichnis. Wer an drei Repositories gleichzeitig arbeitet, bildet das sauberer ab als mit durchnummerierten Fenstern.

Wo tmux vorne liegt

1. Es ist überall

Das ist kein Nebensatz, sondern das stärkste Argument. tmux liegt in jedem Paketrepository, ist auf vielen Servern vorinstalliert und läuft auf allem von der Synology bis zum AIX-Host. herdr muss man erst installieren — und auf einem fremden Produktionsserver wird man das selten dürfen.

2. Zwanzig Jahre Reife

tmux ist seit 2007 im Einsatz, die Fehler sind gefunden, das Verhalten in Grenzfällen ist bekannt. herdr steht bei Version 0.8.2 — also noch vor 1.0, mit allem, was das für Schnittstellenstabilität bedeutet. Für ein Werkzeug, das wochenlang laufende Sitzungen hält, ist das ein Unterschied.

3. Ressourcen und Abhängigkeiten

tmux ist genügsam und läuft auch auf dem kleinsten VPS. herdr ist zwar eine einzelne Rust-Binary ohne externe Abhängigkeiten, zeichnet aber eine deutlich reichhaltigere Oberfläche.

4. Ökosystem

Für tmux gibt es den Plugin-Manager tpm, Konfigurationssammlungen wie Oh My Tmux, unzählige Anleitungen und zu jedem Problem einen Treffer. herdr ist neu — das Material muss noch entstehen.

Auf dem VPS

Beide eignen sich, um Arbeit auf einem Server am Laufen zu halten. Der Unterschied zeigt sich im Zuschnitt.

Bei tmux geht man per SSH auf die Maschine und startet dort tmux beziehungsweise tmux attach. herdr kann das genauso, bietet zusätzlich aber einen direkten Weg:

herdr --remote [email protected] --session arbeit

Dabei wandert die lokale Konfiguration mit — Tastenbelegung und Theme bleiben gleich, egal auf welcher Maschine gearbeitet wird. Bei tmux müsste man die .tmux.conf auf jedem Zielsystem pflegen.

Das typische Muster sieht so aus: Die Agenten laufen auf dem VPS mit guter Anbindung und ohne Schlafmodus, man selbst hängt sich vom Arbeitsrechner oder unterwegs daran. Beide Werkzeuge können das — bei herdr sieht man nach dem Wiederanhängen sofort, welcher Agent inzwischen blockiert.

Umsteigen oder kombinieren?

Man muss sich nicht entscheiden. Ein praktikables Modell:

• tmux auf Servern, auf denen ohnehin nichts Zusätzliches installiert wird — für Updates, Migrationen, lange Backups.
• herdr auf der Entwicklungsmaschine oder dem eigenen VPS, wo mehrere Agenten parallel laufen.

Da die Präfix-Taste identisch ist, kostet der Wechsel zwischen beiden wenig.

Fazit

herdr ist kein tmux-Ersatz, sondern ein Spezialwerkzeug. Die Client-Server-Architektur haben beide; der Unterschied ist, dass herdr versteht, was in den Panes passiert.

Wer einen Multiplexer braucht, um auf dem Server etwas am Laufen zu halten, bleibt bei tmux — ausgereifter, überall vorhanden, zuverlässig. Wer drei oder vier KI-Agenten gleichzeitig beschäftigt, gewinnt mit herdr genau die Information, die bei tmux fehlt: wer gerade wartet.

Die Grundlagen stehen in der Einführung zu herdr, der Vergleich mit dem Urgestein unter herdr gegen GNU screen.

Getestet mit herdr 0.8.2 (stable, Protokoll 20) auf Arch Linux.