libghostty 1.0: el motor de terminal de Ghostty ya tiene ABI estable y está listo para empaquetarse

Mitchell Hashimoto publicó el 6 de noviembre libghostty-vt 1.0, la biblioteca en C para emulación de terminal que se extrajo del núcleo de Ghostty. Lo importante no es el número redondo: desde esta versión la biblioteca y su ABI de C son estables, siguen versionado semántico y llegan con todo lo que una distribución de Linux necesita para empaquetarla. Eso convierte algo que ya estaba metido en la terminal de los IDE de JetBrains, en un PR aprobado de Neovim y en un experimento de KDE en una dependencia que cualquiera puede ligar dinámicamente sin miedo a que se le rompa en la siguiente actualización. Si construyes terminales web, herramientas de consola, grabadores de sesiones o agentes que tienen que "leer" lo que muestra una TUI, te conviene saber qué trae.

Qué es libghostty-vt

Según la documentación oficial, libghostty-vt es una biblioteca sin interfaz: le das los bytes que escribe un programa y te expone el estado de la terminal (la pantalla, el cursor, el scrollback). No dibuja nada. Lo que hagas con ese estado es cosa tuya: pintarlo con GPU, mostrarlo en una página web, guardarlo como grabación o pasárselo a un programa que necesita saber qué hay en pantalla.

La propia documentación enumera para qué sirve: emuladores y multiplexores de terminal, terminales web y sesiones remotas, grabación y reproducción de sesiones, arneses de pruebas para aplicaciones TUI y agentes o automatizaciones que leen lo que muestra una TUI. Trae licencia MIT.

El ejemplo de la página principal cabe en una pantalla: se crea una terminal de 80×24 con ghostty_terminal_new, se le escriben bytes con secuencias de color usando ghostty_terminal_vt_write y se lee lo que quedó en pantalla con un formatter.

Qué significa el 1.0

En su anuncio, Hashimoto explica que el 1.0 implica dos cosas: la biblioteca sigue versionado semántico y tiene promesas estrictas de compatibilidad de ABI, para que los empaquetadores la distribuyan y los programas se liguen a ella de forma dinámica con confianza.

La página de estabilidad lo pone en reglas concretas. Un programa compilado contra una versión 1.x sigue funcionando con cualquier 1.x posterior. Una versión menor solo puede agregar funciones, tipos, valores de enum o campos al final de una estructura con tamaño declarado. Nada se elimina, se cambia de tamaño, se reordena ni se cambia de tipo. Si algo cambia de comportamiento, sale como una función nueva con otro nombre y la vieja queda marcada como GHOSTTY_DEPRECATED hasta la siguiente versión mayor.

Hay una excepción documentada: el formato de bytes de los snapshots se versiona aparte y no entra en la promesa de ABI, así que puede cambiar en cualquier versión. Si piensas guardar snapshots en disco para reabrirlos después, toma nota.

Cómo lo sostienen, según el anuncio:

Cada objeto es un handle opaco, y los cientos de valores que se leen o escriben pasan por unos cuantos getters y setters indexados por enum. Así se agregan valores sin crear símbolos nuevos.
Un programa con headers más nuevos ligado a una biblioteca más vieja recibe GHOSTTY_UNSUPPORTED en lugar de un crash o un comportamiento indefinido.
Los enums quedan fijados a int en todos los compiladores, hasta donde lo permite el estándar de C.
El CI revisa cada cambio con libabigail contra una línea base en Linux, y contra manifiestos de tipos en macOS y WebAssembly. En plataformas ELF todos los símbolos exportados están versionados, así que el cargador dinámico rechaza una versión incompatible por nombre en vez de fallar después de forma misteriosa.

Diagrama: los bytes de un PTY, una conexión SSH o una grabación entran a libghostty-vt, que mantiene el estado de la terminal; el programa anfitrión se encarga de dibujar. Abajo, proyectos que ya la usan

Empaquetado, dependencias y plataformas

El 1.0 trae su propio ciclo de lanzamientos, separado del de Ghostty, la aplicación, y tarballs propios con solo lo que la biblioteca necesita. Hashimoto detalla que cada versión publica un tarball de código fuente firmado y otro de dependencias con los paquetes de Zig, para que una distribución compile sin conexión. La instalación deja bibliotecas compartida y estática con su SONAME, headers, archivos de pkg-config y configuración de CMake, y respeta --prefix, DESTDIR y lib64. Todo está documentado en PACKAGING-LIBGHOSTTY.md.

En dependencias, el anuncio dice que en tiempo de ejecución solo necesita libc, y que sin las rutas SIMD se puede compilar totalmente freestanding, que es como corre en RISC-V y ARM sin sistema operativo. Compila dentro simdutf y Google Highway para SIMD (sin libc++), una tabla compacta de Unicode y Wuffs para decodificar imágenes del protocolo de gráficos de Kitty. No hay código copyleft en todo el árbol, y cada dependencia aparece en un manifiesto con versión, licencia SPDX y hash.

