Libghostty 1.0: ABI estable y 12,5M de usuarios en JetBrains

Libghostty 1.0 ya tiene ABI estable, y el terminal de JetBrains, con 12,5 millones de usuarios activos, corre sobre ella desde antes de que fuera oficial.

Mitchell Hashimoto, creador de Ghostty, extrajo el motor de emulación de la aplicación para que cualquier programa en C, Rust o Python pudiera reutilizarlo sin escribir su propio parser de secuencias de escape. Con la 1.0, esa librería (libghostty-vt) deja de ser un experimento interno y pasa a tener compromisos formales de compatibilidad binaria.

TL;DR

• Libghostty 1.0 llegó el 6 de noviembre de 2026 con ABI de C estable y versionado semántico para Ghostty.- El terminal de JetBrains (IntelliJ, PyCharm, GoLand) corre sobre libghostty-vt y alcanza 12,5 millones de usuarios activos.- Neovim aprobó una pull request para reemplazar libvterm por libghostty-vt y cerrar un issue abierto hace 10 años.- KDE experimenta con un reemplazo de Konsole, mientras Vercel, devenv, OrbStack y Antithesis ya usan la librería en producción.

Qué es Libghostty 1.0

Libghostty-vt es la librería portátil en C para emulación de terminal que Ghostty extrajo de su propio motor: corre el parser de secuencias de escape, el estado de pantalla y el buffer de scrollback para que otro programa no tenga que escribirlos, y Libghostty 1.0 es la versión que vuelve estable su ABI.

A diferencia de Ghostty, la aplicación de terminal que Hashimoto lanzó en 2022, libghostty-vt no tiene interfaz propia: es el motor que otros programas incrustan, parecido a cómo SQLite es la base de datos que cientos de aplicaciones empotran sin que el usuario final sepa que está ahí.
JetBrains migró su terminal a libghostty-vt: 12,5 millones de usuarios.

Qué pasó

La librería de terminal de Ghostty no inaugura la adopción masiva: la confirma. JetBrains ya migró el terminal integrado de IntelliJ, PyCharm, GoLand y el resto de sus IDE a libghostty-vt, y según cifras de la propia empresa eso representa más de 12,5 millones de usuarios activos. Neovim tiene una pull request aprobada que reemplaza libvterm por libghostty-vt y de paso cierra un issue abierto desde hace diez años sobre cómo reflowear el scrollback al cambiar el tamaño de la ventana; los mantenedores esperaban justo este tag para que las distribuciones empaqueten la dependencia por separado.

• KDE: experimenta con un reemplazo de Konsole construido sobre la librería.- Vercel: usa libghostty-vt para renderizar la salida de tareas en la TUI de Turborepo.- devenv: la aprovecha para manejar shells.- Antithesis: la usó para hacer fuzzing de programas de terminal y encontró fallas reales en btop y otros.- Ghostel: la lleva a Emacs.- ghostty-web: es el build en WASM con una API compatible con Xterm.js.- OrbStack: la incrusta como producto comercial.

Encima de esa lista hay agentes de código como herdr y cmux, construidos directamente sobre la librería en vez de escribir otro emulador, y bindings de comunidad para Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart y Java. La lista awesome-libghostty ya rastreaba más de cien proyectos al 6 de noviembre de 2026. Según Hashimoto, hoy más gente usa una terminal con libghostty-vt por debajo que gente que usa Ghostty como aplicación, por un margen amplio.

Contexto e historia

Hashimoto arrancó Ghostty en 2022, y desde entonces la pregunta más repetida sobre el proyecto fue por qué construir otro emulador de terminal en lugar de usar uno existente. Él mismo respondió esa duda en un post anterior titulado "libghostty is coming", pero el argumento de fondo cambió de foco: ya no hace falta explicar la intención, alcanza con mostrar la adopción real.

Hace poco más de un año, en noviembre de 2025, la foto era distinta. El módulo en Zig recién se había fusionado al repositorio principal, la API en C todavía no existía, y el único consumidor de la biblioteca en C de Ghostty era el propio Ghostty.

