Mitchell Hashimoto

I strongly believe there are entire companies right now under heavy AI psychosis and its impossible to have rational conversations about it with them. I can't name any specific people because they include personal friends I deeply respect, but I worry about how this plays out.

I lived through the great MTBF vs MTTR (mean-time-between-failure vs. mean-time-to-recovery) reckoning of infrastructure during the transition to cloud and cloud automation. All those arguments are rearing their ugly heads again but now its... the whole software development industry (maybe the whole world, really).

It's frightening, because the psychosis folks operate under an almost absolute "MTTR is all you need" mentality: "its fine to ship bugs because the agents will fix them so quickly and at a scale humans can't do!" We learned in infrastructure that MTTR is great but you can't yeet resilient systems entirely.

The main issue is I don't even know how to bring this up to people I know personally, because bringing this topic up leads to immediately dismissals like "no no, it has full test coverage" or "bug reports are going down" or something, which just don't paint the whole picture.

We already learned this lesson once in infrastructure: you can automate yourself into a very resilient catastrophe machine. Systems can appear healthy by local metrics while globally becoming incomprehensible. Bug reports can go down while latent risk explodes. Test coverage can rise while semantic understanding falls. Changes happens so fast that nobody notices the underlying architecture decaying.

I worry.

Ghostty is getting automatic scrollback compression, resulting in 70 to 90% less physical memory usage. It happens incrementally when idle, so it had no measurable effect on IO throughput. I'm not aware of any other mainstream terminal that does this. Demo video: https://www.youtube.com/watch?v=ZVAnhimPh8k

The gains let us increase the default scrollback limit from 10MB to 50MB, because on average a full scrollback will still compress smaller than the prior limit. More history, for free. ("Unlimited", disk-paged history is on the roadmap too)

Let's talk about cool implementation details, cause this was fun.

First, the data structure and memory layout ("PageList") I wrote two years ago finally pays off! One of its traits is that screen memory is backed by a linked list of page-aligned, page-sized (or page-multiple-sized) blocks.

Because each block is page-aligned and page-sized, we can use madvise to discard its physical backing while keeping the virtual address space reserved. Compressed pages therefore disappear from resident memory, but decompression is still guaranteed because the address space remains valid and we simply fault new pages back in as needed.

We use the same trick for our memory pools, too. Unallocated pool pages don't count as resident memory, saving another couple of MB per terminal.

This functionality is also available to libghostty-vt consumers via new ghostty_terminal_compress APIs. The consumer decides when the appropriate time to compress is and the APIs advise on compressability.

Our family grew yesterday to 2 kids! A healthy baby boy and healthy wife post labor. ❤️

Libghostty can now be used to fuzz TUIs, thanks to Oskar and Antithesis. They already found bugs in multiple including btop. I always imagined libghostty would be useful for testing TUIs, super happy to see this is both practical and valuable. https://wickstrom.tech/2026-04-30-bombadil-terminal-experiment.html

This is another example of where speed matters! "Why does Ghostty need to be so fast?"

Well, if you're running hundreds or thousands of unit tests that each use a clean in-memory terminal, you want that to be fast. If you're fuzz testing and trying to push an unlimited amount of data through a terminal, you want that terminal to be fast.

So many people got hung up on "why does my terminal _GUI_ need to be fast" without connecting one more dot and realizing the GUI is only fast if the core is fast, and the core being fast unlocks a hell of a lot more.

Like this.

It's so insanely disrespectful for an AI agent to talk to real people without consent or at least disclosure. This is the type of stuff I'm hugely supportive of government regulation. The FCC must expand the definition of robocalling and TCPA-style regulation to online AI.

Ghostty just surpassed Terraform in stars (my previous most-starred project I started). It took Terraform 12 years to reach 48K. Ghostty did it in 1 year. It's bigger than Terraform in active usage, too. I take it personally when people doubt I can outdo my past.

I can take credit for starting both, but not for ongoing development (for the successes and failures). Neither project is a solo endeavor. I'm still extremely actively involved with Ghostty, but there's also a team of a dozen maintainers. Terraform I stepped back and stopped working on it directly like 6 or more years ago.

I consider stars a vanity metric and I don't care about it at all except in this narrow case. I'm a super competitive person (in general), but particularly/especially against my past self. There's no one I like "winning" more against than my past. So, this is my one exception for caring about stars.

