Ekko Studio : un poste de pilotage local pour cinq runtimes d'agents

Le problème : cinq runtimes, cinq façons de perdre le fil

Faire tourner un agent en local ne pose pas de difficulté technique. En faire tourner plusieurs, si. Chacun garde ses sessions, ses fournisseurs, ses modèles et ses traces d'outils dans son propre coin, et l'opérateur finit avec trois terminaux, deux navigateurs et un fichier de configuration qu'il édite à la main. Ekko Studio attaque ce point précis. Le README le formule sans détour : le projet est un poste de travail local-first qui permet de lancer « chats, groupes, workflows, coding tasks, voice, files, and devices from one local-first workspace ».

Le public visé n'est pas l'utilisateur occasionnel. C'est une personne qui a déjà installé Hermes Agent, ou Claude Code, ou Codex, et qui veut une couche commune par-dessus : sessions persistantes, historique, canaux Telegram ou Slack, jobs cron, tableau Kanban, suivi de consommation. Le README précise que Studio n'est pas un sixième agent, mais la plateforme produit partagée. Cette distinction n'est pas cosmétique, elle détermine tout le reste de l'architecture.

Deux familles d'API, et pourquoi la séparation compte

Le dépôt organise les responsabilités en trois familles d'agents. Hermes possède les profils, fournisseurs, modèles, skills, plugins, mémoire, jobs, Kanban, canaux, MCP et le terminal. Ekko possède l'exécution, les approbations, les clarifications, la mémoire et le comportement des fournisseurs. La famille codage (Claude Code, Codex, Pi) possède l'installation, la configuration, les proxys, les sessions et l'exécution des processus.

Studio ne prend en charge que ce qui est commun : chat simple, chat de groupe, orchestration d'agent global, workflows, webhooks, sessions, fichiers et uploads, TTS/STT, médias, thèmes, appareils, réseau, logs, usage, authentification. La conséquence est visible dans le routage HTTP. Les API propres à Studio vivent sous /api/studio/*, celles du plan de contrôle Hermes sous /api/hermes/*. Les chemins déjà publiés pour l'application mobile passent par une couche de compatibilité centralisée plutôt que par des contrôleurs hérités dupliqués.

Ce découpage a un coût. Toute fonctionnalité qui touche à la fois un agent et Studio doit être coupée en deux, et la documentation devra suivre deux chemins. En échange, on sait toujours quel composant détient l'état. C'est la décision de conception la plus lisible du projet, et probablement la plus difficile à préserver dans la durée.

Le flux d'une requête de chat

Le README décrit le mécanisme en une ligne : le streaming temps réel passe par Socket.IO sur le canal /chat-run, et Studio distribue chaque exécution vers Hermes, Ekko, Claude Code, Codex ou Pi via des adaptateurs de runtime. Autrement dit, le navigateur ne parle jamais directement à un agent. Il ouvre une connexion Socket.IO avec Studio, Studio choisit l'adaptateur correspondant au runtime demandé, et les réponses remontent en flux avec les traces d'outils et les aperçus de fichiers générés.

Le stockage suit la même logique de séparation. Studio dispose de sa propre base SQLite locale pour ses sessions, tandis que le fichier state.db de Hermes reste une source en lecture seule pour les API d'historique Hermes. Cette asymétrie explique une limitation documentée : la recherche de session via Ctrl+K porte sur la base locale de Studio, et le README indique explicitement que les sessions d'historique Hermes en lecture seule n'y sont pas incluses. Un utilisateur qui cherche une vieille conversation Hermes ne la trouvera pas par ce chemin.

Les fichiers suivent un traitement distinct : les uploads sont limités à un profil, et le téléchargement d'un fichier généré par un agent se fait par résolution de chemin, ce que le README présente comme fonctionnant sur les backends local, Docker, SSH et Singularity. La prévisualisation en ligne couvre HTML, PDF, DOCX, PPTX, XLSX, CSV, images, Markdown et fichiers source.

Installation : deux commandes et un fichier de configuration

La distribution prend trois formes : une application de bureau Windows/macOS/Linux, un paquet npm en CLI, et une image Docker. Le chemin le plus court documenté est le paquet npm :

npm install -g hermes-web-ui && hermes-web-ui start

Le nom du paquet npm (hermes-web-ui) diffère du nom du produit affiché (Ekko Studio) et du nom du dépôt (hermes-studio). C'est une source de confusion réelle au moment de chercher de l'aide ou de vérifier une version, puisque les releases sont étiquetées « HStudio v1.0.2 » et « v0.7.18 ».

La configuration des canaux est le point où Studio écrit réellement sur le disque. Le README indique que la gestion des identifiants écrit dans ~/.hermes/.env, et que les réglages de comportement des canaux écrivent dans ~/.hermes/config.yaml. Dix plateformes sont prises en charge depuis une page unique : Telegram, Discord, Slack, WhatsApp, Matrix, Feishu (Lark), DingTalk, QQBot, WeChat et WeCom. Selon les plateformes, les champs varient : token de bot pour Telegram et Discord, App ID et Secret pour Feishu, DingTalk et QQBot, access token et homeserver pour Matrix, connexion par QR code pour WeChat avec sauvegarde automatique des identifiants. Studio affiche un état configuré ou non configuré par plateforme.