Hashimoto usó entonces un bug de JediTerm, el emulador de terminal de los IDE de JetBrains, como ejemplo de lo difícil que es escribir un parser de VT100 correcto. Un año después, ese mismo bug quedó obsoleto: JetBrains reemplazó JediTerm por libghostty-vt, y el ejemplo que ilustraba el problema se convirtió en el cliente más grande de la solución.
Neovim prepara reemplazar libvterm por libghostty-vt tras diez años de issue abierto.

Detalles técnicos

Lo que hace estable a una librería en C no son las funciones nuevas: es lo que no puede romperse cuando alguien actualiza de la versión 1.0 a una posterior sin recompilar todo lo demás.

flowchart TD
    A["Ghostty (Zig)"] --> B["libghostty-vt (ABI en C)"]
    B --> C["JetBrains IDEs"]
    B --> D["Neovim"]
    B --> E["Bindings: Rust, Go, Python, Swift"]
    subgraph Consumidores
    C
    D
    E
    end

El diseño sigue un patrón clásico de librerías en C longevas, parecido al de SQLite o libcurl. Cada objeto es un handle opaco: el código externo nunca ve los campos internos, solo un puntero. Los cientos de valores que un programa puede leer o escribir pasan por un conjunto pequeño de getters y setters indexados por enum, así que agregar un valor nuevo no requiere agregar un símbolo nuevo a la librería. Un programa compilado contra headers más nuevos, pero enlazado contra una versión más vieja, recibe un resultado GHOSTTY_UNSUPPORTED en vez de un crash o un comportamiento indefinido.

Las pocas estructuras que no son opacas cargan su propio tamaño en bytes, de forma que se les puedan agregar campos después, o reservan relleno para lo mismo. Los enums quedan fijados a int en cada compilador, hasta donde el estándar de C lo permite, para evitar que un cambio de tamaño rompa el layout en memoria entre plataformas.

¿Cómo se verifica que el ABI no se rompió entre dos releases, en lugar de confiar en la palabra del mantenedor? El equipo corre libabigail en cada cambio contra una línea base de símbolos committeada en el repositorio para Linux, y contra manifiestos de tipos de referencia para macOS y WebAssembly. En plataformas ELF, además, cada símbolo exportado queda versionado, así que el cargador dinámico del sistema operativo se niega a cargar una librería que no coincide por nombre, en vez de fallar de forma críptica más adelante.
AspectoAntes de Libghostty 1.0Con Libghostty 1.0Compatibilidad binariaSin garantías: cada build podía romper a los consumidoresABI estable con versionado semántico y chequeo automático en CIEmpaquetadoSin tarballs oficiales ni manifiestos de licenciasTarball firmado más tarball de dependencias para build offlineConsumidoresSolo Ghostty, la aplicaciónJetBrains, Neovim (pendiente), KDE, Vercel, OrbStack y más de cien proyectosBindings de otros lenguajesInexistentes o informalesRust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart y Java
El release también trae la infraestructura de empaquetado que antes faltaba: cada versión publica un tarball de fuente firmado junto con un tarball de dependencias que incluye cada paquete de Zig en el mismo layout de caché que usa el propio compilador, así una distribución puede compilar la librería sin tocar la red. El build instala las librerías estática y dinámica con el SONAME correcto, headers, archivos pkg-config y un paquete de configuración para CMake, y respeta las variables --prefix, DESTDIR y lib64 que usan los empaquetadores de distribuciones. Todo el proceso queda documentado en el archivo PACKAGING-LIBGHOSTTY.md que se incluye en el tarball.

La licencia es MIT, y en tiempo de ejecución libghostty-vt no necesita nada más que libc, incluso se puede compilar en modo freestanding para quien no quiera ni esa dependencia. Entre sus dependencias de compilación están simdutf y Highway de Google para rutinas SIMD, una tabla compacta de datos Unicode para calcular grafemas, y Wuffs para decodificar imágenes del protocolo gráfico de Kitty. Tanto simdutf como Highway se compilan sin libc++, así que la librería tampoco arrastra una dependencia de la biblioteca estándar de C++.

