Herdr: multiplexor de terminal para agentes de código
Índice de contenidos
- Puntos clave
- Qué problema resuelve de verdad
- Cómo funciona por dentro
- La cola de atención, que es lo único que tmux no hace
- Instalación y primer arranque
- Que los agentes se manejen solos
- La persistencia, medida
- Herdr frente a tmux y Zellij
- Lo que no hace
- Preguntas frecuentes
- ¿Herdr sustituye a tmux?
- ¿Sirve si solo uso un agente?
- ¿Es seguro instalar plugins del marketplace?
- Conclusión
- Fuentes
Cuatro agentes trabajando y ninguna forma de saber cuál te está esperando. Ese es el momento en el que uno empieza a mirar herramientas como esta. Herdr[1] es un multiplexor de terminal para agentes de código: por fuera se parece mucho a tmux, por dentro sabe qué está haciendo cada proceso que tiene dentro. Lo he instalado, lo he roto y lo he medido, y aquí está lo que hace, lo que no, y en qué caso te sobra.
Puntos clave
- Herdr es un binario de Rust con licencia Apache-2.0. La versión estable el día de escribir esto es la v0.8.2, del 19 de agosto de 2026.
- Su diferencia real con tmux es que etiqueta cada panel como trabajando, bloqueado, terminado o inactivo, y ese estado sube por la jerarquía hasta el espacio de trabajo.
- Los agentes pueden manejarlo ellos mismos por línea de comandos y por un socket local que responde en JSON.
- El repositorio tiene 35.155 estrellas y se creó el 27 de marzo de 2026. Es un proyecto de seis meses en versión 0.8.x.
- Con un solo agente en marcha no aporta gran cosa. Empieza a compensar a partir de tres o cuatro corriendo a la vez.
Qué problema resuelve de verdad
El problema no es abrir terminales. Eso lo lleva resolviendo tmux desde 2007 y lo hace bien. El problema es que un panel con un agente dentro tiene dos aspectos indistinguibles: el que está pensando y el que lleva once minutos parado esperando que le confirmes un borrado. Desde fuera los dos son texto quieto.
Con dos agentes lo resuelves mirando. Con seis, no. Acabas rotando por los paneles cada pocos minutos como quien vigila un horno, y ese sondeo manual es exactamente el trabajo que la herramienta debería quitarte.
Herdr ataca eso y poco más. Su README lo dice sin adornos:
always running — herdr is a background server; the terminals live inside it. close the lid, drop the network, or restart the machine; agents keep working and sessions come back.
Traducido: el terminal deja de ser el sitio donde vive el trabajo y pasa a ser una ventana que se abre y se cierra sobre un trabajo que vive en otro sitio.
Cómo funciona por dentro
Es un modelo cliente-servidor clásico. El servidor es dueño de los pseudoterminales y de los procesos hijos; el cliente solo dibuja el estado y manda las teclas. Por eso matar el cliente no mata nada importante.
Encima de eso hay cinco piezas, y merece la pena aprenderse los nombres porque la línea de comandos los usa tal cual:
- Espacio de trabajo (
workspace): un proyecto, normalmente un repositorio. - Pestaña (
tab): una disposición dentro del espacio de trabajo. - Panel (
pane): un terminal de verdad, con su pseudoterminal. - Agente (
agent): un proceso reconocido dentro de un panel. - Sesión (
session): el espacio de nombres persistente del servidor.
La primera vez que lo arranqué me llevé un susto que conviene ahorrarse. Si usas sesiones con nombre, herdr status te responde status: not running aunque el servidor esté perfectamente vivo, porque consulta el socket por defecto en ~/.config/herdr/herdr.sock. Cada sesión con nombre tiene el suyo propio:
herdr status
herdr --session lab status server
herdr session list
La primera orden miente; las dos siguientes dicen la verdad. No es un fallo, el cliente pregunta donde le has dicho que pregunte. Pero perdí diez minutos ahí.
La cola de atención, que es lo único que tmux no hace
Herdr reconoce cinco estados de agente: working, blocked, done, idle y unknown. Lo interesante es que el estado no se queda en el panel, sube.
Lo comprobé arrancando Claude Code dentro de un panel y leyendo el estado por la interfaz de programación:
herdr --session lab agent start revisor --kind claude --pane w1:p2
herdr --session lab api snapshot
El agente apareció detectado como claude, marcado blocked porque estaba esperando en su pantalla de arranque, y ese blocked estaba replicado en la pestaña y en el espacio de trabajo dentro del mismo volcado JSON. Eso es toda la idea del producto en una línea de salida: no tienes que entrar a mirar, el contenedor de más arriba ya te lo dice.
La lista de agentes que reconoce es larga. En la v0.8.2, herdr agent start --kind acepta 22 valores: claude, codex, gemini, cursor, opencode, copilot, grok, qwen, cline, droid, amp, kimi, kiro, kilo, devin, hermes, mastracode, omp, agy, pi, qodercli y maki. Si tu agente no está en esa lista, seguirá funcionando dentro del panel, pero se quedará en unknown y perderás justo lo que has venido a buscar.
Instalación y primer arranque
La vía oficial es la de siempre, con lo que eso implica. Las otras dos líneas son las alternativas por gestor de paquetes:
curl -fsSL https://herdr.dev/install.sh | sh
brew install herdr
mise use -g herdr
Hay binarios estables para Linux, macOS y Windows en x86_64, y para Linux y macOS en aarch64. Yo bajé el de Linux aarch64 de la v0.8.2 a mano: 20.744.664 bytes, unos 20,7 MB. Un fichero, sin Node, sin Electron y sin runtime que instalar.
En reposo, con dos paneles abiertos, el servidor ocupaba 16,8 MB de RSS y el cliente 9,9 MB. Para lo que va a tener dentro, es ruido.
Después de instalarlo, ~/.config/herdr/ contenía solo un directorio sessions/ y un .plugins.lock vacío. No escribe ningún fichero de configuración hasta que tú lo creas, cosa que se agradece. El prefijo de teclado por defecto es ctrl+b, el mismo de tmux, y ctrl+b q desengancha el cliente.
Un aviso que no he visto en ninguna reseña: si lo arrancas en un pseudoterminal sin tamaño (dentro de un script, por ejemplo), el servidor levanta pero dividir paneles falla con un escueto ghostty error -2. Fijando el tamaño del terminal a 200×50 antes de arrancar, funcionó a la primera.
Que los agentes se manejen solos
Esta es la parte que me parece más interesante y la que menos se cuenta. Herdr expone un socket local y una línea de comandos que devuelve JSON, así que un agente puede abrir paneles, lanzar a otro agente y esperar a que se bloquee de verdad antes de seguir.
herdr --session lab pane split --direction right
herdr --session lab pane run w1:p2 'echo hola; uname -sm'
herdr --session lab pane read w1:p2
herdr --session lab agent wait revisor --state blocked
Todo lo que sale del socket viene envuelto en {"id": ..., "result": ...} o en {"id": ..., "error": {"code": ..., "message": ...}}, así que se consulta con jq sin parsear texto a ojo. La excepción es herdr pane read, que devuelve el contenido del terminal en texto plano y no acepta --json.
Y hay un detalle que dice mucho de para quién está pensado esto. El binario trae dentro su propia skill para agentes:
herdr --skill
Imprime un fichero de skill listo para Claude Code, con una instrucción defensiva incluida: el agente debe comprobar que la variable HERDR_ENV vale 1 antes de tocar nada, y si no, decir que no está dentro de Herdr y parar. Las propias pantallas de ayuda llevan un bloque dirigido a los modelos que empieza con "Are you an AI?". Es la primera herramienta de terminal que veo escribiendo documentación para sus dos públicos a la vez.
La persistencia, medida
La promesa de que el trabajo sobrevive a la desconexión es fácil de escribir y fácil de comprobar. Lancé un bucle de diez iteraciones con una pausa de tres segundos dentro de un panel, maté el cliente con kill -9 y esperé.
El servidor seguía en pie y el contador había avanzado solo mientras no había nadie mirando. El proceso no se enteró de que su terminal se había quedado huérfano, que es exactamente lo que uno quiere de un agente que lleva veinte minutos con una migración a medias.
Para máquinas remotas, herdr --remote servidor conecta por SSH y transmite la interfaz al terminal local. El anfitrión remoto puede ser Linux o macOS; Windows no puede hacer de anfitrión.
Herdr frente a tmux y Zellij
| tmux | Zellij | Herdr | |
|---|---|---|---|
| Terminales reales y persistencia | Sí | Sí | Sí |
| Estado del agente (trabajando, bloqueado) | No | No | Sí |
| Interfaz de programación pensada para agentes | No | No | Sí |
| Ratón cómodo desde el primer minuto | Limitado | Sí | Sí |
| Presente en cualquier servidor | Sí | No | No |
| Años de rodaje | Desde 2007 | Desde 2021 | Seis meses |
Puesto así, la conclusión es bastante sobria: Herdr añade una capa sobre lo que tmux ya hacía. Si esa capa te sirve, el cambio es cómodo porque comparte el prefijo ctrl+b y no te obliga a reaprender nada. Si no te sirve, tmux con cuatro líneas de configuración hace el resto igual de bien y ya está instalado en todas partes.
Hay una tercera vía que conviene mencionar: no instalar nada y trabajar con paneles del editor. Es lo más cómodo mientras no cierres la ventana, y es justo lo que deja de funcionar cuando el portátil se duerme con dos agentes dentro.
Lo que no hace
Conviene decirlo claro, porque el entusiasmo alrededor de estas herramientas tiende a comerse los límites.
Herdr no aísla nada. Los agentes comparten el mismo árbol de trabajo salvo que montes ramas separadas con herdr worktree, así que dos agentes editando el mismo fichero siguen pisándose igual que sin Herdr. Si lo que buscas es aislamiento de verdad, eso es otro problema y tiene otras herramientas.
Tampoco hay memoria compartida entre agentes ni nada parecido a un grafo de tareas: no existe un "cuando termine este, arranca aquel". Herdr te dice quién está bloqueado, la decisión sigue siendo tuya. Para el otro lado del problema, el de que el agente recuerde lo que se decidió la semana pasada, hace falta una capa de memoria aparte.
El marketplace de plugins tiene 939 plugins en 922 repositorios, y crece porque cualquiera publica uno poniendo el topic herdr-plugin en GitHub. La página lo admite: no los revisa nadie. Un plugin es un ejecutable local, con lo que eso significa.
Y está la edad del proyecto. Seis meses, versión 0.8.x, un protocolo de socket que va por la revisión 20 y un cliente que comprueba compatibilidad con el servidor al arrancar. Eso último no está ahí de adorno.
Preguntas frecuentes
¿Herdr sustituye a tmux?
Puede, pero no hace falta. Comparte el prefijo ctrl+b y cubre lo básico de tmux, así que se puede usar como reemplazo directo en la máquina de desarrollo. En servidores donde solo abres una sesión para mirar registros, tmux sigue siendo la opción sensata: está instalado, es diminuto y no necesita saber nada de agentes.
¿Sirve si solo uso un agente?
Poco. Con un agente ves su estado mirando la ventana, que es gratis. El valor de Herdr crece con el número de agentes simultáneos y se nota de verdad a partir de tres o cuatro, cuando el sondeo manual empieza a costar más que la herramienta.
¿Es seguro instalar plugins del marketplace?
Con la misma precaución que cualquier ejecutable de terceros. Los plugins se descubren automáticamente por un topic de GitHub, sin revisión previa, y se ejecutan en tu máquina con tus permisos. Lee el código antes de instalar, igual que harías con una extensión del editor.
Conclusión
Herdr resuelve un problema pequeño y concreto: saber qué agente te está esperando sin tener que ir a mirar. Lo resuelve bien, con un binario de 20 MB, sin dependencias y con una interfaz de programación que además pueden usar los propios agentes. Todo lo demás lo hacía ya tmux.
Si trabajas con un agente cada vez, no lo instales. Si tienes cuatro terminales abiertos y has perdido la cuenta de cuál está parado, merece la media hora de probarlo. Lo que más me ha gustado no es la interfaz, es que la herramienta asuma que parte de sus usuarios no son humanos y les escriba documentación aparte.
Si quieres seguir por aquí, la versión en inglés de este artículo está en /en/herdr-terminal-agent-multiplexer/, y para el debate de fondo sobre cuánta herramienta necesita realmente un agente está este análisis de los agentes de terminal.
Fuentes
Código fuente
Accede a todo el código fuente de este artículo en GitHub.
Ver en GitHub