Herdr: un multiplexer de coding agents para correr la manada desde un solo terminal
Imagen: Herdr — herdr.dev. Reproducida bajo fair use con fines de comentario crítico.
Herdr es un agent multiplexer: un binario que vive en el terminal y permite correr múltiples coding agents en paralelo desde una sola sesión persistente, attachable desde cualquier device. La idea de fondo es directa — los coding agents son procesos con estado, igual que los shells que administra tmux — y tmux no los entiende, pero Herdr sí. Si alguna vez quisiste cerrar la laptop y que tus agentes sigan trabajando, o ejecutar un agente en un server remoto desde el teléfono, Herdr es exactamente eso.
Lo que pasó
Herdr es un binario (no una app Electron, no un dashboard web, no un servicio con cuenta) que se instala con un único comando y arranca un servidor local con sesiones persistentes. Los agentes que corrés dentro — Claude Code, Codex, OpenCode, Kimi CLI, Cursor, Copilot CLI, o cualquier terminal agent — viven como procesos reales en PTYs reales, con un layout clickable, state visible (blocked, working, done, idle), y un API JSON sobre socket para que otros procesos (incluido el propio agente) puedan orquestarlos.
Lo que lo diferencia de tmux o Zellij es que Herdr entiende agentes, no solo shells. Lo que lo diferencia de las apps desktop de coding agents (Cursor, Claude Desktop, etc.) es que vive en el terminal y se puede attachar remotamente.
Por qué importa para quien desarrolla con agentes
Trabajar con un coding agent desde la UI desktop es cómodo hasta que necesitás cerrar la laptop, hasta que el agente tiene que correr en un server con más recursos, hasta que querés revisar lo que está haciendo desde el teléfono mientras estás lejos del escritorio. Ahí es donde el modelo “app” se queda corto:
- Persistencia. Una app desktop depende de que tu máquina esté encendida y con la UI abierta. Herdr corre como servidor; los agentes siguen vivos cuando cerrás el laptop, cuando perdes la conexión SSH, cuando cambia el IP de tu red.
- Ubicuidad. Te attachás desde cualquier terminal — Mac, Linux, iPhone SSH client, tablet. El state del agente es el mismo.
- Orquestación programática. Herdr expone CLI y JSON socket API para crear workspaces, panes, esperar estado de agente, leer output. Los agentes pueden orquestar a otros agentes — un patrón que está creciendo en setups multi-agent.
- Sin telemetría ni cuentas. Es un binario en tu máquina. No hay control plane hosted.
Qué resuelve, exactamente
Caso 1: agente en el server, attach desde la laptop.
Tenés un coding agent que tarda 6 horas en una tarea. Lo corrés en tu server (porque ahí están los repos, la GPU, la memoria). Cerrás la laptop. Al rato, abrís el SSH client desde el teléfono y revisás el progreso.
ssh you@server
herdr # attach a la sesión existente
# ves el agent state: working, blocked, done
# podés hacer follow-up, cambiar de pane, salirCaso 2: múltiples agentes en paralelo.
Tres agentes en paralelo: uno corre tests, otro refactorea un módulo, el tercero investiga un bug. Herdr los pone en panes separados con state visible. Podés esperarlos a todos con un solo comando:
herdr wait agent-status 1-1 --status done
herdr wait agent-status 1-2 --status doneCaso 3: agentes que orquestan agentes.
El patrón “spec-driven development” que vimos en otro post se vuelve concreto con Herdr: un agente (Claude Code) escribe la spec, otro (Codex) la implementa. Herdr permite que el primer agente pase work al segundo vía API, espere resultado, revise, e itere — sin que tengas que estar vos mirando la pantalla.
Caso 4: revisar desde el teléfono.
SSH client en iPhone o Android (Termius, Blink, etc.), herdr desde el remote, y tenés un dashboard touch-friendly que te muestra blocked / working / done. Aprobás diffs, cambiás de pane, dejás follow-ups. El escritorio puede estar cerrado.
La arquitectura: por qué funciona
Herdr es tres cosas en una:
- Multiplexer de terminales con estado semántico. Como tmux, mantiene sesiones persistentes con PTYs reales. Pero además sabe qué es un agente y expone su estado (idle / working / blocked / done / error) como primitiva de primera clase.
- Servidor attachable. El proceso
herdrcorre como daemon (o se inicia al abrir el terminal). Cualquier cliente que se conecte al socket ve la misma sesión, el mismo layout, el mismo state. SSH es solo el transporte. - Control surface programático. CLI + JSON socket API. Otros procesos — incluido otro agente — pueden crear workspaces, mover panes, leer output, esperar eventos. Es lo que permite la orquestación multi-agent.
El binario está en ~/$PATH después de instalar, no requiere root, no requiere daemon system-level. Es Unix-style: hace una cosa, la hace bien, se compone con el resto.
Cómo se compara con las alternativas
Herdr mismo publica una tabla comparativa. La versión simplificada:
| Capacidad | tmux / Zellij | Agent apps (Cursor, etc.) | Worktree orchestrators | Herdr |
|---|---|---|---|---|
| Corre en tu terminal | ✓ | — | — | ✓ |
| Sesiones PTY persistentes | ✓ | limited | embedded | ✓ |
| Attach remoto por SSH | ✓ | limited | remote projects | ✓ |
| State semántico de agente | — | partial | workspace status | ✓ |
| Attach directo a un agente | — | — | — | ✓ |
| Otros agentes pueden orquestarlo | scriptable | partial | workflow-owned | ✓ |
La diferencia clave: tmux entiende shells pero no agentes. Las agent apps entienden agentes pero no son multiplexers de terminal. Los worktree orchestrators (git worktree managers) gestionan repos pero no sesiones. Herdr es lo que pasa cuando tomás un multiplexer clásico y lo hacés agent-aware.
El marketplace de plugins
Herdr viene con un marketplace de plugins liviano: cualquier repo público de GitHub tageado herdr-plugin es instalable con un comando.
herdr plugin install <owner>/<repo>La idea es la misma que los marketplaces de tmux o Zellij, pero con scope más alto: hay 150+ plugins que agregan desde syntax highlighting para output de agentes hasta pixel-art de ovejas pastando cuando un agente está idle. Lo que no hace el core, lo hace un plugin. Lo que no hace ningún plugin, lo publicás vos con un topic en GitHub.
Cómo empezar en cinco minutos
El quick-start oficial es deliberadamente corto: Herdr es mouse-first, no exige memorizar atajos. El flujo básico es este:
1. Instalar y arrancar.
curl -fsSL https://herdr.dev/install.sh | sh
cd ~/Projects/algun-proyecto
herdrHerdr abre o se attacha a la sesión background default. No administrás sockets. Si te detachás, los agentes siguen corriendo.
2. Crear workspaces por proyecto.
Cuando una sesión no tiene workspaces, Herdr abre uno automáticamente. Un workspace es un contenedor a nivel de proyecto para tabs, panes y agentes. Convención útil: un workspace por proyecto activo. Mantiene el state de los agentes legible en la sidebar — sin esta disciplina, mezclar agentes de tres proyectos en una sola sesión es donde empieza el caos.
3. Arrancar el coding agent.
En cualquier pane:
claude
# o codex, pi, opencode, o cualquier agent soportadoHerdr lo detecta automáticamente. La sidebar muestra working, blocked, done o idle para cada agente — en todos los workspaces, no solo el activo. Es lo que permite ver de un vistazo qué proyecto te necesita.
4. Mouse-first, teclado opcional.
Lo que se puede hacer con mouse en Herdr:
- Click panes, tabs, workspaces, agents para focus.
- Drag de bordes para redimensionar splits.
- Right-click para context menus (split panes, new tab, etc.).
- Drag-select para copiar texto al clipboard sin
Ctrl+C. - Double-click sobre un token para copiarlo directamente.
- Ctrl-click abre links en el pane (OSC 8 hyperlinks y URLs
http(s)://visibles).
El teclado es opcional pero está ahí para quien lo quiera. Modo prefix (Ctrl+B y luego la acción):
| Acción | Atajo |
|---|---|
| Split right | prefix + v |
| Split down | prefix + - |
| New tab | prefix + c |
| Next / previous tab | prefix + n / prefix + p |
| Workspace nav | prefix + w |
| New workspace | prefix + shift + n |
| Detach client | prefix + q |
5. Detach, reattach, terminar.
- Detach =
prefix + q, o cerrar la ventana del terminal. Server y agentes siguen vivos. - Reattach =
herdrotra vez desde cualquier device que pueda llegar al socket. - Terminar de verdad =
herdr server stop. Ahí sí mueren los panes.
Instalación
Linux/macOS (estable):
curl -fsSL https://herdr.dev/install.sh | shWindows (preview beta):
irm https://herdr.dev/install.ps1 | iexUna vez instalado, herdr arranca el server y abre el TUI. Para attach remoto, hay un cliente dedicado (herdr --remote workbox) que instala Herdr en el host por vos y bridgea el clipboard local — incluyendo paste de imágenes — y mantiene los keybindings que ya usás.
Para quién tiene sentido
Sí, miralo si:
- Corrés coding agents que tardan más de unos minutos y querés que sobrevivan cierres de laptop.
- Tenés agentes en servers remotos y querés attach desde cualquier device (incluido el teléfono).
- Estás armando un setup multi-agent donde un agente orquesta a otros.
- Querés evitar el modelo “app desktop” por motivos de portabilidad, persistence o privacidad.
- Usás tmux o Zellij y sentís que falta algo para agents.
Esperá si:
- Trabajás con un solo agente a la vez y no te importa cerrar la laptop cuando termine.
- Tu workflow es 100% web/desktop y no usás terminal para coding agents.
- No tenés agentes que tarden más de unos minutos.
Lo que conviene recordar
- Herdr es un multiplexer de agentes, no una app. Corre donde está el trabajo; te attachás desde donde estás.
- Persistencia y ubicuidad son el value principal. Los agentes sobreviven cierres de laptop y cambios de red.
- El state semántico (blocked / working / done) es lo que cambia la orquestación. Sin esa primitiva, multi-agent es complicado.
- El CLI + JSON socket API permite que agentes orquesten agentes. Esto compone con setups de spec-driven development.
- No Electron, no cuenta, no telemetría. Es un binario Unix-style. Lo que Herdr no hace, lo hace un plugin.
Fuente
- Herdr — sitio oficial.
- Documentación: herdr.dev/docs (incluye preview de Windows beta, integraciones, comparativa completa).
- Integraciones soportadas: Claude Code, Codex, OpenCode, Cursor, Copilot CLI, Kimi CLI, Droid, Amp, Grok CLI, Hermes, Antigravity, Kiro, Qoder CLI, MastraCode, Pi. Cualquier terminal agent funciona out of the box; las integrations agregan state rico y session resume.
