Glonce

Ghostty's libghostty-vt reaches 1.0 with a stable C ABI

toolsThe Glonce editorsHacker News🔥81Glonce rating81Impact70Novelty80Relevance85Surprise50Players60Credibility90

Mitchell Hashimoto, who started the Ghostty project in 2022, announced libghostty-vt 1.0. It is a portable, high-performance C library for terminal emulation, extracted from the core of Ghostty. He says the 1.0 label means both the library itself and its C ABI are now stable.

He contrasts this with a little over a year ago, when he wrote that libghostty was coming. Back then the Zig module had just been merged, the C API did not exist, and nobody but Ghostty consumed it. Now, he writes, the C API is a complete terminal emulator, it runs in production across hundreds of products, free and commercial, and it has an enforced ABI stability policy.

Adoption is the first argument. The terminal in JetBrains IDEs, previously JediTerm, now runs on libghostty, so every IntelliJ, PyCharm and GoLand user has a libghostty-powered terminal. Based on a JetBrains report, Hashimoto puts that at over 12.5 million active users. Neovim has an approved pull request replacing libvterm with libghostty-vt, which among other things closes a 10-year-old issue about reflowing scrollback on resize; maintainers are waiting for a tagged release so distributions can package the dependency separately. Other users he lists: KDE developers experimenting with a Konsole replacement, Vercel's Turborepo (task output in its TUI), devenv (driving shells), Antithesis (fuzzing TUI programs, which found real bugs in btop and others), Ghostel for Emacs, ghostty-web (a WASM build with an Xterm.js-compatible API), OrbStack, and newer terminals and agentic coding tools such as herdr and cmux. Community bindings exist for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, Java and more, and the awesome-libghostty list tracks well over a hundred projects. He says more people now use a libghostty-powered terminal than use the Ghostty application, by a very large multiple, though he notes the numbers are rough because most consumers do not report usage.

On ABI stability, 1.0 means semantic versioning and strict compatibility promises, so packagers can package it and developers can link to it dynamically. Every object is an opaque handle. Hundreds of values go through a small set of enum-keyed getters and setters, so new values need no new symbol. Programs built with newer headers and linked against an older libghostty get GHOSTTY_UNSUPPORTED results rather than crashes or undefined behavior. The few non-opaque structs carry their size or reserved padding, and enums are pinned to int as far as the C standard allows. CI checks every change with libabigail against a committed baseline on Linux, and against golden type manifests on macOS and WebAssembly. On ELF platforms every exported symbol is versioned, so the dynamic loader refuses a mismatched library by name.

Packaging gets proper tooling. Libghostty has its own release cycle, separate from the Ghostty application, and its own tarballs holding only what it needs. Each release publishes a signed source tarball plus a dependencies tarball with every Zig package, so a distribution can build offline. The build installs shared and static libraries with a proper SONAME, headers, pkg-config files and a CMake package config, honors --prefix, DESTDIR and lib64, and keeps debug info by default. It is all documented in PACKAGING-LIBGHOSTTY.md.

libghostty-vt is MIT licensed. The bundled dependencies are permissive: simdutf and Google Highway for SIMD, a compact Unicode table for grapheme data, and Wuffs for image decoding in the Kitty graphics protocol. There is no copyleft code in the dependency tree and no C++ standard library dependency, and every dependency is listed in a machine-readable manifest with version, SPDX license and hash. A build flag lets a distribution link the system simdutf or Highway instead. A footnote corrects the original post's claim of "not even libc!": the default build links libc, because the SIMD paths use it and the default allocator is malloc. With SIMD off the library is freestanding, which is how it runs on bare-metal RISC-V and ARM targets.

Portability: CI builds and fully tests a set of platforms (unit tests plus all examples), and builds a second set with known users but no automated tests. Artifacts per platform: Linux and FreeBSD get a shared library with versioned symbols, a static library, headers, pkg-config and CMake files; macOS and iOS get a dylib plus an XCFramework covering macOS, iOS and the iOS simulator; Windows gets a DLL with a .pdb, an import library and a static library, built with the GNU ABI but linkable from MSVC programs; Android gets an NDK-built shared library with 16 KB page size support, as Android 15+ requires. WebAssembly comes in a speed-optimized and a size-optimized build, and the small one is under a megabyte with every feature enabled. For a read-only viewer, input encoding, search, selection and Kitty graphics can be compiled out with a build flag, which roughly halves the module; every function stays exported and returns GHOSTTY_UNSUPPORTED. The flags work on every target, not only WASM.