Le fait que Studio réécrive ~/.hermes/config.yaml mérite attention : ce fichier appartient à Hermes, pas à Studio. Si vous l'éditez à la main en parallèle, vous prenez le risque d'un écrasement.

Ce que le dépôt ne permet pas de vérifier

La licence est déclarée NOASSERTION. GitHub n'a pas su classer le fichier LICENSE du dépôt, ce qui signifie qu'aucune conclusion sur les droits d'usage, de modification ou de redistribution n'est possible à partir des métadonnées. Le README affiche un badge de licence npm, mais un badge n'est pas un texte de licence. Avant tout déploiement en entreprise, il faut ouvrir le fichier LICENSE et le lire.

D'autres éléments restent hors de portée. Le README est tronqué au milieu de la section sur les workflows visuels : on sait qu'un canevas Vue Flow existe pour Hermes, Ekko, Claude Code, Codex et Pi, mais la phrase s'arrête là. La section « Visual Workflows » ne peut donc pas être évaluée. De même, la page d'accueil du projet (hermes-studio.ai) et la documentation pointée par le README (ekkostudio.xyz) ne sont citées que comme liens, sans contenu fourni.

Un point de conception mérite d'être signalé comme limite plutôt que comme défaut : le couplage à ~/.hermes/. Une grande partie des réglages de canaux transite par ce répertoire, ce qui suppose une installation Hermes existante et un utilisateur qui accepte que Studio et Hermes partagent le même espace de configuration. Quelqu'un qui veut utiliser uniquement Claude Code ou Codex, sans Hermes, se retrouve avec une dépendance de chemin qui n'a pas de sens pour lui.

Face à un chat multi-modèles classique

La comparaison la plus directe est avec une interface de chat multi-modèles auto-hébergée de type Open WebUI. La différence n'est pas dans l'apparence, elle est dans ce que chaque outil possède. Une interface de chat classique envoie un prompt à une API de modèle et affiche la réponse. Elle n'a pas de notion de profil d'agent, de skills, de mémoire persistante côté agent, de plan de contrôle, ni de jobs planifiés qui déclenchent un agent.

Ekko Studio se place un cran plus haut. Il ne parle pas à des modèles, il parle à des runtimes d'agents, chacun avec ses fournisseurs, ses modèles et son état. C'est aussi ce qui le rend plus lourd : il faut un runtime installé derrière, et la valeur du produit dépend de ce runtime. Une interface de chat classique reste utilisable avec une simple clé d'API. Ekko Studio, non.

Le revers est un périmètre fonctionnel plus large sur des points qu'une interface de chat n'aborde pas du tout : jobs cron avec pause, reprise et déclenchement immédiat, tableau Kanban lié au même état local et au même modèle d'authentification, analyse d'usage avec répartition entrée/sortie des tokens, coût estimé, taux de succès du cache et tendance sur 30 jours. Ces fonctions supposent que l'agent produit des données exploitables, ce qui n'est vrai que si vous l'utilisez réellement pour des tâches suivies.

Maintenance : un rythme de publication serré

Trois releases apparaissent dans les métadonnées : v0.7.17 le 4 septembre 2026, v0.7.18 le 6 septembre, puis v1.0.2 le 9 septembre, jour du dernier push sur main. L'écart entre v0.7.18 et v1.0.2 est de trois jours, ce qui suggère un passage de version majeure rapide plutôt qu'une longue phase de stabilisation. Pour un opérateur, cela veut dire deux choses : les correctifs arrivent vite, et les ruptures de compatibilité peuvent arriver vite aussi.

Le dépôt n'est pas archivé. Le langage principal est TypeScript, avec Vue 3 côté client d'après les topics du dépôt. La pile est donc homogène, ce qui réduit le coût d'entrée pour une équipe front-end.

Le coût de mise à jour réel se concentre sur deux fichiers : ~/.hermes/.env pour les identifiants et ~/.hermes/config.yaml pour le comportement des canaux. Ce sont les points de friction lors d'un changement de version, parce qu'ils sont partagés avec Hermes et réécrits par Studio. Sauvegardez-les avant chaque montée de version. Sur la licence, aucune analyse n'est possible tant que le fichier LICENSE n'a pas été lu : NOASSERTION signifie que la question reste ouverte, pas qu'elle est réglée.

Conclusion éditoriale

Ekko Studio convient à ceux qui font déjà tourner Hermes Agent ou un agent de codage en local et veulent une interface unique pour les sessions, les canaux et les jobs planifiés. Ceux qui cherchent un simple client de chat multi-modèles sans runtime d'agent derrière trouveront la couche de coordination inutile. Avant d'adopter, vérifiez deux points précis : la licence réelle du dépôt, que GitHub ne classe pas, et le contenu de ~/.hermes/config.yaml après avoir configuré un premier canal, puisque c'est ce fichier que Studio réécrit.

Sources officielles

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