Mientras ejecutaba agentes de codificación con AI como Claude Code y Codex al mismo tiempo en varias sesiones de tmux, me encontré con un problema. Se me pasaba cuál sesión había terminado, cuál estaba bloqueada esperando por mí, y con los agentes que corrían en segundo plano solo me daba cuenta de que habían llegado al usage limit después de que ocurría.
tmux llegaba hasta ahí, así que hice comux.
comux es un multiplexor estilo tmux para ejecutar agentes de AI.
- Muestra en tiempo real en la barra lateral el estado del agente en todas las sesiones (
working / ready / blocked) - Envía notificaciones de escritorio de inmediato cuando un agente termina su turno o queda esperando entrada
- Aunque mates el servidor o lo reinicies, al volver a iniciar restaura cada agente al punto de la conversación en el que estaba (a diferencia de
tmux-resurrect, reinicia la sesión) - Puedes ver en tiempo real desde la barra de estado el usage de los agentes y las notificaciones acumuladas
Es un único binario estático sin dependencias, así que funciona en cualquier lugar, como servidores headless por SSH.
Forma parte de un proyecto de terminal más grande (copad), pero comux se puede instalar por separado:
# Instalar solo Comux
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash
# Instalar también Copad (Linux & MacOS)
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash
Bitácora de 4 meses de desarrollo: https://marshallku.com/dev/road-to-making-my-own-terminal/
Si ejecutan varios agentes, sus comentarios son bienvenidos.
3 comentarios
También leí muy bien la entrada del blog.
Como alguien que también está desarrollando un terminal por una motivación similar, me surgieron algunas dudas.
Personalmente, no sé si alguna vez hubo una época como la actual, en la que el entorno de DX cambia tan rápido y además es distinto para cada desarrollador,
pero no sé si usted también lo sintió: justamente en momentos así pensé que era más ventajoso que el control estuviera de mi lado,
y cuando me pregunté cuál es la base del DX en la era de la IA, llegué a la conclusión de que es el terminal.
He probado casi todos los terminales que están de moda últimamente, pero como la entrada en coreano es deficiente en la mayoría y la DX/UX para usar agentes era incómoda, yo también llegué a la conclusión de que debía desarrollarlo por mi cuenta. Avancé con eso y creo que, gracias a mi propio terminal, logré una productividad mejor que la de otras personas.
En mi caso, para obtener el control por completo,
pensé que también debía minimizar la dependencia de librerías externas, así que elegí desarrollarlo yo mismo con Zig (salvo casos inevitables como el webview).
Al ver la entrada del blog y el código, noté que eligió Rust, y me da curiosidad saber por qué optó por librerías externas existentes en Rust, como
ratatui, en lugar de desarrollarlo usted mismo.En el texto también parecía que hubo problemas derivados de la dependencia de librerías externas.
Además, dado que el webview es un webview nativo, como la mayoría de los entornos web no son Safari, me parece que hacer pruebas E2E completas sería difícil. ¿Esa parte simplemente la dejan en manos de herramientas externas de testing? ¿O tienen pensado agregar CEF más adelante? También me da curiosidad.
Yo también, después de usar mi terminal durante cierto tiempo, ya entré en una etapa de estabilización y ahora estoy en una fase en la que pienso mucho en agregar funciones, en la planificación y en la UX, pero imagino que durante el desarrollo hubo muchos crashes y varios bugs.
También me gustaría saber, después de comenzar el desarrollo, más o menos en qué momento se estabilizó lo suficiente como para empezar a usar su terminal propio en lugar de ejecutarlo desde un terminal externo.
¡Hola!
Gracias por compartir una buena experiencia y tus ideas.
Claro, a medida que baja el costo unitario de producir código, sí se abre el camino para construir cosas por cuenta propia, pero en lo personal sigo viendo la adopción de librerías externas sin relación con la llegada de la era de la IA.
Solo cuando creo que estas dos cosas son ciertas es que termino haciéndolo yo mismo.
Hay varias razones, pero al final pienso que, por pequeño que sea un fragmento de código, en cuanto yo empiezo a gestionarlo entra en un terreno donde yo mismo tengo que revisarlo, probarlo, mantenerlo, etc., y siempre viene acompañado de un costo que va más allá de simplemente escribir código.
Entre los problemas que también surgieron durante el proceso de desarrollo, hubo muchos choques con programas bastante centrales como el window manager, así que si además hubiera construido todo esto desde cero, creo que habría tenido que dedicar muchísimo más tiempo a la implementación y la validación que al período de depuración y pruebas por conflictos con dependencias externas.
Además, desde que empecé el desarrollo seguí usando, aunque con dolor, la herramienta que hice yo mismo, y creo que eso también fue posible en cierta medida porque empecé a desarrollar sobre varias dependencias.
Como en el caso de macOS donde se eliminó SwiftTerm, primero incorporé dependencias externas para comprobar si el concepto que quería realmente funcionaba, y cuando aparecía algo que yo tenía que implementar, empezaba a hacerlo directamente; aun en ese punto, mis programas seguían funcionando apoyados temporalmente en dependencias externas, así que pude seguir concentrándome en estabilizarlos y agregar funciones sobre esa base.
Además, si metes WebKit, la mayoría de las web apps funcionan igual que cuando abres un navegador normal.
Últimamente también estoy aprovechando bastante herramientas que permiten controlar un headless browser desde la CLI, y Claude in Chrome, y como quiero evitar montar Chromium incluso dentro de la terminal y terminar usando memoria en exceso, salvo que pase algo grande, no creo que vaya a cambiar demasiado el stack tecnológico de la webview dentro de la terminal.
¡Gracias por leer!
El enlace de instalación del multiplexor parece estar cortado... Si revisas esta sección del README, puedes instalar solo el multiplexor.