On resources, the library creates no threads and allocates only through a customizable allocator. Hashimoto 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 for the shells because bash used far more RAM than libghostty-vt and would not fit in the 8 GB budget.

Looking ahead, he says you can now build a terminal in about 1,500 lines of C with more features and better performance than just about any terminal that existed in 2025, and most today. A footnote defines "features" as the terminal protocols and sequences understood, and "performance" as parsing throughput and memory usage. The project will focus on stability while implementing as many terminal protocols as exist, with options to enable or disable them. Docs, examples and downloads are at lib.ghostty.org. A footnote also states the post was completely hand-written with no AI assistance.

Key facts

  • libghostty-vt 1.0, a portable MIT-licensed C terminal-emulation library extracted from Ghostty, declares both the library and its C ABI stable, with semantic versioning.
  • CI enforces the ABI policy: libabigail against a committed baseline on Linux, golden type manifests on macOS and WebAssembly, and versioned symbols on ELF platforms.
  • The terminal in JetBrains IDEs now runs on libghostty; Hashimoto cites a JetBrains report of over 12.5 million active users, and says the awesome-libghostty list tracks well over a hundred projects.
  • Neovim has an approved pull request swapping libvterm for libghostty-vt, waiting on a tagged release so distributions can package it.
  • In a test, Hashimoto ran 10,000 active terminals with live shells on a 4-core, 8 GB Linux server; the small WebAssembly build is under a megabyte with every feature enabled.

Why it matters

Terminal emulation is hard to get right, and Hashimoto's argument is that projects should embed one well-tested engine instead of each writing their own. A stable ABI is what lets that happen at scale: distributions can package the library once and programs can link to it dynamically without breaking on upgrades. He frames the 1.0 as the point where libghostty stops being an internal piece of Ghostty and becomes shared infrastructure, citing JetBrains, Neovim, Turborepo and others. He also argues that a bug reported by one embedder improves the library for all of them.

Who it affects

Terminal and TUI developers, IDE and editor makers, and anyone building tools that need to render terminal output, from agentic coding tools to read-only web viewers. Distribution packagers are a stated target, since the release brings signed tarballs, an offline dependencies tarball, license manifests and standard build files. End users are affected indirectly: according to the author, more people already use a libghostty-powered terminal than use the Ghostty application itself.

How to use it

The library is MIT licensed, and docs, examples and downloads are at lib.ghostty.org. It builds for Linux, FreeBSD, macOS, iOS, Windows, Android and WebAssembly, with an XCFramework for Xcode and Swift Package Manager and community bindings for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, Java and more. Packagers should read PACKAGING-LIBGHOSTTY.md, shipped in the tarball. Build flags let you compile out features such as input encoding, search, selection and Kitty graphics, link the system simdutf or Highway, or turn off SIMD for a freestanding build. Hashimoto says a terminal can now be built in about 1,500 lines of C.

How solid is it

The post is a first-party announcement by the library's author, so performance and feature claims are his own. Its concrete checks are described in detail: CI builds and fully tests a stated set of platforms, with libabigail and golden-manifest ABI checks on every change. The 12.5 million figure is JetBrains' reported active users, taken from a JetBrains report cited by the author, not a measured count of libghostty terminal sessions; he calls his usage numbers rough. The 10,000-terminal run is a single test on one 4-core, 8 GB server.

Risks and caveats

The earlier "not even libc!" claim was wrong for the default build, which links libc; only the SIMD-off build is freestanding. Neovim's change is approved but not yet merged, and no merge date is given. The KDE Konsole replacement is described only as an experiment. The "more features and better performance than just about any terminal" claim is the author's, limited by his own footnote to protocols understood, parsing throughput and memory use. The post names no benchmark figures comparing libghostty-vt with other terminals. A second set of platforms is built in CI but not tested automatically.

“Every bug any libghostty-vt embedder reports makes everyone else in the ecosystem better.”

— Mitchell Hashimoto, Libghostty 1.0