Libghostty 1.0 Is Here: A Stable C ABI for Embedding Ghostty's Terminal

Libghostty hit 1.0 on November 6, 2026, and the headline is boring in the best way: the C library that powers Ghostty's terminal engine now has a frozen, stable ABI. Mitchell Hashimoto, the HashiCorp co-founder who built Terraform and Vault before starting Ghostty in 2023, spent roughly five years getting here. The library is already running inside JetBrains IDEs (12.5 million active users), it has a verbally-accepted path into Neovim, and it's the terminal core behind KDE's Konsole replacement, Vercel's Turborepo, and OrbStack.

If you've never heard of libghostty, here's the one-line version: it's the terminal emulation engine, split out of the Ghostty app, so other programs can embed a real terminal instead of writing their own VT100 parser badly for the fourth time.

What is libghostty, actually?

Ghostty the app is a GPU-accelerated terminal emulator written in Zig. Libghostty is the part of Ghostty that actually understands terminal escape sequences, cursor state, scrollback, and rendering, packaged as a standalone library with a C API on top. Hashimoto has said in past interviews that libghostty was the real goal the whole time, and the macOS and Linux apps were always meant to be the flagship demo proving the library works in production.

That matters because terminal emulation is one of those problems everyone reimplements badly. Every IDE, every code editor, every build tool with a "run command" panel, and now every coding agent CLI needs something that can parse ANSI codes and track cursor position. Historically they either shell out to a half-finished parser or embed something like libvterm. Libghostty's pitch is: stop doing that, link against the thing that already handles real-world terminal output correctly, including all the edge cases vim, tmux, and htop throw at it.

What's actually new in 1.0?

The specific library shipping 1.0 is called libghostty-vt. The "vt" means it's just the virtual terminal piece: sequence parsing and state tracking, not rendering. It's MIT-licensed and needs nothing beyond libc at runtime, not even libc on some targets.

Here's what the ABI freeze actually guarantees, per Hashimoto's release notes:

That's a real semantic versioning commitment, not a "we'll try" note in a README. It's also exactly the kind of boring, disciplined API design that makes distro maintainers comfortable packaging something. And that's the actual unlock here: once Debian, Fedora, or Homebrew can package a library without worrying it'll snap ABI next month, every downstream project stops vendoring its own copy.

Who's already using it?

This is the part that got people's attention on Hacker News. Adoption isn't hypothetical:

• JetBrains IDEs — powers the built-in terminal across all JetBrains products, 12.5 million active users
• Neovim — a pull request replacing the long-standing libvterm dependency with libghostty-vt has reportedly been verbally accepted
• KDE — the in-progress Konsole successor uses it
• Vercel Turborepo — uses it for terminal output in its build UI
• OrbStack — the macOS container/VM app
• Ghostel — an Emacs terminal mode that users on Hacker News say clearly beats vterm and eat on performance
• 100+ community projects, with bindings already written for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, and Java

That's a wide spread for a library that didn't have a stable ABI a year ago. The pattern across almost all of these is the same: get rid of a bespoke or half-maintained terminal parser and replace it with one that's already handled millions of real sessions in Ghostty.

How fast is it, really?

Hashimoto's own stress test is the number people keep quoting: 10,000 active terminal instances on a 4-core Linux box with 8GB of RAM. He had to switch his test harness from Bash to Dash because Bash itself was eating too much memory per spawned shell to hit that count. That's a synthetic benchmark, obviously, and your mileage with real shells running real programs will vary. But it's a believable number given Ghostty's existing reputation for low per-terminal overhead, and it's a very different story from Electron-based terminal UIs that can eat triple-digit megabytes per tab before you've typed anything.

The WebAssembly build is the other eyebrow-raiser: under one megabyte, fully featured, no Emscripten dependency. Hashimoto posted a browser demo of terminal key encoding running on the Wasm build back in October, which is the same code path that ships in the native app.

Platform coverage is broad too: Linux (glibc and musl), macOS 13+, iOS 13+, FreeBSD, Windows, Android, WebAssembly, plus bare metal and illumos support for people doing weirder things.

Wait, what's Rex?

If you've seen Hashimoto's name pop up next to something called Rex and gotten confused, you're not alone, it came up repeatedly in the Hacker News thread. Rex is a separate, paid product Hashimoto is building on top of this foundation, aimed at agentic terminal workflows with AI built in. Ghostty stays free, open source, and MIT-licensed, it's the technical proof that libghostty works in a real shipping app. Rex is where the commercial AI features live. The split is deliberate: the core terminal engine stays a public good anyone can build on, and the business sits on top of it rather than inside it.

That framing lines up with why libghostty matters for the AI coding tool wave specifically. Every coding agent that runs commands in a terminal, from Claude Code to competitors, either shells out to a real terminal emulator or fakes it with a crude pty wrapper. A stable, embeddable terminal library is exactly the kind of plumbing that agent-adjacent tooling has been missing.

What are people saying about it?

The Hacker News thread (50399933) is mostly positive, with one top comment summarizing the vibe: "this is how you write a library." The praise is specifically about the API discipline, not just the performance numbers. A few threads of actual criticism showed up too: Ghostty itself is still Linux and macOS only, so people wanting Windows-native terminal gains from libghostty have to wait on a third party to wire it up (and some already have, see the Windows entry in the platform list above). Several commenters also compared Ghostty to iTerm2 directly, noting iTerm2 still wins on raw feature count (tmux integration, vertical tabs) while Ghostty wins on speed and sane defaults out of the box.

Should you actually use it?

If you're building a terminal UI, an IDE panel, or a coding agent CLI that needs to render real terminal output and you're currently maintaining your own ANSI parser, yes, go look at this. A 1.0 ABI guarantee means you can link against it today without getting burned by a breaking change six months from now. That's not a small thing for anyone who's been bitten by an "experimental" library flipping its API mid-project.

If you're just a terminal user picking your daily driver, libghostty 1.0 doesn't change much for you directly, it's plumbing, not a feature. But every app you use that adopts it gets a small invisible win: fewer terminal rendering bugs, better protocol support, and one less thing for that app's maintainers to hand-roll badly. JetBrains already shipped that win to 12.5 million people without most of them noticing.

Watch