As a reminder, libghostty is the highly portable, embeddable library that provides core terminal emulation, render state, and more. I always felt that a free, high qualty, lightweight, reusable terminal emulation core would benefit the developer world more than any single GUI application. And that is playing out!
It is and always was my true purpose with the Ghostty project (I said this in my first ever talk about Ghostty!). I've jokingly said many times that Ghostty GUI is just a glorified tech demo for libghostty. That's not fair though, because GUI is great and there are really talented people working on it.
Since I started the project, Ghostty has always gotten people saying "I don't understand why you'd start a terminal emulator today." Well, the answer is libghostty. It's truly unique and its enabling something special (imo!).
Highlights of libghostty since 6 months ago (none of the below was true 6 months ago):
- Libghostty has nearly 100% coverage of all of Ghostty's core (and you can compile with flags to remove any of these features for size/safety): https://libghostty.tip.ghostty.org/
- Libghostty now builds and is tested (in CI) for: Apple (macOS, iOS, visionOS), Windows (MSVC and GNU), Linux, FreeBSD, Android, WebAssembly, and freestanding (i.e. direct on hardware with no OS).
- Libghostty has bindings in pretty much every popular programming language: C, Zig, Go, Swift, Python, Rust, .NET, etc.
- Libghostty's memory requirements have dramatically shrunk to enable the portability above. There's still work to do but a single empty terminal now takes 90% less memory. And at scale I've proven 10,000 active (input/output happening) terminals on a Linux server with 4 cores and 8 GB of RAM.
- Libghostty powers all JetBrains IDE terminals, over 12.5 million active users. https://blog.jetbrains.com/platform/2026/10/jetbrains-termin...
- Libghostty is the most popular core behind the wave of venture-backed "agentic" terminals and editors, such as Herdr, cmux, and many others.
- Libghostty is being discussed and has been verbally accepted to replace the terminal core in Neovim: https://github.com/neovim/neovim/pull/39773 (work still to be done)
- Libghostty powers a really popular and powerful terminal emulator for emacs (Ghostel): https://github.com/dakra/ghostel
- Libghostty's speed is used by Antithesis to fuzz popular terminal programs and has directly led to hundreds of bug fixes sent upstream to programs such as tmux, btop, shells, and other terminal emulators. :)
- And so much more: https://github.com/Uzaaft/awesome-libghostty
Libghostty is really successfully turning into the tide that raises all boats. As it becomes more popular, Ghostty itself gets more performant and stable, and so does everyone else. It is also a vehicle for delivering modern terminal emulation to the widest source possible.
I plan on tagging libghostty 1.0 in the next few months and declaring ABI stability at that point!
I don't mind if my English isn't entirely idiomatic and all my sentence constuctions aren't "by the book" correct. I want to write, and I want anyone reading my writing to know that it's the product of thinking and editing that's unique to me.
Erm, this really depends on the human I think.
But I can't do this any longer. I'm tired, boss.
here's another:
"when i am sad, i have to remind myself that sadness i feel so as to qualify me to enjoy and feel joy."
this is not mine, it's a paraphrase of a poem verse from Mawlawi (aka Rumi in the West).
Turns out they were quoting Rumi from K Pop Demon Hunters and I indeed am uncultured.
The one I am mentioning is جلال الدین محمد بلخی رومی So the sufi saint.
It's been a quite smooth experience, and I remain very excited about the lib. I believe you are successfully setting the standard. Big congrats for your 1.4.0!
This looks like a great opportunity for the KDE project to rethink its terminal application for the modern age. Text-based config would be amazing though not sure how it'll fit into KDE Frameworks etc.
Periodically, I would run into TUI issues and think "I should just finally do it," especially around wanting to replace tmux in general. But I knew from experience the long tail of annoying issues for terminals that it's more time consuming than it appears, and so I again never bothered.
Thanks for the good work to raise all boats :)
I tend to move away from terminal emulation towards GUI when I can (and using custom remote protocols somewhat inspired by arcan), but TUI is still useful for a while. I actually had a need for a good terminal emulation library for the fallback TUI/pty attachment for non-gui programs for my supervisor, so I'll try out libghostty.
(a couple of us working on packaging libghostty and ghostty proper to for Guix at the moment )
That's really cool, but I'm drawing a blank; what's it used for? Embedded terminal something?
Just took our TinyBubbles framework (TinyGo + BubbleTea) and added TinyGhostty [1]. We had all the parts in place.
The web demos use Booba [2] and our ghostty-web fork, so that's libghostty embedding another libghostty. The source cells are composited into our TinyHAL device abstraction. The UX is presented using "Booba Actions" which abuses OSC 7501.
This describes the differences between TinyGhostty and go-libghostty [3]. I've run other demos on embedded devices, but not this one yet. The fonts could use some love.
[1] https://nimbleterminal.github.io/TinyBubbles/?demo=tinyghost...
[2] https://github.com/NimbleMarkets/go-booba
[3] https://github.com/NimbleTerminal/TinyBubbles/tree/main/tiny...
I am really impressed. When I had read your original comment, I literally shouted oye! (meaning woah) because of how interesting it felt. Glad that I can see the demo as well.
But aside from the fun little demo, what are the real use cases that we can think of as well.
here are some that I have thought of
1. SSH'ing into a terminal (VPS) or being able to view what the AI agents are doing on that VPS and controlling them very thinly in your pocket.
2. I have a slight dream that I'd like to chip in but I always wanted to create something like monkeytype but on embedded-hardware. Something which can just plug to TV's and people can connect a keyboard and start to type.
3. Or another idea but being a book reader and having it connect to some library resource
(2) & (3) for the underdeveloped regions.
Maybe (1) can be good as well and could very well be a small computer terminal which can teach/help the underdeveloped regions.
I live in India and I see it first hand how genuinely just want to create some extremely minimalist software on extremely cheap hardware to make funding of them easier and more scalable.
This also makes the constraints work good as one of the govt's basically spent a lot of money providing mid/high end tablets to every children and it turned out to be quite catastrophic because although it was kiosked because it was just intended to watch videos or read resources.
Children paid people to crack it and then started using instagram on it. My mother is a govt. teacher and she strongly thinks that it was a waste of resources and even the parents of the children and local village meeting committees think so as well. I remember reading some local news articles about villages conducting meetings on how to prevent their children from such instagram addiction so quickly after the tabs were given.
I would like to hope that maybe someday someone creates the more optimal solution to the problems that I discussed and libghostty comes handy to the situation. Thanks for making it and have a nice day :-D
It's a pleasure reading your posts.
Wanted to add too that I can't wait for xterm to eventually support libghostty, you've been super supportive providing feedback!
But if you run nix you could give it a whirl: https://github.com/KritR/ghostty-kms
And right afterwards you write that not only it is the case, but the change is very recent !
Any interest in moving console typography past the 80's, since computers are fast now?
I do not know if you read my initial commment, but MacOS Terminal (native app) has this feature. And it is not a terminal multiplexer like tmux or what you proposed.
https://ghostty.org/docs/config/keybind/reference#toggle_qui...
keybind = global:cmd+ctrl+alt+shift+t=toggle_visibility
overall I have had better experience using `toggle_visibility` to show/hide Ghostty for hotkey style window.Last time I checked it didn't work on Linux (or I couldn't make it work on my setup, I don't remember). It seems it still has some limitations but better than before.
Someone willing to distribute ghostty has to pull in a whole programing language stack just for it, ghostty seems to be the most important project written in zig so far.
For the definition of portable that matters to me, this is the least portable possible, if it was written in almost any other language it would have been more portable. And yes, this all goes away once zig is onboarded to all distros, then it becomes "empirically portable", but we're not there yet.
PS.: "Portable" meaning which CPU architectures are supported is not a very useful meaning of the word for me, even though it's more accurate, it says nothing about the ability to actually build and run it in different OSes.
That’s implying a lot more than I think is the case for Zig.
Zig itself is a very lean and independent executable. It’s just one binary. Statically linked on Linux I believe. It’s even moving toward removing LLVM dependence.
I don’t know of any other language that aims to be as portable as Zig, including C itself. Of course, not all of those goals have been realised yet, but at this stage I don’t think there’s much preventing portability from Zig’s part itself, other than more architectures supported in its own compiler backend. And I suppose a 1.0 release would make it easier to get the compiler more widely distributed.
* With some UB herbs and spices
Zig is also a C compiler
Here’s an example of Zig building some C code:
hello.c
> #include <stdio.h>
>
> int main(int argc, char **argv) {
> printf("Hello world\n");
> return 0;
> }
$ zig build-exe hello.c -lc
$ ./hello
> Hello worldZig has its own compiler backend. With limited arch support of course. Only used in debug modes for now.
I think the most interesting part is they rely on WASM for bootstrapping so all you need to make to bootstrap Zig anywhere is a WASM interpreter (if I understand correctly).
it is all open source: https://github.com/hotaisle/hotaisle-website
I personally avoid using the terminal as much as possible b/c the whole things feels very archaic/fragile/baroque - but the central idea seems great and I'd love a modern take on it
Turns out that the warts are the incorporation of the lessons learned. For this reason, just before Wayland fulfills its destiny and becomes an immaculate replacement for X11, a new generation of developers will determine Wayland's codebase is too complex to comprehend and must be rewritten from scratch.
There is no reason why programs input/output can't be schema'ed, consumed and piped in a type-safe manner. And why there can't be a better standard than bash for simple scripts.
But it is really hard to pull this kind of thing off unless you redesign most of the common tools by scratch and do so through a committee and somehow push it down people's throat through strict platform control.
No need to push it to people. Do it for yourself and create your community around it.
Also no need to do it from scratch. It’s just the interface part that needs to be rewriten.
Although not necessarily advertised as such, I've been successfully using alacritty in several projects injecting terminals into things both serious and silly.
I use Alacritty and GNOME Terminal. I don’t have a great reason for not using or trying Ghostty other than I have a minor aversion to Zig. (Again, not a great reason and arguably a not good reason)
When you say you've proven, are you hinting at use of formal verification?