If you've updated IntelliJ, PyCharm or GoLand to 2026.3 and opened a terminal tab, you've used Ghostty's terminal engine. You didn't install it. JetBrains did that for you.

So what is libghostty? It's the terminal emulation core of the Ghostty terminal, pulled out into a C library you can embed in your own app. On November 6, 2026 Mitchell Hashimoto shipped libghostty-vt 1.0 and declared that "the library itself and the C ABI are now stable." The same post says the terminal in JetBrains IDEs now runs on it. Citing a JetBrains report, he puts that at over 12.5 million active users, and concludes that more people now use a libghostty-powered terminal than use the Ghostty app, "by a very large multiple."

I think the library matters more than the app does, so that's what this post is about: what libghostty-vt does, what it leaves to you, who already ships it, and how to start using it.

What libghostty-vt does, with a C example

You feed it bytes and it gives you terminal state. Those bytes are whatever a program would write to a terminal: text, escape sequences, cursor movement, colors. The library parses them and keeps the screen, the styles and the scrollback. You can query that state or format it back out.

This is the hello world from lib.ghostty.org, trimmed of comments:

#include <stdio.h> #include <string.h> #include <ghostty/vt.h>  int main(void) { GhosttyTerminal terminal; ghostty_terminal_new(NULL, &terminal, 80, 24); const char *text = "Hello, \x1b[1;32mworld\x1b[0m!\r\n"; ghostty_terminal_vt_write(terminal, (const uint8_t *)text, strlen(text)); GhosttyFormatter formatter; ghostty_formatter_terminal_new(NULL, &formatter, terminal); uint8_t *buf = NULL; size_t len = 0; ghostty_formatter_format_alloc(formatter, NULL, &buf, &len); fwrite(buf, 1, len, stdout); putchar('\n'); ghostty_free(NULL, buf, len); ghostty_formatter_free(formatter); ghostty_terminal_free(terminal); return 0; } 

That prints Hello, world! as plain text. The bold green is in the terminal state, and the default formatter just doesn't emit it. The NULL arguments select the default allocator.

The original example has a comment I'd keep in mind: the bytes "can come from anywhere: a pty, a network connection, a recording." Besides the terminal itself, the 1.0 build includes input encoding, search, selection and the Kitty graphics protocol (with Wuffs doing the image decoding). The docs say the parsers and encoders "work without a terminal," so you can use them on their own.

What it doesn't do: no renderer, no fonts, no PTY

Nothing in the announcement or the docs front page describes a renderer, a font stack or a PTY layer. You're getting the VT core. Spawning the shell, drawing glyphs and wiring up the window are your job. The Ghostling demo is a basic terminal built on it in about 1,500 lines of C, which gives you a rough idea of how much code that is.

It also does very little behind your back:

  • It creates no threads.
  • It allocates only through an allocator you can replace.
  • At runtime it needs nothing but libc, and with SIMD disabled it builds freestanding. That's how it runs on bare-metal RISC-V and ARM.

That last point is what makes it embeddable. A library that spins up its own threads and pulls in a font stack won't fit into an IDE, a web page and a microcontroller, and libghostty-vt fits into all three.

Who already ships libghostty

From the announcement:

Project What it uses libghostty for
JetBrains IDEs The integrated terminal
Vercel Turborepo Rendering TUI task output
devenv Driving shells
Antithesis Fuzzing TUI programs (found bugs in btop and others)
Ghostel Terminal in Emacs
ghostty-web WASM build with an Xterm.js-compatible API
OrbStack Embedded terminal
herdr, cmux Built on it

The awesome-libghostty list tracks over 100 projects.

Two names need an asterisk. The Neovim PR that swaps libvterm for libghostty-vt is approved but not merged; the maintainers are waiting for a tagged release. If it lands, it closes a 10-year-old issue about reflowing scrollback on resize. KDE developers are experimenting with a Konsole replacement built on it (the linked project is Kwi), but it's still an experiment and Konsole hasn't shipped it. If you see "Neovim and KDE adopted Ghostty" anywhere, it's ahead of the facts.

Performance and WASM size: whose numbers are these?

There are two WebAssembly builds, one optimized for speed and one for size. The small one is under 1 MB with every feature enabled. Feature flags can compile out input encoding, search, selection and Kitty graphics, which roughly halves the module. The compiled-out functions stay exported and return GHOSTTY_UNSUPPORTED, so your bindings don't break. The same flags work on native targets too.

On density, 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 used dash because bash "used far more RAM than libghostty-vt." So at that scale the memory ceiling came from the shells, and the terminal library was the cheap part.

These are the author's own measurements on his own setup. The post doesn't compare throughput against libvterm, xterm.js or anything else. His claim that Ghostling has "more features and better performance than just about any terminal that existed in 2025" is also his own, and his footnote scopes "performance" to parsing throughput and memory use. On Hacker News, one commenter who tried it as Mudlet's ANSI decoder reported "no measurable speed gain in tests." I'd benchmark against your own workload before believing anyone's chart, his included.

Why 1.0 matters: a stable C ABI

This release is about a compatibility promise more than new code. 1.0 follows semver with strict ABI guarantees, and the design backs that up:

  • Every object is an opaque handle.
  • Values go through enum-keyed getters and setters, so adding a value doesn't add a symbol.
  • Building against newer headers than the library you link returns GHOSTTY_UNSUPPORTED instead of crashing.
  • The few non-opaque structs carry their size or reserved padding, and enums are pinned to int.
  • CI checks the ABI with libabigail against a committed baseline on Linux, and on ELF platforms exported symbols are versioned.

Packaging got the same treatment. libghostty has its own release cycle and tarballs, separate from the app, with a signed source tarball plus a dependencies tarball for offline builds. You get a SONAME, pkg-config files and a CMake package config, and the build honors --prefix, DESTDIR and lib64. It's MIT licensed, and the author says there's no copyleft code anywhere in the dependency tree.

The criticism on both Lobsters and HN is about Zig. The C ABI shields consumers from Zig churn, but building the library still needs a specific Zig version, and people expect that to hurt Debian, especially if Neovim switches. It's a fair complaint, because a stable ABI doesn't help a distro that can't build the thing.

How to start using libghostty

  1. Read the docs at lib.ghostty.org: Installing, Your First Terminal, Building Blocks, API Conventions, and the Stability page for what a release is allowed to change.
  2. Pick a binding if you're not writing C. There are community bindings for Rust, Go, JavaScript, Swift, Python, .NET, Elixir, Dart, Java and more. Check the awesome list for maturity before you depend on one.
  3. If you're shipping xterm.js in a web app, look at ghostty-web. The Xterm.js-compatible API is meant to make that swap cheap.
  4. If you test TUIs, start here. Pipe your program's output into ghostty_terminal_vt_write, format the screen, and assert on it. That's roughly what Antithesis did when they found the btop bugs.
  5. Supported targets in CI include Linux (glibc and musl), macOS 13+, iOS 13+, FreeBSD, Windows x86_64, Android and wasm32. Windows arm64, WASI, illumos, 32-bit x86 and bare metal (riscv32, thumb) build but aren't tested, so treat those as "should work."

The Ghostty app is a nice terminal in a crowded field. The library is the new part, because nobody has to write their own VT parser to get modern terminal behavior any more. An IDE vendor with millions of users picked it over maintaining its own, and I'd bet other vendors with homegrown terminals are taking notes.

If you could embed a real terminal in any app you work on, where would you put it? And if your answer is "nowhere, terminals belong in terminals," tell me why.

Sources