Beim gleichzeitigen Betrieb von AI-Coding-Agenten wie Claude Code oder Codex in mehreren tmux-Sitzungen sind bei mir Probleme aufgetreten. Ich habe übersehen, welche Sitzung fertig war, welche auf mich wartend blockiert war, und bei im Hintergrund laufenden Agenten habe ich oft erst bemerkt, dass ein usage limit erreicht wurde, nachdem es schon passiert war.
Mit tmux kam ich an Grenzen, deshalb habe ich comux entwickelt.
comux ist ein tmux-ähnlicher Multiplexer für den Betrieb von AI-Agenten.
- Zeigt den Agentenstatus aller Sitzungen (working / ready / blocked) in Echtzeit in einer Seitenleiste an
- Sendet sofort Desktop-Benachrichtigungen, wenn ein Agent seinen Turn beendet oder auf Eingabe wartet
- Selbst wenn der Server abstürzt oder neu gestartet wird, stellt es beim Neustart jeden Agenten an der Stelle der Unterhaltung wieder her (anders als tmux-resurrect werden die Sitzungen neu gestartet)
- Usage der Agenten und aufgelaufene Benachrichtigungen lassen sich in Echtzeit in der Statusleiste prüfen
Da es sich um eine einzelne statische Binärdatei ohne Abhängigkeiten handelt, läuft es überall, auch auf headless Servern per SSH.
Es ist Teil eines größeren Terminal-Projekts (copad), aber comux kann auch separat installiert werden:
# Nur Comux installieren
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash
# Copad mit installieren (Linux & MacOS)
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash
Entstehungsbericht aus 4 Monaten: https://marshallku.com/dev/road-to-making-my-own-terminal/
Feedback ist willkommen, besonders von Leuten, die mehrere Agenten parallel nutzen.
3 Kommentare
Ich habe auch den Blogbeitrag mit großem Interesse gelesen.
Da ich selbst mit einer ähnlichen Motivation ein Terminal entwickle, sind bei mir ein paar Fragen aufgekommen.
Persönlich habe ich das Gefühl, dass sich die DX-Umgebung heutzutage so schnell verändert wie selten zuvor und dass jeder Entwickler in einer etwas anderen Realität lebt.
Ich weiß nicht, ob Sie das auch so empfunden haben, aber gerade in so einer Zeit hielt ich es für vorteilhafter, wenn die Kontrolle bei mir selbst liegt.
Und als ich darüber nachgedacht habe, was die Grundlage der DX im Zeitalter von AI ist, kam ich zu dem Schluss, dass sie terminalbasiert ist.
Ich habe die meisten der zuletzt populären Terminals ausprobiert, aber bei den meisten war schon die koreanische Eingabe mangelhaft, und auch für die Nutzung von Agenten waren DX und UX unkomfortabel. Deshalb bin ich ebenfalls zu dem Schluss gekommen, es direkt selbst zu entwickeln, und ich denke, dass ich mir mit meinem eigenen Terminal eine bessere Produktivität als andere verschafft habe.
In meinem Fall wollte ich die Kontrolle vollständig gewinnen,
und deshalb dachte ich auch, dass man die Abhängigkeit von externen Bibliotheken minimieren sollte. Daher habe ich mich für eine Eigenentwicklung in Zig entschieden (abgesehen von unvermeidlichen Dingen wie WebView).
Wenn ich mir jedoch Ihren Blogbeitrag und den Code ansehe, haben Sie sich für Rust entschieden und statt mehr selbst zu entwickeln externe Bibliotheken aus dem Rust-Ökosystem wie
ratatuigewählt. Mich würde interessieren, warum Sie diese Entscheidung getroffen haben.Auch im Text wirkte es so, als hätte es Probleme durch Abhängigkeiten von externen Bibliotheken gegeben.
Da WebView ein natives WebView ist, dürfte ein vollständiger E2E-Test wohl schwierig sein, weil die meisten Webumgebungen nicht der Safari-Umgebung entsprechen. Geben Sie diesen Teil deshalb einfach an externe Testing-Tools ab? Oder planen Sie später vielleicht auch, CEF zu integrieren? Das würde mich ebenfalls interessieren.
Auch ich bin inzwischen an dem Punkt angekommen, an dem mein Terminal einigermaßen nutzbar ist und in die Stabilisierungsphase übergeht, sodass ich viel über Feature-Erweiterungen, Planung und UX nachdenke. Während der Entwicklung dürfte es aber viele Crashes und allerlei Bugs gegeben haben.
Mich würde daher auch interessieren, ab wann nach dem Entwicklungsstart es stabil genug war, dass Sie nicht mehr in einem externen Terminal, sondern in Ihrem selbst entwickelten Terminal arbeiten konnten.
Hallo!
Danke, dass Sie Ihre guten Erfahrungen und Gedanken geteilt haben.
Natürlich hat sich durch die sinkenden Kosten für die Code-Erstellung der Weg zur Eigenentwicklung geöffnet, aber persönlich betrachte ich die Einführung externer Libraries unabhängig davon, ob nun das KI-Zeitalter angebrochen ist.
Nur wenn ich denke, dass diese beiden Punkte zutreffen, baue ich etwas selbst.
Dafür gibt es verschiedene Gründe, aber letztlich denke ich: Sobald ich anfange, auch nur ein noch so kleines Code-Stück zu verwalten, fällt es in meinen Verantwortungsbereich für Review, Tests, Wartung usw., und es entstehen immer Kosten, die über das reine Schreiben von Code hinausgehen.
Auch die Probleme während der Entwicklung waren oft Konflikte mit recht zentralen Programmen wie dem Window Manager. Wenn ich auch das alles from scratch gebaut hätte, hätte ich vermutlich deutlich mehr Zeit in Implementierung und Verifikation stecken müssen als in das Debugging und Testen von Konflikten mit externen Abhängigkeiten.
Außerdem habe ich seit Beginn der Entwicklung — wenn auch unter Schmerzen — weiterhin mein eigenes Tool benutzt. Ich vermute, dass das bis zu einem gewissen Grad möglich war, weil ich auf bestimmten Abhängigkeiten aufgebaut habe.
Wie in dem Fall, in dem ich SwiftTerm unter macOS entfernt habe: Zunächst hole ich eine externe Abhängigkeit hinein und prüfe, ob das von mir gewünschte Konzept funktioniert. Wenn sich dann etwas ergibt, das ich selbst implementieren muss, beginne ich damit. Aber auch zu diesem Zeitpunkt laufen meine Programme dank der externen Abhängigkeit erst einmal weiter, sodass ich darauf aufbauend weiter Stabilisierung und Feature-Erweiterungen vorantreiben konnte.
Außerdem gilt: Wenn man WebKit einbindet, verhalten sich die meisten Web-Apps genauso, als würde man sie in einem normalen Browser öffnen!
In letzter Zeit nutze ich aktiv ein Tool, mit dem man einen Headless Browser per CLI steuern kann, sowie Claude in Chrome. Außerdem möchte ich vermeiden, Chromium sogar noch ins Terminal einzubetten und dadurch übermäßig viel Speicher zu verbrauchen. Wenn nichts Größeres passiert, werde ich den Tech-Stack der WebView im Terminal daher wohl nicht wesentlich ändern.
Danke fürs Lesen!
Der Link zur Installation des Multiplexers scheint abgeschnitten zu sein. Wenn Sie diesen Abschnitt in der README prüfen, können Sie nur den Multiplexer installieren.