Herdr: probé el multiplexor de terminal hecho para agentes de IA — así me fue

Llevo un rato corriendo varios agentes de código al mismo tiempo — Claude en uno, DeepSeek en otro, Codex, Gemini, Opencode y un par más, cada uno mordisqueando una parte distinta de un mismo proyecto. El problema nunca fue arrancarlos. El problema fue no perder de vista cuál estaba trabajando, cuál se había quedado esperando mi aprobación, y cuál ya había terminado hace veinte minutos sin que yo me diera cuenta. tmux nunca resolvió eso — para tmux, todos esos paneles son solo texto en una terminal, no le importa si adentro hay un agente pensando o un cat de un archivo.

Ahí entra Herdr: un multiplexor de terminal, pero diseñado desde cero para saber qué es un agente de código y qué no.

Qué es, en una frase

Herdr organiza tu terminal en workspaces, tabs y panes — como tmux o Zellij — pero además reconoce cuándo un pane tiene un agente de código adentro y le da seguimiento a su estado real: working, blocked, idle, done. No es una app de escritorio ni un dashboard web. Es un binario que corre en tu terminal, accesible por SSH desde cualquier lado, incluido el teléfono.

Se instala con un curl script, Homebrew o Nix, y arranca con un solo comando:

herdr

Eso abre o reconecta tu sesión de fondo. Si cierras la terminal o te desconectas, los agentes siguen vivos — te reenganchas cuando quieras, incluso desde el celular por SSH/Mosh:

Lo que de verdad resuelve

La comparación oficial que hace el propio sitio (herdr.dev/compare) es honesta y me ayudó a ubicarlo. Evalúa cinco dimensiones: integración con la terminal, persistencia de sesión, conciencia semántica del estado del agente, superficie de API para control, e integración con flujos de git/worktrees.

En corto: tmux/Zellij dan persistencia pero no entienden agentes. Warp/cmux entienden agentes pero te sacan de tu terminal. Los orquestadores de worktrees resuelven aislamiento por branch, no la vista en vivo de qué está haciendo cada agente. Herdr es el único que junta las tres cosas sin dejar la terminal.

Lo comprobé en vivo: listé mis workspaces con herdr workspace list y en un solo JSON vi el estado de los 10 agentes que tenía corriendo — cuál estaba idle, cuál blocked, cuál llevaba rato sin que nadie lo revisara. Eso, sin Herdr, hubiera sido ir pane por pane a mano.

El truco real: agentes como ciudadanos de primera clase

Lo que más se siente distinto es la API. No es solo “mandar texto a una terminal” — Herdr entiende el ciclo de vida del agente:

• agent start levanta un agente reconocido (Claude, Codex, Gemini, Opencode, y varios más) en un pane libre.
• agent prompt ... --wait manda una instrucción y espera a que el agente vuelva a un estado estable (idle, done o blocked) — no un timeout arbitrario, sino el ciclo de vida real del agente.
• agent wait --until blocked sirve para detectar exactamente cuándo un agente se quedó esperando una aprobación tuya.

Agentes delegándose trabajo entre sí

Esta es la parte que de plano no existía antes, ni con tmux ni con nada parecido. Como cada agente puede controlar a otro a través del mismo CLI, terminas con algo parecido a una llamada a función entre agentes — no solo “abrir una terminal y correr el proyecto” (eso ya lo resolvía cualquier multiplexor), sino delegar una tarea completa y esperar el resultado.

En la práctica se ve así:

• Desde Claude: “abre Opencode y termina el diseño” — Claude usa agent start/agent prompt --wait para levantar Opencode en un pane libre, mandarle la tarea de diseño, y esperar a que vuelva a idle antes de seguir.
• Desde Claude: “abre Codex y ejecuta una búsqueda en Playwright” — mismo patrón, pero delegando a Codex una tarea de automatización de navegador.
• Desde Codex: “abre Claude y carga los datos de la base del día de hoy” — la delegación funciona en ambos sentidos, cualquier agente puede ser el que pide y el que ejecuta.

Y lo importante: como todos corren sobre el mismo proyecto y el mismo directorio de trabajo, comparten el contexto real — archivos, git, base de datos local — no una copia aislada. Un agente no le “explica” al otro qué hay en el repo; simplemente opera sobre el mismo estado. Es la diferencia entre tener seis asistentes que no se hablan, y un equipo que se reparte el trabajo y se avisa cuando termina.

El ecosistema de plugins

Esto sí me sorprendió: hay 311 repositorios en GitHub con el topic herdr-plugin. No hay revisión formal — cualquiera publica el suyo con un manifiesto herdr-plugin.toml y aparece en el índice. Los más adoptados, por estrellas:

1. agentbox (★303) — corre agentes en VMs sandboxeadas en paralelo, local o en la nube.
2. herdr-file-viewer (★219) — visor de archivos TUI, consciente de git, con diffs y markdown renderizado.
3. herdr-reviewr (★213) — sidebar de code-review sobre el diff de un agente.
4. herdr-plus (★151) — colección de utilidades extra (Proyectos, Quick Actions).
5. herdr-remote (★119) — monitorea y controla tus agentes desde el celular o Telegram.

También hay de todo un poco: un plugin que convierte tus agentes en ovejitas pixel-art viviendo en una granja (herdr-flock), otro que resume el gasto de tokens en vivo, uno que sincroniza el título de la ventana, y varios de integración con Neovim.

Lo que probé y lo que no me convenció

Instalé el herdr-file-viewer y lo abrí en un split pane — funciona, se ve bien, tiene el árbol de archivos con diffs y syntax highlighting. Pero se sintió lento: cada vez que lo abres, Herdr levanta un binario completo de Rust en un pane nuevo, no es un simple visor liviano. Para una consulta rápida de “¿qué archivo tocó el agente?”, el overhead se nota.

Luego intenté instalar herdr-flock (las ovejitas) solo por curiosidad, y el build falló: cargo build --release no tenía un toolchain de Rust configurado por default en el sistema (rustup default stable lo hubiera arreglado). No es culpa de Herdr — es el costo de un ecosistema de plugins sin revisión central: cada uno trae su propia cadena de build, y no todos van a compilar limpio en cualquier máquina.

¿Vale la pena?

Si ya trabajas con un solo agente a la vez, Herdr es overkill — quédate con tu terminal de siempre. Pero si como yo tienes media docena de agentes trabajando en paralelo sobre el mismo proyecto, la diferencia es real: en vez de adivinar cuál terminó y cuál se quedó pensando, tienes un estado semántico real, consultable por CLI, agentes que se delegan trabajo entre sí compartiendo el mismo contexto, y control remoto desde el teléfono si lo necesitas.

Es gratis, open-source, sin cuenta ni telemetría. Lo peor que te puede pasar es instalarlo, probarlo un rato, y volver a tmux si no es lo tuyo — no hay mucho que perder.