herdr: der Terminal-Multiplexer, der weiß, was deine KI-Agenten tun

Wer mehrere KI-Coding-Agenten gleichzeitig laufen lässt, kennt das Problem: In Fenster eins wartet Claude Code seit zehn Minuten auf eine Bestätigung, in Fenster zwei ist Codex längst fertig, und man merkt es erst, wenn man durchklickt. herdr löst genau das — ein Terminal-Multiplexer, der den Zustand der Agenten kennt und ihn in einer Seitenleiste anzeigt.

Das Wichtigste in Kürze

• Was: Terminal-Multiplexer in Rust, speziell für KI-Coding-Agenten.
• Kernidee: Er erkennt, ob ein Agent arbeitet, blockiert, fertig oder untätig ist.
• Architektur: Client-Server über Unix-Socket — Sessions überleben das Schließen des Terminals.
• Remote: Läuft auf dem VPS, Bedienung per SSH oder mit --remote.
• Steuerbar per CLI, damit auch durch Agenten selbst.

Installation

herdr kommt als einzelne Rust-Binary ohne externe Abhängigkeiten:

curl -fsSL https://herdr.dev/install.sh | sh

Unter Arch-basierten Systemen geht auch der Weg über den AUR-Helfer, unter macOS Homebrew, dazu mise und Nix. Aktualisiert wird mit herdr update, umgeschaltet zwischen stabilem und Vorschaukanal mit herdr channel set preview.

Grundsätzlich gilt: Ein Installationsskript aus dem Netz direkt in die Shell zu pipen, sollte man sich bewusst machen. Wer das nicht will, lädt das Skript herunter, liest es und führt es dann aus.

Gestartet wird mit dem nackten Befehl:

herdr

Die Client-Server-Architektur

Das ist der Teil, der herdr von einem normalen Terminal unterscheidet — und der Grund, warum sich das Werkzeug für Arbeit auf dem VPS eignet.

Beim ersten Start passieren zwei Dinge: Ein Server legt sich als Hintergrundprozess an und übernimmt die echten Terminal-Prozesse. Dazu verbindet sich ein Client, der nur Eingaben entgegennimmt und die Ausgabe zeichnet. Beide reden über einen Unix-Socket:

$ herdr status
client:
  version: 0.8.2
  channel: stable
  protocol: 20

server:
  status: running
  version: 0.8.2
  protocol: 20
  compatible: yes
  socket: /home/dr/.config/herdr/herdr.sock

Im Prozessbaum sieht man beide Teile getrennt:

$ pgrep -a herdr
318674 herdr
318679 /usr/bin/herdr server

Die Konsequenz ist entscheidend: Wenn der Client verschwindet, laufen die Prozesse weiter. Man kann das Terminalfenster schließen, den Laptop zuklappen oder die SSH-Verbindung verlieren — der Agent im Pane arbeitet weiter. Beim nächsten herdr hängt man sich wieder an denselben Zustand.

Das Protokoll wird dabei versioniert (protocol: 20) und auf Verträglichkeit geprüft. Nach einem Update meldet herdr status unter restart_needed, ob der Server neu gestartet werden muss.

Sessions, Workspaces, Tabs, Panes

herdr staffelt die Hierarchie feiner als tmux. Von außen nach innen:

Sessions lassen sich auflisten und gezielt ansteuern:

$ herdr session list
name       status   directory                 socket
default    running  /home/dr/.config/herdr    /home/dr/.config/herdr/herdr.sock

$ herdr session attach arbeit

Praktisch trennt man damit Kontexte: eine Session für die Arbeit, eine für private Projekte — jede mit eigenen Workspaces, die sich nicht in die Quere kommen.

Der eigentliche Punkt: Agent-Zustände

herdr erkennt, was der Prozess in einem Pane gerade tut, und ordnet ihn einem von fünf Zuständen zu:

blocked ist der Grund, warum es dieses Werkzeug gibt. Wer drei Agenten parallel laufen lässt, verliert sonst genau dort Zeit: Einer wartet auf ein „ja, weiter“ und niemand merkt es.

Die Zustände stehen auch der Kommandozeile zur Verfügung:

