Superlogical Rex: el Creador de Ghostty Repiensa el Multiplexor de Terminal

Rex es el multiplexor de terminal que Mitchell Hashimoto lleva construyendo en Superlogical desde HashiCorp y Ghostty. Es un emulador de terminal y un multiplexor en una sola aplicación nativa: abres la app, estás en un terminal, y las sesiones, splits y persistencia ya están ahí. Al 5 de octubre está en prueba pública (invitaciones por lista de correo, macOS primero), pero la documentación ya es pública y Hashimoto ha publicado dos largos recorridos de cómo funciona. Hay material real suficiente para escribir un briefing en condiciones, así que aquí está.

La app Rex para macOS: pestañas de sesión arriba, paneles divididos corriendo una revisión de código Codex, una TUI de git diff y un juego Snake

Qué es Rex

No corres Rex dentro de otro terminal como tmux corre dentro de Kitty o Ghostty; él es el terminal. El pitch de Superlogical es “un reemplazo directo del terminal que uses hoy”, con sesiones persistentes, conexiones remotas y estado de actividad de programas encima.

El vocabulario son cuatro sustantivos, y aparecen por todas partes en la CLI y la config:

• Una sesión es un grupo de trabajo, normalmente un proyecto. El servidor la mantiene viva haya o no alguien mirándola.
• Una ventana es una pestaña dentro de una sesión. Contiene un layout de bloques.
• Un bloque es una aplicación en una ventana. Hoy eso significa un terminal.
• Un cliente es un programa conectado al servidor, como la app de macOS.

El servidor lo posee todo. Los clientes se conectan, renderizan, se desconectan. Cierra la app a mitad de un build, vuelve a abrirla, y estás de vuelta en la misma sesión donde la dejaste.

Por qué la arquitectura es diferente (y por qué importa)

Esta es la parte que vale entender, porque es la razón por la que Rex existe en vez de ser otra skin de tmux.

Un multiplexor tradicional se sienta entre tu emulador de terminal y el PTY. Terminal → tmux → shell. Cada byte se parsea dos veces: una por el modelo de terminal interno del multiplexor, otra por tu emulador. E históricamente, los núcleos de terminal dentro de tmux, screen y zellij son lentos al lado de los emuladores modernos. Hashimoto lo dice sin rodeos en su recorrido de arquitectura: Ghostty, Kitty y Alacritty son a veces 100x más rápidos en IO de terminal que el emulador dentro de un multiplexor, así que atornillar uno delante de tu terminal rápido te da, en sus palabras, “esa experiencia lenta en un terminal rápido”.

Quién parsea el flujo PTY: los multiplexores tradicionales se sientan entre tu terminal y el shell y parsean los bytes dos veces; Rex deriva bytes crudos a instancias libghostty por cliente

Rex invierte quién hace el parsing:

1. El servidor posee el PTY. Cuando un cliente se conecta, el servidor pausa el procesamiento del PTY un momento y envía un frame binario personalizado con justo el estado suficiente (dimensiones, cursor, pantalla actual) para que el cliente renderice. Luego un frame de listo: puedes escribir, seleccionar y hacer scroll mientras todo lo demás carga.
2. Bytes crudos, no diffs de pantalla. En vez de seguir un modelo de pantalla compartido y enviar diffs, el servidor deriva los bytes PTY crudos a cada cliente, como SSH. Cada cliente corre libghostty y parsea independientemente. Si el servidor alguna vez parsea lento, a tu cliente le da igual.
3. El scrollback se transmite detrás. Primero el chunk más nuevo, con un estado de carga mientras el historial se rellena. Y como el cliente posee su propio viewport, dos clientes conectados pueden hacer scroll en la misma sesión independientemente, lo que arregla el famoso comportamiento de tmux donde una persona haciendo scroll mueve la pantalla de todos.

Dos consecuencias que vale conocer:

