Pane vs Ghostty

renderizado de fuentes y rendimiento por GPU

Ghostty usa su propio renderizador por GPU, con Metal en macOS y OpenGL en Linux. El renderizado de fuentes, incluidas ligaduras, emojis y fuentes de color, es uno de sus objetivos de diseño principales, y quien pasa horas en una terminal lo nota.

libghostty se puede integrar

Mitchell Hashimoto publicó su visión de libghostty en septiembre de 2025 - una biblioteca de C/Zig integrable que permite a cualquier app usar el renderizado de Ghostty. cmux (la terminal para agentes de macOS) ya se basa en libghostty. Esto convierte a Ghostty en una base de renderizado más que en una app terminada, lo que es una apuesta de ecosistema muy sólida.

licencia MIT, financiado por la comunidad

Ghostty tiene licencia MIT, sin restricciones comerciales. Su patrocinador fiscal es Hack Club (una 501(c)(3)), después de que la familia de Mitchell donara personalmente 150.000 $ para arrancar el proyecto. No hay presión de inversores de capital riesgo ni plan de pago. El código es totalmente abierto y se puede bifurcar.

cumplimiento de estándares e interfaz nativa de cada plataforma

Ghostty tiene el cumplimiento de estándares como objetivo prioritario: secuencias de escape de xterm, códigos OSC, gráficos sixel. En macOS usa SwiftUI; en Linux usa GTK. Cada plataforma tiene un marco de ventana nativo, no una capa de compatibilidad multiplataforma.

sin notificaciones que conozcan a los agentes

El hilo de discusiones de Ghostty sobre flujos de trabajo con agentes + tmux documenta claramente esta carencia: no hay ningún mecanismo para lanzar una notificación de escritorio cuando un agente concreto en un panel concreto de tmux pasa a estar en espera. Las alternativas - bucles de sondeo, scripts de tmux send-keys, disparadores de AppleScript - obligan a mantener herramientas propias que se rompen con las actualizaciones de tmux y de Ghostty.

configuración manual de worktrees por agente

Cada agente en paralelo necesita su propia rama y su propia copia del sistema de archivos. Con la pila casera, eso supone git worktree add antes de cada agente y git worktree remove para limpiar después. Con 4 o más agentes al día, eso suma decenas de comandos manuales por semana.

el cansancio de comprobarlo todo

Para saber qué agente espera una respuesta, o recorres a mano todas las ventanas de tmux o escribes un script de sondeo. Ninguna de las dos opciones escala. El coste de cambiar de contexto para revisar 4 o más agentes repartidos en ventanas de tmux se come buena parte de la ventaja del paralelismo.

sin una revisión de diffs unificada

Cuando un agente termina, revisar sus cambios supone cambiar a esa ventana de tmux y ejecutar git diff o gh pr diff en la terminal. No hay un visor de diffs unificado con resaltado de sintaxis para todos los agentes. Hacer commit y push es otro paso manual por agente.

automatización de worktrees

Crea un pane y se le asigna un worktree de git en su propia rama, con tus archivos .env y los ajustes del agente copiados. Archiva el pane y el worktree se elimina después de que Pane compruebe que no queda nada sin guardar. Sin el ciclo manual de git worktree add y eliminar.

coordinación de varios agentes

Pane le da a cada agente su propia sesión aislada con un indicador de estado visible. Cuando un agente espera una respuesta, salta una notificación de escritorio al instante - sin sondeos ni scripts de bash. Ves todos los agentes en una sola interfaz.

multiplataforma

Pane funciona en Windows, macOS y Linux con el mismo flujo de trabajo, y ejecuta los agentes dentro de WSL para los repos que tengas ahí. Si tu equipo incluye desarrolladores en Windows, todos pueden usar la misma configuración.

revisión de diffs y commit con el teclado

Cuando un agente termina, pulsa ⌘⇧B (Ctrl+Shift+B en Windows y Linux) para abrir el panel Changes y sus diffs con resaltado de sintaxis, luego ⌘⇧K para hacer commit y ⌘⇧U para hacer push, sin soltar el teclado ni cambiar de ventana. La pila casera necesita comandos de terminal para cada paso y para cada agente.