A couple months in and Vouch in Ghostty is working extremely well. Our PR quality is up and the rate of PRs has not gone down at all. Getting a vouch is easy, and the minimal barrier to entry easily filters most. Look at this 5min interaction that saved hours of future anguish.

Ghostty is now indisputably the fastest terminal emulator at IO throughput, by a very large margin. On ASCII, Unicode, and CSI tests, Ghostty is more than 2x (double!) faster than any other leading "fast" terminal. These changes are directly in libghostty, too, so everyone wins.

time cat 150MB_ascii.txt:

• Ghostty nightly: 575ms
• Ghostty 1.3.2: 1.5sec
• Alacritty: 1.2sec
• Kitty: 1.7sec
• Warp: 3.8sec
• iTerm2, Terminal: stopped after 60s

time cat 150MB_unicode.txt (mixed languages):

• Ghostty nightly: 536ms
• Ghostty 1.3.2: 1.22sec
• Alacritty: 1.05s
• Kitty: 1.35s
• Warp: 3.4s
• iTerm2, Terminal: stopped after 60s

DOOM-Fire-Zig (an IO test):

• Ghostty nightly: 842fps
• Ghostty 1.3.2: 532fps
• Kitty: 485fps
• Alacritty: 593fps
• Warp: 577fps
• iTerm2, Terminal: 60fps (yes, 60)

To quickly address the "cat speed doesn't matter" naysayers: this is a direct test of how many bytes/second you can push through a terminal. It doesn't cover just "read big file" but also "how much can a TUI do". The tests above test various shapes of inputs (plain ascii, unicode/wide chars, csi-heavy loads, etc.). IO throughput is incredibly important.

Most of these improvements apply to libghostty-vt consumers too, so any libghostty-based terminals will instantly see huge throughput improvements by simply upgrading (ABI compatible).

I'll cover the exact improvements in a blog post in the future. These results are the result of 6 separate optimizations.

From empty repo to a functional minimal standalone terminal based on libghostty in less than 2 hours, presenting Ghostling! ~600 lines of C and you get extremely accurate, performant, and proven terminal emulation. Every program on earth that needs any subset of terminal functionality and can now easily get it.

https://github.com/ghostty-org/ghostling

Feature list:
- Resize with text reflow
- Full 24-bit color and 256-color palette support
- Bold, italic, and inverse text styles
- Unicode and multi-codepoint grapheme handling (no shaping or layout)
- Keyboard input with modifier support (Shift, Ctrl, Alt, Super)
- Kitty keyboard protocol support
- Mouse tracking (X10, normal, button, and any-event modes)
- Mouse reporting formats (SGR, URxvt, UTF8, X10)
- Scroll wheel support (viewport scrollback or forwarded to applications)
- Scrollbar with mouse drag-to-scroll
- Focus reporting (CSI I / CSI O)
- And more. Effectively all the terminal emulation features supported by Ghostty!

The libghostty C API is not formally released, but I built this project to prove its ready to go. 😎 https://github.com/ghostty-org/ghostling

libghostty for Rust! Some Ghostty maintainers came together and made a really high quality Rust crate in front of libghostty-vt. The repo includes a full port of Ghostling (full terminal in a single Rust file!). The API is beautiful. https://github.com/Uzaaft/libghostty-rs/

Love this post by Antirez on developing Redis Array support. Its a great showcase of thoughtful AI usage and how AI can empower even the best developers while still producing high quality work. https://antirez.com/news/164

Huge W for Zig from the Kimi K2.6 announcement. https://www.kimi.com/blog/kimi-k2-6

Libghostty now fully exposes the Kitty Graphics Protocol. This may be the first native embeddable terminal to support this. I added a full Kitty graphics renderer to Ghostling (the libghostty demo project) in ~270 LoC.

Ghostling PR: https://github.com/ghostty-org/ghostling/pull/13
C API Docs: https://libghostty.tip.ghostty.org/group__kitty__graphics.html
C PR: https://github.com/ghostty-org/ghostty/pull/12145
Zig PR: https://github.com/ghostty-org/ghostty/pull/12144

Ghostty GUI has supported Kitty graphics since version 1.0 and I believe we have one of the most comprehensive Kitty graphics protocol implementations besides Kitty itself.

For example, we support unicode placeholders which lets the protocol work in tmux, which is -- I think -- only supported by Ghostty besides Kitty.