herdr agent list
herdr agent explain <ziel> --json
herdr agent wait <ziel> --state blocked

herdr agent wait ist dabei der interessanteste Befehl: Ein Skript kann blockieren, bis ein Agent einen bestimmten Zustand erreicht — damit lassen sich Abläufe bauen, die auf mehrere Agenten warten.

Unterstützte Agenten

herdr kennt über zwanzig Agenten ab Werk, darunter Claude Code, Codex, Gemini, Cursor, Copilot, Devin, opencode und Qwen. Die Erkennung läuft zunächst über die Prozessbeobachtung. Zusätzlich lassen sich Integrationen installieren, mit denen der Agent seinen Zustand selbst meldet, statt ihn erraten zu lassen:

herdr integration install claude

Das ist spürbar zuverlässiger als die reine Prozesserkennung und bringt bei Claude Code zusätzlich die Wiederherstellung der Sitzung mit.

Steuerung über die Kommandozeile

Fast alles, was sich klicken lässt, geht auch per Befehl über den Socket. Workspaces zum Beispiel:

herdr workspace create --cwd ~/api-service --label "api-service"
herdr workspace list
herdr workspace focus w2

Und ein Agent lässt sich direkt in einem bestehenden Pane starten:

herdr agent start claude --kind claude --pane w2:p1

Der Clou daran: Diese CLI steht den Agenten selbst zur Verfügung. Ein Agent kann sich ein weiteres Pane aufmachen, dort einen Befehl ausführen und dessen Ausgabe programmatisch zurücklesen — über herdr pane read beziehungsweise herdr agent read. Damit wird der Multiplexer vom Anzeigewerkzeug zur Arbeitsumgebung, in der sich Agenten selbst organisieren.

herdr denkt diesen Fall sogar explizit mit: Die Hilfeausgabe enthält einen eigenen Abschnitt, der sich an KI-Agenten richtet und auf herdr --skill sowie eine maschinenlesbare Dokumentation verweist.

Remote und VPS

Hier zahlt sich die Client-Server-Trennung aus. Es gibt zwei Wege:

Der klassische: Per SSH auf den Server, dort herdr starten. Die Session bleibt dort bestehen, auch wenn die Verbindung abreißt. Beim nächsten Login hängt man sich wieder an.

Der direkte:

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

Dabei wird die lokale Konfiguration mitgereicht — Tastenbelegung und Theme bleiben also gleich, egal auf welcher Maschine die Agenten tatsächlich laufen.

Das ergibt ein sehr praktisches Muster: Die Agenten arbeiten auf einem VPS mit guter Anbindung, man selbst hängt sich vom Arbeitsrechner, vom Laptop oder notfalls vom Telefon über SSH daran. Läuft ein Auftrag über Stunden, macht man einfach den Deckel zu.

Bedienung

Die Präfix-Taste ist ab Werk ctrl+b und damit identisch zu tmux. Eine Übersicht der aktiven Belegung zeigt prefix+?. Konfiguriert wird in ~/.config/herdr/config.toml mit Abschnitten für Tasten, Theme, Oberfläche, Terminal und Updates. Nach Änderungen genügt:

herdr server reload-config

Ein Unterschied zu den Klassikern fällt sofort auf: Die Oberfläche ist vollständig mit der Maus bedienbar. Panes anklicken, Workspaces wechseln, Trennlinien ziehen — das ist kein Dogma-Bruch, sondern schlicht praktisch, wenn man ohnehin in einem grafischen Terminal sitzt.

Für wen lohnt sich das?

Ja, wenn du regelmäßig mehrere KI-Agenten parallel laufen lässt und auf mehreren Projekten gleichzeitig arbeitest. Der Zustandsüberblick ist genau dann bares Geld wert.

Eher nicht, wenn du einen Multiplexer vor allem brauchst, um auf dem Server eine lange Aufgabe am Laufen zu halten. Dafür ist tmux ausgereifter, überall vorinstalliert und seit Jahren stabil.

Wie sich die beiden konkret unterscheiden, steht im Vergleich herdr gegen tmux. Und für alle, die noch mit dem Urgestein arbeiten: herdr gegen GNU screen.

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