libghostty 1.0: Ghostty's terminal engine now has a stable ABI and is ready for packaging

Mitchell Hashimoto published libghostty-vt 1.0 on November 6, the C library for terminal emulation that was extracted from Ghostty's core. The important part isn't the round number: as of this release, the library and its C ABI are stable, follow semantic versioning, and ship with everything a Linux distribution needs to package them. That turns something that was already inside the terminal of JetBrains IDEs, in an approved Neovim PR, and in a KDE experiment into a dependency anyone can dynamically link without worrying that the next update will break it. If you build web terminals, console tools, session recorders, or agents that have to "read" what a TUI displays, it's worth knowing what it brings.

What libghostty-vt is

According to the official documentation, libghostty-vt is a headless library: you feed it the bytes a program writes and it exposes the terminal state (the screen, the cursor, the scrollback). It doesn't draw anything. What you do with that state is up to you: render it with the GPU, show it on a web page, save it as a recording, or hand it to a program that needs to know what's on screen.

The documentation itself lists what it's for: terminal emulators and multiplexers, web terminals and remote sessions, session recording and playback, test harnesses for TUI applications, and agents or automations that read what a TUI displays. It's MIT licensed.

The example on the main page fits on one screen: you create an 80×24 terminal with ghostty_terminal_new, write bytes with color sequences to it using ghostty_terminal_vt_write, and read what ended up on screen with a formatter.

What 1.0 means

In his announcement, Hashimoto explains that 1.0 means two things: the library follows semantic versioning and has strict ABI compatibility promises, so packagers can distribute it and programs can link to it dynamically with confidence.

The stability page turns this into concrete rules. A program compiled against a 1.x version keeps working with any later 1.x. A minor version can only add functions, types, enum values, or fields at the end of a struct with a declared size. Nothing is removed, resized, reordered, or changed in type. If something changes behavior, it ships as a new function with a different name and the old one is marked GHOSTTY_DEPRECATED until the next major version.

There is one documented exception: the byte format of snapshots is versioned separately and is not covered by the ABI promise, so it can change in any release. If you plan to save snapshots to disk to reopen them later, take note.

How they hold this up, according to the announcement:

Every object is an opaque handle, and the hundreds of values that are read or written go through a handful of getters and setters indexed by enum. That way values can be added without creating new symbols.
A program with newer headers linked against an older library gets GHOSTTY_UNSUPPORTED instead of a crash or undefined behavior.
Enums are pinned to int across all compilers, as far as the C standard allows.
CI checks every change with libabigail against a baseline on Linux, and against type manifests on macOS and WebAssembly. On ELF platforms every exported symbol is versioned, so the dynamic loader rejects an incompatible version by name instead of failing mysteriously later.

Diagram: bytes from a PTY, an SSH connection, or a recording go into libghostty-vt, which maintains the terminal state; the host program takes care of drawing. Below, projects that already use it

Packaging, dependencies, and platforms

Version 1.0 comes with its own release cycle, separate from Ghostty the application, and its own tarballs containing only what the library needs. Hashimoto details that each release publishes a signed source tarball and another one with dependencies containing the Zig packages, so a distribution can build offline. The installation leaves shared and static libraries with their SONAME, headers, pkg-config files, and CMake configuration, and it respects --prefix, DESTDIR, and lib64. It's all documented in PACKAGING-LIBGHOSTTY.md.

On dependencies, the announcement says that at runtime it only needs libc, and that without the SIMD paths it can be built fully freestanding, which is how it runs on RISC-V and ARM without an operating system. It builds in simdutf and Google Highway for SIMD (without libc++), a compact Unicode table, and Wuffs for decoding images from the Kitty graphics protocol. There is no copyleft code in the entire tree, and every dependency appears in a manifest with version, SPDX license, and hash.

The platforms that are built and tested in CI, according to the announcement:

Platform	Architectures
Linux (glibc and 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)

It is also built, without automated tests, for bare metal (riscv32, thumb), WASI, Windows arm64, illumos, and 32-bit x86. The WebAssembly version comes in two flavors, one optimized for speed and one for size; the small one weighs less than a megabyte with everything enabled. If you only need a read-only viewer, you can strip out input encoding, search, selection, and Kitty graphics with build flags, which according to Hashimoto cuts the module roughly in half.

The detail that matters to anyone running servers

The library doesn't create threads, allocates memory only through an allocator you can customize, and, according to its author, uses little compute and little memory. Hashimoto says he ran 10,000 active terminals, each with a live shell producing output, on a Linux server with 4 cores and 8 GB of RAM. He had to use dash because bash consumed far more RAM than the library itself and wouldn't fit in 8 GB.

This is a test by the author, not an independent benchmark, and I didn't reproduce it. But for anyone offering terminals in the browser, admin consoles, or sandboxes for agents, the order of magnitude is what counts: the bottleneck stops being the emulator.

Who already uses it

Hashimoto devotes a good part of the announcement to the users it already has:

JetBrains. Since version 2026.3, the integrated terminal in their IDEs runs on libghostty, replacing JediTerm, according to the JetBrains blog. The company explains that libghostty handles sequence parsing and terminal state, while the IDE keeps doing the drawing. In practice, that brings the Kitty keyboard protocol (Shift+Enter now inserts a line break in tools like Claude Code or Codex) and almost 50 control sequences that JediTerm ignored or handled wrong.
Neovim. It has an approved PR that replaces libvterm with libghostty-vt and closes a 10-year-old issue about scrollback reflow on resize. According to Hashimoto, the maintainers were waiting for a tagged release so distributions can package the dependency separately, and 1.0 should unblock it.
KDE. Eike Hein introduced Kwi, an experimental terminal for Plasma built on libghostty-vt and Qt Quick. He himself clarifies that it's an experiment and not KDE's official direction.
Others: Vercel's Turborepo uses it for its TUI, devenv uses it to manage shells, OrbStack integrates it into its product, ghostty-web is a WASM build with an API compatible with Xterm.js, and there's a wave of "agentic" coding tools like herdr and cmux.

There are community bindings for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, Java, and others. Hashimoto claims that today more people use a libghostty-powered terminal than Ghostty the application, "by a very large multiple." As he acknowledges in a note, the numbers are approximate: most projects don't report usage.

My take

For years, every IDE, web terminal, and multiplexer wrote its own emulator, with its own bugs. libghostty's bet is the opposite: a single well-tested engine (the stability page mentions fuzzing with AFL++ on dedicated machines 24/7) and everyone puts their own interface on top. The JetBrains case shows it works in something with millions of users.

What I find most useful for anyone reading this isn't yet another pretty terminal, but what it enables without a window: automatically testing TUIs, recording server sessions and replaying them, or giving an agent a reliable reading of what's on screen instead of guessing among escape sequences. With the stable ABI and the official packages, that can now be built without vendoring a fork.

What's worth watching: the snapshot format isn't covered by the stability promise, and the library handles state, not rendering. If you want a full terminal, drawing, fonts, and integration are still your job, although the Ghostling example puts one together in about 1,500 lines of C.

I haven't tried it; all of this comes from Mitchell Hashimoto's announcement, the official documentation at lib.ghostty.org, and the announcements of the cited projects.