Now this robust, real world proven implementation is available to anyone embedding Ghostty. Enable it with a few lines of code and build a renderer with a couple hundred as shown in Ghostling. Amazing.

Btw, for Ghostling (libghostty demo), I didn't write a single line of... anything. Agents wrote 100% of everything you see incl. Nix flakes, CI jobs, etc. I reviewed every line of code manually and constantly nudged the agents in the right direction. I used a mix of Opus+Codex.

I went from empty repo to functional terminal that could run Neovim with keyboard, mouse events in ~80 minutes. Pretty sweet.

Note: libghostty itself is of course heavily hand written (with agent assistance all over too, though). I'm just talking about Ghostling itself.

Even for CI setup (GitHub actions), I had the agent sit in a `gh` CLI loop watching failures, fixing, pushing, fixing, pushing, etc. Doing GHA with agents are the only way I stay sane, honestly.

I just re-read the full main.c from top to bottom and I'm very satisfied. I would've done some things differently but if an engineer I worked with PRed all this, I would've accepted it. Its good enough.

Some people have pointed out the commenting is over the top and indicative of AI. This is actually my personal comment style, and I told the agent to comment heavily (its even in the AGENTS.md, look for yourself!). Anyone who has worked with me professionally or in OSS knows that I comment everything all the time.

One of my favorite things is that libghostty really forces us to better our core. For example, we recently made stream processing infallible (sending arbitrary user input into Ghostty). External input can't be trusted, so it must never cause our core to fail. Now it doesn't.

Zig's error system makes this easy and obvious. Previously, errors would bubble up from handlers through to the stream processor. The practical effect is that if a sequence failed, it could cause partial processing of terminal sequences. I never heard of this happening in practice, but the API allowed it.

Now, we force all error handling to happen at the handler level. If an error happens, the handler must deal with it and guarantee that the terminal is in a coherent state. The stream processor WILL move forward.

This was critical because when designing the C API, we needed to determine what possible errors could be returned from `ghostty_terminal_vt_write`. On reflection of the Zig API, I realized... none can. No possible errors can (or should) occur. I was able to fix this through the type system in Zig and now the C API is a `void` return type with zero allocation. Hurrah!

PR: https://github.com/ghostty-org/ghostty/pull/11468

Ghostty 1.3.1 is now out, most importantly fixing the phantom mouse drag/select/scroll events on macOS. This release also includes improvements to AppleScript support and a couple dozen bug fixes. https://ghostty.org/docs/install/release-notes/1-3-1

The libghostty C API is functionally super stable, because its the same core thats been powering Ghostty for years. But the ABI is not yet stable. In this video, I talk about what an ABI is and the plans we have to ensure libghostty ABI compatibility once we tag a release. https://www.youtube.com/watch?v=VAGNcyo8hqs

There's such a deep misunderstanding out there about tmux and zellij and I get so many absurd issue reports demonstrating that. So many don't realize that using them is like running a Windows VM on your Mac device, and complaining to Apple that iCloud sync isn't working from the VM.

They are super powerful and have their use and I am happy to support them in any way I can. I'm not anti-multiplexer, but I wish more people understood the architecture a bit more.

libghostty is FAST! Here's a look at vtebench with Ghostling. Reminder: Ghostling is single threaded + blocking render + blocking IO. The point is, you get comparable speed to the fastest dedicated terminals in an embeddable lib! Had to pull out iTerm2 because its so slow.

Warning: Ghostling is purple in the first chart but green in the second. Sorry for the confusion.

Also, the Unicode results are not correct for Ghostling because Ghostling is getting stuck on worst case "glyph not found" since we only embed one font. So the results are wildly skewed poorly. A result integrator of libghostty would have significantly better performance here.

I haven't fully profiled the libghostty C API yet. I think there will be obvious wins to be had. This was just my first check and I am very happy with the results.

Comparing libghostty/Ghostling to dedicated terminals is a bit unfair, since dedicated terminals can get away with a lot of performance tricks to go faster that a reusable general purpose terminal emulation library can't do as well. But, I wanted to show this comparison to show that despite that, libghostty still does SUPER well, comparable, and even best-in-class in a couple categories.

This is all to say, every embedded terminal experience on earth can be nearly as fast as the fastest native desktop terminals. There are no more excuses. The tide will rise!

Full Ghostling source (single ~600 line C file): https://github.com/ghostty-org/ghostling