Las plataformas que se compilan y se prueban en CI, según el anuncio:

Plataforma	Arquitecturas
Linux (glibc y musl)	x86_64, aarch64
macOS 13+	x86_64, aarch64
iOS 13+	aarch64
FreeBSD	x86_64, aarch64
Windows	x86_64
Android	aarch64, x86_64, arm
WebAssembly	wasm32 (freestanding)

Además se compila, sin pruebas automáticas, para bare metal (riscv32, thumb), WASI, Windows arm64, illumos y x86 de 32 bits. La versión de WebAssembly viene en dos sabores, uno optimizado para velocidad y otro para tamaño; el pequeño pesa menos de un megabyte con todo activado. Si solo necesitas un visor de lectura, puedes quitar con banderas de compilación la codificación de entrada, la búsqueda, la selección y los gráficos de Kitty, lo que según Hashimoto reduce el módulo aproximadamente a la mitad.

El dato que le importa a quien opera servidores

La biblioteca no crea hilos, reserva memoria solo a través de un allocator que puedes personalizar y, según su autor, usa poco cómputo y poca memoria. Hashimoto cuenta que corrió 10,000 terminales activas, cada una con una shell viva produciendo salida, en un servidor Linux con 4 núcleos y 8 GB de RAM. Tuvo que usar dash porque bash consumía mucha más RAM que la propia biblioteca y no cabía en los 8 GB.

Es una prueba del autor, no un benchmark independiente, y no la reproduje. Pero para quien ofrece terminales en el navegador, consolas de administración o sandboxes para agentes, el orden de magnitud es lo que cuenta: el cuello de botella deja de ser el emulador.

Quién ya lo usa

Hashimoto dedica buena parte del anuncio a los usuarios que ya tiene:

JetBrains. Desde la versión 2026.3, la terminal integrada de sus IDE corre sobre libghostty y sustituye a JediTerm, según el blog de JetBrains. La empresa explica que libghostty se encarga del análisis de secuencias y del estado de la terminal, mientras el IDE sigue dibujando. En la práctica, eso trae el protocolo de teclado de Kitty (Shift+Enter ya hace un salto de línea en herramientas como Claude Code o Codex) y casi 50 secuencias de control que JediTerm ignoraba o interpretaba mal.
Neovim. Tiene un PR aprobado que reemplaza libvterm por libghostty-vt y cierra un issue de hace 10 años sobre el reflow del scrollback al cambiar de tamaño. Según Hashimoto, los mantenedores esperaban una versión etiquetada para que las distribuciones empaqueten la dependencia por separado, y el 1.0 debería destrabarlo.
KDE. Eike Hein presentó Kwi, una terminal experimental para Plasma construida sobre libghostty-vt y Qt Quick. Él mismo aclara que es un experimento y no la dirección oficial de KDE.
Otros: Turborepo de Vercel la usa para su TUI, devenv para manejar shells, OrbStack la integra en su producto, ghostty-web es una compilación WASM con API compatible con Xterm.js y hay una ola de herramientas "agénticas" de código como herdr y cmux.

Hay bindings de la comunidad para Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, Java y otros. Hashimoto sostiene que hoy más gente usa una terminal impulsada por libghostty que Ghostty, la aplicación, "por un múltiplo muy grande". Como reconoce en una nota, las cifras son aproximadas: la mayoría de los proyectos no reportan uso.

Mi lectura

Durante años, cada IDE, terminal web y multiplexor escribió su propio emulador, con sus propios bugs. La apuesta de libghostty es la contraria: un solo motor bien probado (la página de estabilidad menciona fuzzing con AFL++ en máquinas dedicadas 24/7) y que cada quien ponga su interfaz encima. El caso de JetBrains demuestra que funciona en algo con millones de usuarios.

Lo que me parece más útil para quien lee esto no es otra terminal bonita, sino lo que habilita sin ventana: probar TUIs de forma automática, grabar sesiones de servidor y reproducirlas, o darle a un agente una lectura confiable de lo que hay en pantalla en vez de adivinar entre secuencias de escape. Con el ABI estable y los paquetes oficiales, eso ya se puede construir sin vendorizar un fork.

Lo que conviene vigilar: el formato de snapshots no está cubierto por la promesa de estabilidad, y la biblioteca se encarga del estado, no del render. Si quieres una terminal completa, el dibujo, las fuentes y la integración siguen siendo trabajo tuyo, aunque el ejemplo Ghostling arma una en unas 1,500 líneas de C.

No lo probé; todo esto sale del anuncio de Mitchell Hashimoto, la documentación oficial en lib.ghostty.org y los anuncios de los proyectos citados.