Qué es Herdr y por qué tus agentes ya no viven en tu terminal

Si usas Claude Code, Codex o cualquier otro agente de programación desde la terminal, conoces la escena: tienes tres en marcha, cada uno en su ventana, y no sabes cuál ha terminado, cuál lleva veinte minutos esperando a que apruebes un comando y cuál sigue trabajando. Cierras el portátil para ir a comer y, al volver, alguno se ha quedado colgado con la conexión SSH. Herdr existe para esa escena.

Un servidor que no se va

La idea central cabe en dos frases. Herdr separa la terminal en dos mitades: un servidor en segundo plano, que es el dueño de los paneles y de los procesos que corren dentro, y un cliente, que es la interfaz que ves. El cliente se conecta y se desconecta; el servidor sigue.

Eso significa que cerrar la ventana, perder la conexión o apagar el portátil no mata al agente. Cuando vuelves y escribes herdr, la sesión aparece donde la dejaste, con la salida del agente intacta. Y puedes tener varios clientes mirando la misma sesión a la vez: uno en el equipo de casa, otro en el móvil por SSH.

Quien haya usado tmux o zellij reconocerá el modelo. La diferencia está en lo que Herdr construye encima.

Sabe qué es un agente

Un multiplexor clásico ve procesos. Herdr ve agentes. Detecta cuándo dentro de un panel corre Claude Code, Codex, Cursor, OpenCode, Pi o cualquiera de la veintena larga que reconoce, y le asigna un estado que se lee sin abrir el panel:

• trabajando: está ejecutando algo.
• bloqueado: necesita una respuesta tuya, una aprobación, una decisión.
• hecho: ha terminado y aún no lo has mirado.
• en espera: listo para recibir instrucciones.

Ese estado sube por la jerarquía. Si un agente está bloqueado, su panel, su pestaña y su espacio de trabajo se ven bloqueados en la barra lateral. La barra lateral es, en la práctica, el panel de control: arrancas varios agentes, los dejas trabajar en paralelo y miras ahí para saber a quién atender.

La detección funciona sin instalar nada dentro del agente. Herdr identifica el proceso en primer plano y lee lo que hay al fondo de la pantalla; compara esa captura con reglas por agente (los «manifiestos de pantalla») que se actualizan solas. Para algunos agentes hay integraciones oficiales que informan del estado directamente y, sobre todo, permiten reanudar la conversación después de reiniciar el servidor: Claude Code con claude --resume, Codex con codex resume, y así con el resto.

Las piezas, en cuatro palabras

Espacio de trabajo: un proyecto. Lo normal es uno por repositorio. Pestaña: una disposición de paneles dentro del espacio de trabajo (agentes, registros, servidor…). Panel: una terminal de verdad, con su proceso. Sesión: el espacio de nombres del servidor; con herdr a secas usas la sesión por defecto, y solo necesitas sesiones con nombre si quieres aislar por completo dos entornos.

Todo se maneja con el ratón: clic para enfocar, arrastrar bordes para redimensionar, clic derecho para dividir. El teclado es opcional, con un prefijo (ctrl+b) como en tmux, y todos los atajos se cambian en un fichero TOML.

Varias máquinas en una ventana

Aquí está la parte que más cambia el día a día de quien trabaja con servidores. Guardas una máquina SSH una vez (herdr machine add workbox) y sus espacios de trabajo aparecen en la misma barra lateral que los locales, con la lista de agentes combinada. Cambias de máquina como quien cambia de pestaña. Si se cae la conexión con una, las demás siguen; la que se cayó se reconecta sola y mientras tanto muestra lo último que vio, atenuado.

También puedes hacerlo al revés: entrar por SSH y ejecutar herdr allí, como harías con tmux. O usar herdr --remote workbox, que deja el servidor en el remoto pero pinta la interfaz en local, con tu tema y tus atajos.

Y una API para automatizar

Todo lo que hace la interfaz se puede hacer desde la línea de comandos o desde un socket local con JSON: crear espacios de trabajo, dividir paneles, leer la salida de un agente, enviarle un prompt y esperar a que termine (herdr agent prompt reviewer "revisa el diff" --wait). Un script puede orquestar agentes. Un agente puede orquestar a otros. Sobre esa API se construyen también los plugins, que ya son más de mil trescientos.

Qué no es

No es un agente: no escribe código, aloja a los que lo escriben. No es una aplicación de escritorio ni un panel web: es un binario en Rust que corre en tu terminal. Y no es un servicio en la nube: corre en tu máquina o en tu servidor, y lo que pasa en tus paneles no sale de ahí.

El código está en GitHub bajo licencia Apache 2.0, con versión nueva cada pocas semanas. En esta guía tienes la documentación traducida y un catálogo de plugins en castellano. Y si quieres verlo en marcha, instalarlo lleva cinco minutos.