Ekko Studio: ein lokales Dashboard für fünf Agent-Runtimes

Fünf Runtimes, ein Arbeitsbereich: das Problem hinter Ekko Studio

Wer heute mit Coding-Agenten arbeitet, betreibt selten nur einen. Claude Code läuft im Terminal, Codex in einem anderen, Pi vielleicht in einem dritten Fenster, dazu ein Hermes-Agent mit eigenen Profilen, Providern und Cron-Jobs. Jede dieser Installationen bringt ihre eigene Sitzungsverwaltung mit, ihre eigene Art, Modellantworten zu streamen, ihre eigene Ablage für generierte Dateien. Ekko Studio setzt genau an dieser Stelle an: Das Projekt beschreibt sich selbst als "shared product platform, not a sixth agent", also als gemeinsame Plattform und nicht als sechster Agent. Es koordiniert die fünf Runtimes Hermes, Ekko, Claude Code, Codex und Pi in einer Oberfläche, mit gemeinsamer Sitzungsdatenbank, gemeinsamer Dateiverwaltung, gemeinsamer Nutzungsstatistik und gemeinsamen Plattformkanälen. Die Zielgruppe sind damit nicht Endanwender, die einen einzelnen Chatbot suchen, sondern Betreiber, die mehrere Agent-Familien parallel laufen lassen und deren Zustand an einer Stelle sehen wollen. Das README gruppiert die Runtimes in drei Familien: Hermes, Ekko und die Coding-Agenten. Jede Familie behält laut Dokumentation ihre eigenen Zuständigkeiten, etwa Profile, Provider, Skills und Kanban bei Hermes oder Installation und Prozessausführung bei den Coding-Agenten.

Die API-Trennung ist die eigentliche Architekturentscheidung