📌 Nota: Libghostty-vt no depende de libc++ ni, en su variante freestanding, de la libc del sistema: todo el runtime queda contenido en la propia librería.

Impacto y análisis

El impacto real no es técnico: es económico. Antes de libghostty-vt, cada aplicación que necesitaba mostrar una terminal (un IDE, una herramienta de CI, un cliente SSH) tenía dos opciones: escribir su propio parser de secuencias de escape desde cero, con todos los bugs que eso implica, o adoptar una librería vieja como libvterm, que no se diseñó para el ritmo de actualizaciones de las terminales modernas, como el color de 24 bits o el protocolo gráfico de Kitty. La librería de Ghostty resuelve ese dilema ofreciendo el motor de una aplicación ya probada en producción, con un contrato de compatibilidad binaria que un empaquetador puede auditar.

La contrapartida es que la estabilidad del ABI es una promesa de compatibilidad binaria, no una garantía de comportamiento idéntico: libabigail detecta cambios de layout y de símbolos, pero no puede demostrar que la semántica de una función se mantiene igual entre versiones. Si una versión futura cambia cómo interpreta una secuencia de escape poco común, el ABI sigue siendo compatible y el programa no va a crashear, pero puede renderizar distinto. Para un IDE con 12,5 millones de usuarios, esa clase de regresión silenciosa pesa tanto como un crash.

Qué sigue

Con el tag 1.0 ya publicado, los mantenedores de Neovim pueden avanzar el merge que reemplaza libvterm: estaban esperando justamente este release para empaquetar la dependencia por separado en vez de vendorizarla dentro del repositorio. El reemplazo de Konsole que prueba KDE sigue en fase experimental, sin fecha de lanzamiento. Y la lista awesome-libghostty va a seguir creciendo mientras más terminales, agentes de código y herramientas de TUI eligen incrustar la librería en vez de escribir la suya propia.

📖 Resumen en Telegram: Ver resumen

Probalo vos: cloná el repositorio de Ghostty y revisá los headers de la release 1.0 de libghostty-vt para ver el ABI estable en código real.

Preguntas frecuentes

¿Qué diferencia hay entre Ghostty y la librería libghostty-vt?

Ghostty es la aplicación de terminal que una persona usa para abrir una ventana y escribir comandos. Libghostty-vt es la librería en C que Ghostty extrajo de su propio motor, pensada para que otros programas la incrusten sin mostrar ninguna interfaz propia.

¿Qué significa que libghostty-vt tenga un ABI estable?

Significa que un programa compilado contra una versión puede seguir funcionando al enlazarse con una versión más nueva de la librería, sin recompilar, porque los símbolos exportados y el layout de memoria no cambian de forma incompatible.

¿Qué proyectos ya usan la librería de terminal de Ghostty?

El terminal integrado de los IDE de JetBrains, Turborepo de Vercel, devenv, Ghostel para Emacs, OrbStack, y agentes de código como herdr y cmux, entre más de cien proyectos listados en awesome-libghostty.

¿Neovim ya reemplazó libvterm por libghostty-vt?

Todavía no está mergeado: hay una pull request aprobada, pero los mantenedores esperaban el tag de la versión 1.0 para empaquetar la dependencia por separado antes de integrarla.

¿En qué lenguajes hay bindings para libghostty-vt?

La comunidad mantiene bindings para Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart y Java, además de la API oficial en C.

¿Libghostty-vt es software libre?

Sí, tiene licencia MIT y en tiempo de ejecución solo depende de libc; incluso se puede compilar en modo freestanding sin esa dependencia.

Referencias

• Mitchell Hashimoto, "Libghostty 1.0": el anuncio original de la versión estable de la librería.- Repositorio de Ghostty en GitHub: código fuente de Ghostty y de libghostty-vt.- Repositorio de Neovim en GitHub: donde vive la pull request que reemplaza libvterm por libghostty-vt.- JetBrains: la empresa cuyos IDE migraron su terminal integrado a libghostty-vt.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.