• Sin multiplexado dentro de la ventana. Cada split es su propia conexión PTY renderizada como pestaña, split o ventana nativa. Eso es lo que hace posibles los clientes iOS y navegador, y es por qué un árbol de paneles estilo tmux no es el modelo. Un modo de compatibilidad legacy para terminales tontos (una capa libghostty en medio, el mismo trade-off que hace tmux pero con un núcleo más rápido) aún se está discutiendo.
• El input sigue centralizado. Las pulsaciones de teclas se serializan por el servidor, un escritor y muchos lectores, así que el estado autoritativo nunca se bifurca aunque un cliente se desincronice. Un cliente desviado simplemente reejecuta el handshake.

Como el cliente es el emulador de terminal, el soporte de funciones sigue a libghostty. La brecha del protocolo de gráficos Kitty que tmux nunca cerró es el tipo de cosa que aterriza mucho más rápido aquí, porque Superlogical envía el motor de terminal.

Hosts remotos: discretamente un reemplazo de SSH

La segunda demo es la que me hizo incorporarme. Rex no es solo persistencia local. Desde la paleta de comandos añades un host remoto (Hashimoto lo demuestra contra un VPS en su tailnet), y lo que se abre parece SSH pero no es SSH:

• Hace un login de sistema real. La sesión aparece en who, tu login shell se carga, los límites por usuario se respetan. Hashimoto dice que ni siquiera corre SSH en esa máquina; Rex es cómo entra, incluyendo como root. Un mapeo del lado servidor controla qué identidades pueden actuar como qué usuarios, y las claves SSH existentes se respetan.
• rex whoami reporta la cadena de identidad. En la demo muestra que conectó como mitchellh vía su identidad Tailscale a través de un par de saltos. La autenticación remota viaja sobre la identidad de red que ya tienes.
• Se siente local. Describe haber tomado ideas arquitectónicas de Mosh para la respuesta, sin reclamar paridad completa con Mosh. Matar una sesión remota vía rex session kill se propaga antes de que puedas reabrir la app.
• Todo lo local funciona en remoto. El salto a directorio Cmd+Shift+G también funciona en hosts remotos. “Todo lo que funciona local debería funcionar remoto” es una regla de diseño declarada.

Las sesiones locales no necesitan nada remoto. Los hosts remotos son para cuando quieres la misma persistencia en un VPS.

La CLI rex es la superficie de control

Cada terminal que abre Rex obtiene rex en su PATH automáticamente, más tres variables de entorno que le dicen a la CLI dónde está:

Así que rex split dentro de un panel divide ese panel. Para actuar en otro sitio, apunta con -s (sesión), -w (ventana), -b (bloque), -C (cliente) o -S (servidor). Los objetivos se resuelven en un orden fijo: ID completo, luego label, luego posición, luego un sufijo de ID de 4+ caracteres. Un objetivo ambiguo no cambia nada: lista las coincidencias y sale con estado 3.

rex ls                              # list sessions
rex session inspect                 # details of the session you're in
rex send -s build -w 2 'make test'  # type into window 2 of the "build" session
rex capture -b logs                 # print the screen of the block labeled "logs"
rex -S studio ls                    # sessions on the host labeled "studio"

La mayoría de comandos aceptan --json (salida estable con IDs completos, hecha para scripts) y devuelven códigos de salida con significado: 0 ok, 1 falló, 2 línea de comandos mala, 3 objetivo inexistente o ambiguo, 4 servidor inalcanzable, 130 interrumpido. rex wait y rex run --wait adoptan el estado de salida del programa envuelto, así que los scripts componen limpiamente. Es la misma filosofía “todo es automatizable” de cmux, llevada más lejos.

La configuración es Lua, y las acciones personalizadas son reales

La config vive en un archivo: ~/.config/rex/init.lua en macOS y Linux, %AppData%\rex\init.lua en Windows, REX_CONFIG pisa ambas. Rex no necesita config alguna, y require te permite dividir una grande en archivos.