Das Repository trennt zwei Namespaces. Studio-eigene HTTP-APIs liegen unter /api/studio/*, die Kontrollebene von Hermes liegt unter /api/hermes/*. Diese Aufteilung ist mehr als Namenskosmetik: Sie legt fest, welche Daten das Dashboard autoritativ hält und welche es nur liest. Am deutlichsten wird das bei Sitzungen. Ekko Studio führt eine eigene SQLite-Datenbank für Studio-Sitzungen, während die Hermes-eigene state.db laut README eine reine Lesquelle für die Verlaufs-APIs von Hermes bleibt. Die Sitzungssuche über Ctrl+K durchsucht dementsprechend nur die lokale Studio-Datenbank, nicht die schreibgeschützten Hermes-Verlaufssitzungen. Dieser Schnitt hat Konsequenzen für jeden, der Sitzungen migrieren oder sichern will: Es gibt nicht die eine Sitzungsablage, sondern zwei mit unterschiedlichen Rechten. Der Chat selbst läuft laut README über Socket.IO auf dem Pfad /chat-run, wobei Studio jeden Lauf über Runtime-Adapter an einen der fünf Agenten weiterreicht. Für bereits veröffentlichte Pfade der mobilen App existiert eine zentrale Kompatibilitätsschicht, statt alte Controller doppelt zu pflegen. Das ist eine bewusste Entscheidung gegen Wildwuchs, aber sie bedeutet auch, dass neue API-Versionen an dieser Schicht vorbeimüssen.

Installation: npm-Paket, Docker-Image oder Desktop-Build

Das README nennt drei Auslieferungswege: eine Desktop-App für Windows, macOS und Linux, ein npm-CLI-Paket und ein Docker-Image. Der schnellste Weg steht direkt im Kopf der README: npm install -g hermes-web-ui && hermes-web-ui start. Wer die Desktop-Variante bevorzugt, lädt sie über die Release-Seite. Für die Einrichtung der Plattformkanäle sind zwei Dateien maßgeblich, und beide liegen außerhalb des Projekts im Home-Verzeichnis. Zugangsdaten wie Bot-Token schreibt die Oberfläche laut README nach ~/.hermes/.env. Verhaltenseinstellungen der Kanäle, etwa Mention-Steuerung oder Auto-Thread, landen in ~/.hermes/config.yaml. Das ist eine relevante Designentscheidung: Die Konfiguration gehört dem Hermes-Agenten, nicht dem Dashboard. Wer Ekko Studio entfernt, behält seine Kanalkonfiguration, und wer sie von Hand ändert, sieht die Änderung beim nächsten Start. Die Seite für Plattformkanäle deckt zehn Dienste ab, darunter Telegram, Discord, Slack, WhatsApp, Matrix, Feishu, DingTalk, QQBot, WeChat und WeCom. Die Erkennung, ob ein Kanal konfiguriert ist, läuft laut README über einen Status pro Plattform. Ein Sonderfall ist WeChat: Dort erfolgt die Anmeldung per QR-Code im Browser, die Zugangsdaten werden automatisch gespeichert.

Workflows, Jobs und Kanban: was das Dashboard selbst besitzt

Neben dem Chat hat Studio eigene Funktionen, die keinem Agenten gehören. Dazu zählen ein Vue-Flow-Canvas für visuelle Workflows, über den sich die fünf Runtimes verbinden lassen, sowie geplante Aufgaben im Cron-Format. Für Jobs nennt das README Anlegen, Bearbeiten, Pausieren, Fortsetzen und Löschen sowie eine sofortige Ausführung und vorgefertigte Cron-Ausdrücke. Dazu kommt ein profilbewusstes Kanban-Board, das Aufgaben anlegt, aktualisiert und Status verschiebt. Interessant ist der Hinweis, dass Kanban denselben lokalen Studio-Zustand und dasselbe Authentifizierungsmodell nutzt wie der Rest des Dashboards. Das erklärt, warum es kein eigenes Berechtigungskonzept gibt: Wer Zugriff auf die Oberfläche hat, hat Zugriff auf Board und Jobs. Die Nutzungsanalyse wertet Token-Verbrauch nach Eingabe und Ausgabe aus, zählt Sitzungen mit Tagesdurchschnitt, schätzt Kosten, zeigt die Cache-Trefferquote, verteilt die Modellnutzung und stellt einen 30-Tage-Verlauf als Balkendiagramm plus Datentabelle dar. Wer diese Zahlen für Abrechnung verwenden will, sollte beachten, dass das README von geschätzten Kosten spricht. Eine Schätzung ist keine Abrechnungsgrundlage, und die zugrunde liegenden Preistabellen sind nicht Teil des hier vorliegenden Materials.

Wo Ekko Studio die falsche Wahl ist

Die erste Einschränkung steht im Funktionsumfang selbst. Die Sitzungssuche über Ctrl+K erfasst ausdrücklich nicht die schreibgeschützten Hermes-Verlaufssitzungen. Wer also historische Hermes-Sitzungen durchsuchen will, bekommt im Dashboard nur einen Teil der Daten zu sehen und muss für den Rest auf die Hermes-eigenen Werkzeuge zurückgreifen. Zweitens ist der Betriebsaufwand real: ein global installiertes npm-Paket, ein Docker-Image und Desktop-Builds für drei Plattformen bedeuten drei Pflegepfade, die auseinanderlaufen können. Drittens passt das Modell nicht für Einzelnutzer. Wer genau einen Agenten mit einem Anbieter betreibt, braucht keine Runtime-Adapter, keine Gruppe von fünf Runtimes und keine Kompatibilitätsschicht für mobile App-Pfade. Der vierte Punkt betrifft die Lizenz. GitHub meldet für das Repository NOASSERTION, das README verlinkt einen LICENSE-Pfad, aber der Inhalt liegt hier nicht vor. Wer Ekko Studio kommerziell einsetzen oder weiterverbreiten will, muss diesen Text selbst lesen, bevor er plant. Eine Aussage über Erlaubnisse ist auf dieser Grundlage nicht möglich.

Alternativen: Oberfläche mitgeliefert oder selbst gebaut

Die naheliegende Alternative ist, beim Agenten selbst zu bleiben. Hermes Agent bringt laut README eine eigene Kontrollebene mit, die Ekko Studio über /api/hermes/* anspricht. Wer nur Hermes betreibt, kann diese Ebene direkt nutzen und auf die Studio-Schicht verzichten. Der Unterschied liegt nicht im Funktionsumfang, sondern in der Datenhoheit: Direkt am Agenten gibt es nur eine Sitzungsablage, während Ekko Studio eine zweite SQLite-Datenbank daneben führt und die Hermes-Datenbank nur liest. Für reine Hermes-Nutzer ist das ein zusätzlicher Zustand ohne Gegenwert. Umgekehrt gilt: Sobald Claude Code, Codex und Pi mit im Spiel sind, gibt es zu Ekko Studio keine vergleichbare Zusammenführung, weil die Coding-Agenten laut README eigene Installations-, Proxy- und Sitzungslogik mitbringen. Eine zweite Alternative ist der Verzicht auf eine gemeinsame Oberfläche und der Betrieb getrennter Terminals und Konfigurationsdateien. Das kostet keine zusätzliche Software, aber es kostet die gemeinsame Nutzungsstatistik, die gemeinsame Dateiverwaltung und die gemeinsamen Kanäle.

Wartung, Release-Tempo und was vor dem Einsatz zu klären ist

Der Versionsverlauf ist aufschlussreich. Auf v0.7.17 vom 4. September 2026 folgte zwei Tage später v0.7.18, und am 9. September 2026 erschien v1.0.2. Zwischen den letzten beiden Releases liegt ein Sprung von 0.7 auf 1.0 innerhalb von drei Tagen. Solche Sprünge sind kein Qualitätsurteil, aber sie sagen etwas über die Erwartung an die Versionsnummer: Wer auf 0.7.x aufgesetzt hat, muss mit Änderungen rechnen, die eine Hauptversionserhöhung rechtfertigen. Das Repository ist nicht archiviert, der letzte Push liegt auf demselben Tag wie das Release v1.0.2. Für die Wartung heißt das konkret: Die Konfiguration liegt in ~/.hermes/.env und ~/.hermes/config.yaml und überlebt ein Upgrade des Dashboards. Die Studio-eigene SQLite-Datenbank für Sitzungen tut das nicht automatisch, und das README beschreibt kein Migrationswerkzeug dafür. Vor einem Upgrade sollte man diese Datei sichern. Offen bleibt die Lizenzfrage: Solange NOASSERTION gemeldet wird und der LICENSE-Text nicht geprüft ist, lässt sich weder die Weitergabe noch der kommerzielle Einsatz planen. Das ist der erste Punkt, den ein Team klären muss, nicht der letzte.

Redaktionelles Fazit

Wer mehrere Agent-Runtimes parallel betreibt und Hermes-Profile, Provider und Jobs nicht in fünf separaten Oberflächen verwalten will, findet hier eine konsolidierte Konsole mit klarer API-Trennung zwischen /api/studio/* und /api/hermes/*. Wer einen einzelnen Chat-Bot für einen Anbieter sucht, trägt mit einem npm-Paket, einem Docker-Image und drei Desktop-Builds deutlich mehr Betriebslast als nötig. Vor dem Einsatz zu prüfen sind der Lizenztext im LICENSE-Pfad, weil GitHub NOASSERTION meldet, sowie die Frage, ob die eigene Hermes-Version die unter /api/hermes/* erwarteten Endpunkte bereitstellt.

Offizielle Quellen

1. EKKOLearnAI/hermes-studio on GitHub
2. Issues
3. Project website
4. README
5. Releases