I shook off some of the dust and wrote Go for the first time in 3 years and built some libghostty bindings for Go. Its cgo but since libghostty can be fully static and only depends on libc, mixing cgo + Zig as the C compiler lets you cross compile easily. https://github.com/mitchellh/go-libghostty

We now build binary "xcframework" packages for libghostty on every commit for macOS and iOS. They're available via GitHub releases and blob storage. Just drop them into Xcode or in a Package.swift and you're ready to go. No Zig headaches. No build step. https://github.com/ghostty-org/ghostty/pull/12149

I've contributed a patch to the venerable simdutf library by @lemire@mastodon.social so that it can now be used with no dependency on libc++ at all. Libghostty is already updated so it now only depends on libc. I blogged about it here: https://mitchellh.com/writing/simdutf-no-libcxx

The Building Block Economy. https://mitchellh.com/writing/building-block-economy

The most effective way to build software and get massive adoption is no longer high quality mainline apps but via building blocks that enable and encourage others to build quantity over quality.

Updated the libghostty-vt CMake files to make cross-compilation as easy as one (or a few lines). Since libghostty only depends on libc/c++ and Zig bundles libc when used as a c/c++ compiler, you can get full cross-compilation easily. The Zig toolchain is paying huge dividends!

This would've been true even if libghostty wasn't written in Zig, its just a fun coincidence that its written in Zig too. But Zig the C/C++ compiler on its own is amazing (a frontend for clang but with a ton of extra work done by the Zig team to make cross compilation easy).

More details in this commit: https://github.com/ghostty-org/ghostty/commit/7127abfe285014c62bc1f9b24d4e038af7f94afa

The libghostty Zig and C API as well as the Ghostling demo application have all been updated to support "effects", or the ability for libghostty to now handle side effects (bell, titles, etc.) and responses (size reports, etc.).

Here's a devlog about it: https://www.youtube.com/watch?v=X2d0CxwrJJQ

Links to examples below:

Zig PR: https://github.com/ghostty-org/ghostty/pull/11787
C PR: https://github.com/ghostty-org/ghostty/pull/11814
Ghostling commit: https://github.com/ghostty-org/ghostling/commit/be529b5f76e894afcc5ccbf34bb53d1b83cf6667

With Ghostty 1.3 out the door, my focus is now on completing the libghostty C API (Zig API is already complete). Just added the groundwork for exposing full terminal state and formatting it as plain text, VT, or HTML. https://github.com/ghostty-org/ghostty/pull/11506

This is all just writing C ABI compatible APIs to the already-existing and heavily real-world proven Zig APIs. For example, the formatter API is how our copy/paste works (the HTML format is the source of truth for Ghostty 1.3's rich text copy). And of course, the terminal API is literally the core Ghostty terminal emulator!

The major API I need to do next is the "render state" API. Formatters are made for infrequent point-in-time snapshots; they aren't particularly performant. The render state is a stateful API for building high performance render loops and its what the Ghostty GPU renderer is built on top of. Will come soon...

Simdutf released v9 which includes the ability to use it without libc++ at runtime (via a cleanup of my work). Really glad I could help get this upstream, a big win for all libghostty-vt users as we eliminate a major dependency for free. https://github.com/simdutf/simdutf/pull/962

Devlog about the recently added Kitty graphics protocol support to libghostty, highlighting how kept libghostty to zero runtime dependencies, how libghostty is secure by default for the protocol, and showcasing the Ghostling implementation. https://www.youtube.com/watch?v=biZ4HywLxZY&feature=youtu.be

@thejtoken@hachyderm.io been blogging and talking about this stuff for over a year now at least. Been a daily user ever since.

@HugeGameArtGD@mastodon.gamedev.place Sorry a quick follow up, the example I gave here is good with more detail:

I built (not slop) the plugin system and SDK. I think it's good. But I don't know. I launched a handful of ralph-loop agents overnight while I slept to produce plugins with a variety of examples.

I woke up, the plugins worked (mostly). The code was terrible. But I could immediately find two things:

1. Common patterns a lot of the plugins repeated that I could think about whether made sense in the formal SDK (cleaned up)

2. Using the plugins in a working but hypothetical environment to really "feel" if this was directionally good or if there was something lacking. For example, one thing I took away was that plugin installation was way too burdensome when you had a lot you wanted to get up and running with quickly.

Clean that up, work on that throughout the day, plan my next evening. Rinse, repeat.