rex.bind("cmd+d", "pane.split", { direction = "right" })
rex.bind("ctrl+b>c", "window.new")  -- tmux-style prefix chords work

Dos detalles que la documentación deja claros y es fácil pasar por alto: el servidor lee el archivo, así que rex config reload debe correr en la máquina del servidor y es rechazado por una conexión remota. Y no hay file watching; la recarga es manual. rex config check valida un archivo sin aplicarlo, una llamada rex.* errónea se salta con un error mientras el resto del archivo sigue cargando, y un error de sintaxis Lua duro mantiene la última config buena.

Las acciones personalizadas son funciones Lua con nombre definidas con rex.action. Una vez definidas se comportan como las integradas: vinculables a teclas, buscables en la paleta de comandos, ejecutables desde la CLI con rex do:

rex.action{
  name  = "scratch",
  title = "Open Scratch Window",
  run   = function(ctx, args)
    rex.session.new_window{
      layout = rex.layout.block{
        flavor = "com.superlogical.terminal.shell",
      },
    }
  end,
}
rex.bind("shift+cmd+n", "scratch")

Las acciones toman args tipados (o un JSON Schema completo como tabla Lua), reciben un ctx (session_id, block_id, client_id, origin), llaman a otras acciones por rex.invoke, y encolan acciones del lado cliente con rex.client.queue. Dos puertas que conocer: la app solo acepta acciones desde la CLI cuando Remote Control está activado en ajustes, y rex do ~/.config/rex/init.lua --action scratch corre una acción desde un archivo contra la sesión viva sin tocar la config en ejecución. Esa última es el bucle de iteración rápida.

Dónde puedes correrlo, y cuánto cuesta

Para conseguir un sitio, únete a la lista de correo en la página del anuncio. La documentación es pública y vale leerla incluso sin acceso; la referencia de CLI y Lua te cuenta la mayor parte de lo que es el producto.

Rex vs tmux vs Herdr

Encuadre honesto: son herramientas diferentes resolviendo problemas diferentes. tmux es el incumbente con décadas de memoria muscular detrás. Rex apuesta a que el multiplexor debería ser el terminal. Herdr ni siquiera es un terminal, es un plano de control para agentes de código IA (sidebar de estado de agentes, socket API, plugins de marketplace). Si los agentes son tu problema real, empieza con mi reseña de Herdr y las guías de los mejores clientes Herdr y mejores plugins Herdr. Si la ergonomía del terminal es el problema, Rex es lo más interesante en este espacio desde zellij.

Aristas que conocer

• Solo macOS por ahora. Sin workaround, sin sideload; las piezas de Linux y Windows existen pero aún no están en manos de testers.
• El flujo tmux no se porta 1:1. Sin árbol de paneles dentro de la ventana; los splits son conexiones separadas en contenedores nativos. Los acordes de prefijo como ctrl+b>c funcionan en rex.bind, tu .tmux.conf no.
• La recarga de config es manual. Sin file watching aún; rex config reload solo en la máquina del servidor.
• El reemplazo de SSH es real pero temprano. Las demos muestran logins completos y respeto de claves SSH, pero el mapeo de identidades del lado servidor aún no está documentado en profundidad.
• La superficie de funciones sigue a libghostty. Adopción rápida de funciones de terminal, pero el servidor sigue gobernando lo que una sesión puede hacer.

FAQ

La versión corta

Rex es Mitchell Hashimoto argumentando que un multiplexor de terminal no debería emular un terminal en medio de tu terminal. El cliente parsea, el servidor transmite, las sesiones persisten, los remotos hacen login de verdad, y todo es scriptable en Lua. Es solo-macOS por ahora, pero la documentación es pública y la arquitectura es genuinamente diferente en vez de un reskin. Únete a la lista de correo si quieres entrar.

También vale una mirada: mi guía de configuración de Ghostty (el mismo motor está bajo el capó de Rex) y la guía de cmux, otro terminal basado en libghostty con una CLI de automatización que ya está disponible para macOS.