Mitchell Hashimoto released libghostty-vt 1.0 on November 6, 2026, giving developers who embed Ghostty's terminal engine a stable C ABI. That promise matters when an application and its terminal library are upgraded separately: the project now commits to keeping programs built against one 1.x release working with later 1.x releases. The release announcement makes compatibility and distribution packaging the central changes.
There is a limit worth checking before adopting it. The stability policy excludes the snapshot byte format from that compatibility promise. This report examines the announcement and documentation; we haven't built the release or tested an embedding application.
What the compatibility promise covers
An ABI, or application binary interface, determines how compiled code calls into a library. Libghostty-vt's policy for the 1.x series allows additions such as functions and enum values, while prohibiting removal, resizing, reordering or changes to existing types. Behavior changes get a separately named function, with the old function deprecated until the next major version.
That gives an application maintainer a clearer upgrade boundary. It doesn't mean any library version can satisfy any program. The same documentation distinguishes the headers used at compile time from the library loaded at runtime. Its compatibility example requires matching major versions and a runtime minor version at least as recent as the headers. If you dynamically link the library, that is a useful check to retain.
Snapshots need their own treatment. The functions that save and load them belong to the stable C ABI, but the bytes they exchange may change in any release, according to the snapshot exception. Developers planning to retain terminal snapshots should therefore assess format compatibility separately from whether their application still links.
Packaging gets an independent release cycle
Hashimoto says libghostty has a release cycle separate from the Ghostty application. Each release supplies a signed source tarball and a companion dependency tarball, allowing distributions to build offline. The announcement's packaging details also specify shared and static libraries, headers, pkg-config files and CMake package configuration. These are concrete provisions for maintainers integrating the library into existing build systems.
The library's job is narrower than the desktop application. You feed it the bytes a program writes, and it exposes terminal state, including the screen and cursor. The documentation's introductory example writes a color escape sequence, then extracts plain text through a formatter. It opens no GUI window and uses no real pseudo-terminal. That's a documented example, not output we reproduced, and it helps locate the remaining integration work: a host application must connect the engine to its own input, output and display.
The next useful check is distribution packaging. Hashimoto says Neovim maintainers were waiting for a tagged release before merging their approved libghostty-vt replacement for libvterm. That is a pending integration in the November 6 account, not a completed migration. Whether that change lands, and how distributions package the dependency, will show how the 1.0 compatibility promise translates into routine upgrades.