Zum Inhalt springen
vord
Auf die Warteliste macOS 15+ · Apple Silicon & Intel

// Der Blog · 16. Juni 2026

Warum ein Statusraster Terminal-Tabs schlägt

5 Minuten Lesezeit

Du kannst schon jetzt fünf Agenten in tmux fahren. Fenster teilen, in jedem Pane einen starten, fertig. Das funktioniert, bis du die Frage beantworten willst, auf die es wirklich ankommt: Welcher braucht mich? tmux kann es dir nicht sagen. Die Tab-Leiste deines Terminals auch nicht. Warum das so ist, lohnt sich zu verstehen — denn darin steckt das ganze Argument für ein anderes Werkzeug.

Ein Terminal-Multiplexer zeigt Panes, keinen Zustand

tmux ist sehr gut in dem, was es tut: Es multiplext ein Terminal. Es gibt dir Panes und Fenster, die einen Verbindungsabbruch überleben. Was es nicht hat, ist irgendein Begriff davon, was in einem Pane passiert. Für tmux sehen ein blockierter und ein beschäftigter Agent gleich aus, weil beide ein Strom von Bytes sind. Es kann dir alle Ströme gleichzeitig zeigen. Es kann dir nicht sagen, dass Pane 3 an einer Rechtefrage hängt, während Pane 1 mitten im Denken ist.

Also liest du. Du überfliegst die Panes, entzifferst die Ausgabe mit eigenen Augen, schließt auf den Zustand. Bei zwei Agenten geht das. Bei fünf fällt es zusammen, denn jetzt bist du die Status-Engine — in einer Schleife, langsam, vergesslich.

Um den Status zu kennen, musst du die Session betreiben

Hier liegt der technische Kern. Von außen lässt sich anhand der Ausgabe nicht verlässlich unterscheiden, ob ein Agent arbeitet oder wartet. Ausgabe ist mehrdeutig: Eine lange Pause kann Nachdenken heißen — oder dass unterhalb des sichtbaren Bereichs eine Abfrage auf Eingabe wartet. Farben und Spinner helfen dem menschlichen Auge, liefern aber kein sauberes Signal.

Ein sauberes Signal bekommst du, indem du die Session in einem echten PTY betreibst, das dir gehört. Wenn du das Pseudo-Terminal selbst hältst, siehst du jedes Byte, das der Agent schreibt, und kontrollierst seine Eingabe. Das ist das Fundament, auf dem alles andere steht. Ohne es rätst du von außen. Mit ihm hast du Gewissheit. vord macht das für fünf CLIs: Claude Code, Codex, Kimi, OpenCode und Grok. Du installierst und startest sie selbst, vord betreibt die Sessions.

Hooks schlagen Heuristiken — und du willst beides

Das PTY zu besitzen bringt dir die Bytes. Aber das beste Signal steckt gar nicht in den Bytes. Es ist der Agent, der es dir direkt sagt. Eine CLI wie Claude Code kann bei Zustandsänderungen Hooks auslösen. Richte diese Hooks auf einen lokalen Empfänger, und der Agent meldet seinen eigenen Status: gestartet, wartet auf Rechte, stellt eine Frage, wartet auf einen Plan, fertig. Das ist keine Schlussfolgerung. Das ist der Agent, der sagt, was er tut.

Bildschirm-Heuristiken verdienen ihren Platz weiterhin als Rückfallebene. Wo keine Hooks eingerichtet sind oder eine CLI keine auslöst, liest du, was die Session ausgibt, und triffst die beste mögliche Einschätzung. Das richtige Design nutzt das starke Signal, wenn es da ist, und fällt auf die Heuristik zurück, wenn nicht — nie umgekehrt.

Der Gewinn des starken Signals ist Genauigkeit. Eine Heuristik sagt dir „wartet wahrscheinlich“. Ein Hook sagt dir „wartet, wegen einer Rechtefrage, für diesen Befehl“. Dieser Unterschied macht aus einer Benachrichtigung etwas Nützliches statt Lärm.

Sortieren ist die Funktion, von der du nicht wusstest, dass du sie brauchst

Sobald du den Zustand jeder Session wirklich kennst, kannst du danach sortieren. Das klingt banal. Es ist das mit Abstand Nützlichste, was das Raster tut.

Alles, was auf dich wartet, kommt nach oben. Damit ist der Bildschirm die Warteschlange. Du suchst die blockierte Session nicht, denn sie steht schon vorn. Die arbeitenden rutschen dorthin, wo sie hingehören; anfassen sollst du sie ohnehin nicht. Die untätigen liegen noch tiefer, neben allem, was beendet ist oder ein Limit erreicht hat. Das Layout übernimmt die Triage, damit deine Augen es nicht tun müssen.

Vergleich das mit Tabs, deren Position davon abhängt, wann du sie geöffnet hast. Der blockierte Agent kann Tab 1 oder Tab 6 sein, und herausfinden lässt es sich nur, indem du jeden besuchst. Tabs mit fester Position zwingen dich zur linearen Suche. Nach Status sortierte Karten geben dir die Antwort ganz oben.

Dichte ist die andere Hälfte

Den Status zu kennen erlaubt es, Details gefahrlos einzuklappen. Wenn du nur wissen musst, wer dich braucht, brauchst du keine fünf scrollenden Terminals. Du brauchst fünf Statuskarten, die du mit einem Blick erfasst. Wenn du eingreifst, öffnest du diese eine Session in voller Größe und tippst in ein echtes Terminal. Du änderst die Menge des Gezeigten danach, was du gerade entscheidest — statt auf fünf volle Terminals zu starren, die du ohnehin nicht gleichzeitig lesen kannst.

Also: Tabs oder Raster?

Tabs sind richtig, wenn du ein oder zwei langlebige Sessions hast, in denen du direkt arbeitest. Ein Raster ist richtig, wenn du viele Sessions hast, die immer wieder eine Entscheidung brauchen, und du nicht vorhersagen kannst, welche und wann. Genau das ist der Arbeitsablauf mit Agenten.

Das Terminal wurde für den Menschen an der Tastatur gebaut. Das Raster ist für den Menschen gebaut, der eine Flotte beaufsichtigt — und das ist die Aufgabe von heute.

Das Cockpit

Das Raster sortiert sich selbst, Wartende zuerst

Jede Session ist eine Karte. Arbeitende Agenten rutschen nach unten. Wartende stehen oben — schon gefunden, bevor du irgendwo geklickt hast. Wo die CLI ihren Zustand über Hooks meldet, ist die Beschriftung genau: Rechtefrage, Rückfrage, Plan zur Freigabe oder fertig.

vord — Cockpit
vord-Statusraster mit nach Status sortierten Agenten-Sessions — Wartende oben, Arbeitende darunter

// Mehr aus dem Blog

Passend dazu

Hör auf, dich durch Terminals zu klicken, um das eine zu finden, das dich braucht

vord betreibt jede Agenten-Session in einem echten Terminal und sortiert das Raster mit den Wartenden zuerst. Claude Code, Codex, Kimi, OpenCode und Grok, alle in einer Ansicht.