Mitchell Hashimoto

A Terminal Protocol for Program Status (OSC 7501)

2026-10-06T00:00:00+00:00

I wrote a specification for a new terminal escape sequence: OSC 7501, the Program Status Protocol. It lets any program tell the terminal what it's doing: idle, working, waiting on the user, finished, or failed, and why.

For example, here is how Terraform could indicate that it is blocked waiting for user input, with the message "Apply 3 to add, 1 to change, 0 to destroy?" (base64-encoded). A terminal (or any other tool running Terraform) could show this information however it feels appropriate: a notification, an inbox, a status icon, etc.

ESC ] 7501 ; state=blocked:kind=permission:app=terraform:msg=QXBwbHkgMyB0byBhZGQsIDEgdG8gY2hhbmdlLCAwIHRvIGRlc3Ryb3k/ ESC \

This post covers why I think this protocol needs to exist, why the existing approaches aren't good enough (especially for coding agents), and how the protocol works.

This is a completely generic, terminal-native specification and protocol. It emerged from my work on Superlogical and Ghostty but the specification has no product-specific functionality or language. It is designed as an idiomatic, well-formed specification that any terminal developer will find familiar.

The Problem

Long-running work is common in terminals: builds, deployments, package upgrades, data processing, and, more and more today, coding agents. These programs alternate between working on their own, waiting on the user, and finishing. Meanwhile, users usually go off and do something else and want to know when the work finishes or needs them.

Aspects of this problem have been solved in various ways going back decades. For example, some terminals monitor the active foreground process and have features to notify when it changes. Or, they wait for some time period of "quiet" (for various definitions) output. The specification also lists the reasons why existing sequences aren't enough.

Ultimately, I felt there wasn't a cohesive, interaction-agnostic, generic solution to this problem that conveyed progress, blocking, completion, and trees of tasks. And it wasn't possible to cobble together pre-existing sequences to achieve it robustly, either.

Singling Out "Agentic Inboxes"

Don't care about AI, LLMs, etc.? Skip this section. The problem is generic and applies in a compelling way without bringing in AI. It's particularly nasty with AI so I want to call it out, but if you don't care about any of that, just skip this.

It's now increasingly common for people to run many long-running agents for any number of reasons: background research, issue monitoring, bug fixing, large features, etc. Each one works for a while and then stops to ask for permission, ask a question, or report it's done.

From this, a new category of tool has emerged that I'll simply call the agentic inbox: a single view across every running agent showing which are working, which are done, and which are waiting on you. Herdr, cmux, and Agent Deck are a few examples of hundreds.

Without a dedicated protocol, they solve the agent status problem in two ways: heuristics and non-terminal APIs.

Heuristics

The first approach is to guess by reading the screen or the window title and matching it against known patterns.

Herdr is a good example because it does this well and documents it openly. Its detection manifests are TOML rules that classify an agent as idle, working, or blocked. Here is the first of 16 rules for Claude Code:

[[rules]]
id = "osc_title_working"
state = "working"
priority = 1100
region = "osc_title"
visible_working = true
# Braille covers <= 2.1.227; half-circles are the 2.1.228 busy spinner.
regex = ['^[\x{2800}-\x{28FF}\x{25D0}-\x{25D3}] ']

Claude Code is considered "working" if its window title starts with a Braille spinner character or, as of version 2.1.228, a half-circle one. The history of that file shows ten changes in three months for just Claude Code.

This isn't a criticism of Herdr. Its maintainers are doing the best possible job with the tools available. But it demonstrates well the benefit a unified protocol would have.

Non-Terminal APIs

The second approach is to have the program report its own state through an inbox-specific, out-of-band API such as Herdr's socket API or cmux notify. This is better than heuristics in some ways, because the program that actually knows its state is the one reporting it. But every program has to integrate with every inbox separately, and a local socket doesn't work over SSH or from within a container without extra bridging. The pty already works across all of this.

The Program Status Protocol

OSC 7501 is a terminal native answer to this problem. The program reports its own state directly via the pty that it always has, using a format that is safe to send everywhere (well-behaved terminals ignore unknown OSCs).

The body of the sequence is a list of key=value pairs separated by :. The only required key is state, which is one of:

`state`	Meaning
`idle`	At rest, waiting for the user's next instruction.
`working`	Running. May include a `progress` percentage.
`done`	Finished. The result is ready and the user hasn't seen it yet.
`blocked`	Can't continue until the user does something. `kind` says what (`permission`, `question`, or `auth`) and `msg` says why.
`error`	Failed and stopped.

Optional keys include app, a stable machine-readable program name like cargo or claude-code, and msg, a single human-readable line encoded as base64.

Programs that run several things at once can report multiple records using hierarchical ids. A deploy tool can be working at the root while us-east pushes an image at 40% and eu-west is blocked waiting for approval to deploy to production. Both are true at the same time, and the terminal decides what to show. A clear state removes records.

Here's a complete integration for a shell script to wrap rsync to participate in this protocol:

status() {
  printf '\e]7501;state=%s:msg=%s\e\\' "$1" "$(printf '%s' "$2" | base64 | tr -d '\n')"
}
status working "Syncing photos"
rsync -a ~/Photos backup:/photos && status done "Photos synced" || status error "rsync failed"

Trivial to script with plain old POSIX sh. No SDK, no sockets, no environment variables, no JSON. No bias towards specific GUI presentations. No bias to any specific workload (like AI). A well-formed, generic foundation to build functionality above that anyone and everyone can participate with.

The full spec covers the rest: record lifetime, feature detection, terminfo, size limits, and security. It's short. I wrote it all by hand. Please read it.

Implement It

I wrote this specification based on my experience maintaining a terminal emulator for many years now. It is written in a way that is easy for application developers to emit, and easy for terminal emulators to consume and parse.

I've already implemented this protocol twice. We have one implementation in libghostty and I have a parallel implementation in Rex. I've also implemented it as a proof-of-concept in Terraform, Claude Code, Codex, and Homebrew via either plugins or forks. In each case, the implementation was no more than a dozen lines.

I've been in contact with the maintainers of many popular terminal programs and emulators and they've helped review and shape the specification. But if you have any more feedback, I'm happy to hear it.

If you've implemented the specification please let me know via email (mail icon in the footer) and I'll add you to the list of tools that implement this. Thank you.

I'd like us all to stop guessing what programs are doing by reading their screens or process trees. The program already knows. Let's give it a way to tell us!

Superlogical

2026-07-29T00:00:00+00:00

I've started a new company: Superlogical.

I authored 1 the announcement post on the Superlogical homepage, which describes the problem statement and what we're building.2 Read that to learn more. This post is more of a personal statement about what led to this, how it relates to my recent work, and what comes next.

Building for the Love of It

In 2023, after 11 years, I left the company I previously founded.

Since then, my primary focus has been being a mostly full-time dad. I became involved with a lot of philanthropy.3 I wrote a lot on technical topics, sharing as much as I had the time and energy for.

But I never stopped building. Building software is my personal passion, and I continued to learn and build a little every day just for the love of it.

Ghostty

I poured most of that passion into Ghostty. Ghostty started as a personal project I thought I'd throw away 4, but instead grew into a project with millions of daily users, a large community with a wonderful group of core maintainers, and a reusable library powering impactful software as well as fun software.

I have no intention of ever commercializing Ghostty. To solidify this, I donated the entirety of Ghostty to a federally recognized non-profit in 2025. This ownership legally binds Ghostty to the public-benefit purpose it was created to serve. It is now and forever an open building block that everyone can build on and learn from.

Ghostty is much more than just me, I don't want to give the wrong impression! Ghostty is made up of about a dozen core maintainers, almost 50 localization team members, and another dozen community moderators. Some of these people are paid via the non-profit. It is a very healthy open source project made up of a diverse group of talented individuals.

I have had, and continue to have, an immense amount of fun working on Ghostty. And over my years working on it, I became increasingly interested in the problems around the terminal emulator itself. Or, to be purposefully coy, I kept asking “why?” Why is terminal usage more widespread than ever? What continues to drive its growth? At what point does that end? What comes next? Why? Why? Why!

What Comes Next

The answer to these questions leads to Superlogical.

I wasn't searching for a reason to start another company, but I found a problem I wanted to spend years working on, a scope that required a team, and people I wanted to build it with.

Superlogical will begin by shipping a terminal multiplexer. I'm pouring my years of experience building a terminal and studying the potential and limitations of other multiplexers into something new, powerful, and, of course, fast.

My cofounders are some of the most talented people I've ever worked with. They're amazingly accomplished and their work speaks for itself. They're each going to play an equal part in making this something really special. One thing we all share is an uncompromising commitment to well-crafted software and software experiences.

We will build on libghostty exactly as it was designed to be used: as a public building block for terminal applications. Superlogical will consume the same MIT-licensed components available to everyone else, and we will continue to upstream shared terminal work so every libghostty consumer can benefit.

Ghostty itself remains a non-profit; its mission, governance, license, technical goals, and roadmap do not change.

Of course, the terminal multiplexer isn't the entire vision. I'm not ready to share more yet, but you can learn a tiny bit more on the Superlogical website. Sign up for the newsletter for beta access and development updates along the way.5

Oh, and we're hiring!

Footnotes

No AI! Hand-written, real, and authentic. ↩
I realize there is some vaguery and unanswered questions. We have a lot more answers but don't want to just lay it all out in a tome on a landing page. We'll reveal more through updates over time. ↩
My family doesn't publicize most of our philanthropic work. A large majority is non-tech related. ↩
The kind you use to learn something but never publish. We all have dozens (hundreds?) of those in a GitHub graveyard. ↩
We considered very strongly not sharing anything at all until we were ready to ship the product, but devlogs are fun, building in public is fun, and I think this team has proven we can and will ship. ↩

Everyone Should Know SIMD

2026-07-22T00:00:00+00:00

SIMD has a reputation for being complex. I've met many very good software engineers who dismiss it as something too complex to learn or a niche optimization meant for only the highest-performance software, not useful in everyday programming.

I think that's wrong. SIMD can be simple to understand 1, and common "process N values at a time" SIMD code to speed up a naive for loop almost always follows the same general shape. Once you learn the basics, writing SIMD is just about as easy as a for loop. And when it's not, it's usually a good sign to skip it for now.

Every developer should know at least that much SIMD.

This post uses Zig for examples but is a general piece that applies to any programming language. Support for SIMD instructions varies by programming language and I hope that more programming languages expose these generic concepts in the future!

I hate that I have to do this for every post now, but I also want to note this was completely hand-written with no AI assistance.

Table of Contents

Background: What Is SIMD?

If you already know what SIMD is, skip this section.

SIMD allows a CPU to operate on multiple values in parallel. For example, instead of comparing one byte at a time, a CPU can compare 4, 8, or even more bytes with a single instruction.

If you ever see loops like this in your code:

for (byte in bytes) { /* ... */ }
for (character in string) { /* ... */ }
for (value in array) { /* ... */ }

There is an opportunity to use SIMD. SIMD turns those into this:

for (8 byte chunk in bytes) { /* ... */ }

This results in a localized speedup that directly maps to the parallelism: you process data 4x, 8x, or even faster.

The only real requirement for this to pay off is that you need to be regularly processing a large enough number of bytes. If you're doing these for loops across data that is only ever a handful or dozens of bytes, it's not worth it. But if this is iterating over hundreds, thousands, millions of bytes, the payoff will be huge.

That's the basics. Projects such as simdutf and simdjson take this to an extreme and use SIMD techniques that can be difficult to understand. But you do not need to write algorithms like those to benefit from SIMD. The common case is dramatically simpler.

The Common Shape

The common "process N values at a time" SIMD code follows the same five steps:

Broadcast any constants you need and initialize vector accumulators, if any.
Loop over input one vector-width chunk at a time.
Perform the comparison or arithmetic across all lanes in parallel.
Reduce or store the vector result as needed.
Handle the remaining elements with a scalar tail. A scalar tail is just your normal loop from before vectorizing, but it only processes the remainder that doesn't fit into a full vector.

As you do this more and more, you'll begin to naturally decompose every for loop into these five steps and writing SIMD becomes nearly as natural as writing a scalar loop.

A Real Example

Let's look at a real example from Ghostty. We'll look at the scalar implementation, the SIMD implementation, and then map it back to the common shape above.

I have a slice of decoded codepoints that I want to consume until I see a value at or below 0xF (a C0 control character).2 Terminals are mostly plain characters to be printed, so we try to batch all those together. So this loop finds the end of the next printable run as quickly as possible.

The scalar loop is one line:

while (end < cps.len and cps[end] > 0xF) end += 1;

It processes one codepoint at a time. It is easy to understand.

Here is the generic vector version with no CPU-specific intrinsics 3 and no comments. I will explain it in detail later.

if (simd.lanes(u32)) |lanes| {
    const V = @Vector(lanes, u32);
    const threshold: V = @splat(0xF);
    while (end + lanes <= cps.len) : (end += lanes) {
        const values: V = cps[end..][0..lanes].*;
        const greater_than_threshold = values > threshold;
        if (@reduce(.And, greater_than_threshold)) continue;
        const mask: std.meta.Int(.unsigned, lanes) = @bitCast(greater_than_threshold);
        end += @ctz(~mask);
        break;
    }
}

while (end < cps.len and cps[end] > 0xF) end += 1;

12 more lines of code.

This can improve the loop's throughput by up to 4x with ARM NEON (including Apple Silicon), 8x with AVX2 (most modern x86 CPUs), and 16x with AVX-512 (some Intel CPUs and AMD Zen 4 and newer).

In real-world end-to-end throughput from terminal program to finalized terminal state on an AVX2 Intel desktop, this was more like a 5x speedup. You always lose some of the ideal speedup due to the other stuff around the SIMD code, but... that's still 5x!

Okay, now I understand that those 12 lines are going to look really alien to someone not familiar with the concepts. So now let's back up and explain it step by step, mapping it directly to the shape previously mentioned.

Step 1: Broadcast Constants

Let's start with the first three lines:

if (simd.lanes(u32)) |lanes| {
    const V = @Vector(lanes, u32);
    const threshold: V = @splat(0xF);

simd.lanes(u32) is a helper in Ghostty that returns the number of u32 values the target CPU can process at once. These individual values are called lanes. On ARM this returns 4, AVX2 returns 8, and AVX-512 returns 16. If the target doesn't have a vector size we want to use, it returns null and we skip all of this code and do zero SIMD work.

@Vector(lanes, u32) creates the vector type. If lanes is 8, then V is a single value containing eight u32 values that the CPU can operate on in parallel. And so on.

Finally, we need to compare every value to 0xF. A vector comparison requires a vector on both sides, so @splat(0xF) copies, or broadcasts, 0xF into every lane. The result is a vector that looks like this:

{ 0xF, 0xF, 0xF, 0xF, 0xF, 0xF, 0xF, 0xF }

This is step 1: prepare the vector type and broadcast any constants. Some algorithms also initialize a vector accumulator here, but this algorithm doesn't need one.

Step 2: Loop One Vector at a Time

Next, we loop over one complete vector at a time:

while (end + lanes <= cps.len) : (end += lanes) {
    const values: V = cps[end..][0..lanes].*;

If lanes is 8, we only enter the loop when at least eight values remain. Inside the loop, we load those eight values into the vector values. At the end of every loop, end += lanes moves forward by eight values instead of one.

The requirement for a complete vector is important. If only five values remain, we can't load an eight-lane vector. There are various tricks to handle this, but we do the easy thing and handle them via our scalar tail, which I'll explain later in step 5.

This is step 2: load and loop over the input one vector-width chunk at a time. You can see the lane-count speedup here!

Step 3: Perform the SIMD Operation

Now we perform the comparison:

const greater_than_threshold = values > threshold;

Both values and threshold are vectors, so this maps to a vector operation (a literal vector CPU instruction). The one > compares every lane in values to every corresponding lane in threshold. If there are eight lanes, this is equivalent to performing the scalar comparison cps[end] > 0xF eight times, but it does it in one CPU instruction instead.4

The result is another vector with one boolean per lane. Conceptually, it looks something like this:

values:                 { 0x41, 0x42, 0x43, 0x0A, 0x44, 0x45, 0x46, 0x47 }
threshold:              {  0xF,  0xF,  0xF,  0xF,  0xF,  0xF,  0xF,  0xF }
greater_than_threshold: { true, true, true, false, true, true, true, true }

This is the actual SIMD operation. There is no explicit inner loop. The > operator applies to every lane in parallel.

Comparisons are only one example. This could be addition, multiplication, minimum, maximum, or any other operation supported by the vector type. The point is the code still has the same shape.

Step 4: Reduce the Vector Result

We now have a vector of booleans, but the original loop needs to know the location of the first value at or below 0xF.

First, let's handle the common case where every value is above 0xF:

if (@reduce(.And, greater_than_threshold)) continue;

@reduce(.And, ...) combines every boolean using and and returns a single boolean. If every lane is true, we continue and process the next vector. In our example, lane 3 is false, so @reduce returns false and we fall through to find exactly which lane failed.

If any lane is false, then we need to find exactly which lane failed:

const mask: std.meta.Int(.unsigned, lanes) = @bitCast(greater_than_threshold);
end += @ctz(~mask);
break;

@bitCast turns the vector of booleans into an integer with one bit per lane. A 1 bit means the value was greater than 0xF and a 0 means it wasn't. We invert the mask so failed comparisons are 1, and then @ctz counts the number of zero bits before the first failure. That count is the index of the first failing lane.

We add that index to end and break because we found the control character.

Using the same values from step 3, we can see this transformation per lane:

values:                 { 0x41, 0x42, 0x43, 0x0A, 0x44, 0x45, 0x46, 0x47 }
greater_than_threshold: { true, true, true, false, true, true, true, true }
mask:                   {    1,    1,    1,     0,    1,    1,    1,    1 }
~mask:                  {    0,    0,    0,     1,    0,    0,    0,    0 }

@ctz(~mask) counts three zero bits before the first 1, so it returns 3. Adding 3 to end points it at lane 3, which contains 0x0A, the first control character.

This is step 4: reduce the vector result into whatever the original algorithm needs. This is also the step that varies the most between algorithms. A sum might reduce a vector accumulator into a single number. A transform might store the entire vector to an output buffer. Our scan turns the vector into a bit mask so it can find one specific lane.

Step 5: Finish with the Scalar Tail

After the vector loop, we run the exact scalar loop we started with:

while (end < cps.len and cps[end] > 0xF) end += 1;

If the input length isn't an exact multiple of the vector width, this processes the remaining values. For example, an eight-lane vector loop leaves anywhere from zero to seven values for this loop. This is called the scalar tail.

This loop also handles CPUs where simd.lanes(u32) returns null. In that case we skip all of the SIMD code and the scalar loop processes the entire input. The original implementation remains both the fallback and the tail.

That's step 5. It's just the normal loop.

Recap: The Common Shape

Let's map the entire implementation back to the five steps:

@splat(0xF) broadcasts the comparison value into every lane.
The while loop loads lanes values at a time.
values > threshold compares every lane in parallel.
@reduce, @bitCast, and @ctz find the first failed comparison.
The original scalar loop handles the remainder and unsupported CPUs.

The details in step 4 initially take some time to understand, but the overall shape is straightforward. And steps 1, 2, 3, and 5 tend to look nearly identical across completely different algorithms.

Whenever you see a for (byte in bytes), this is the shape you'll map to.

Why Can't the Compiler Do This?

Sometimes it can! Compilers can auto-vectorize simple loops, particularly regular arithmetic loops without complex control flow. You should always compile the scalar version with optimizations and see what your compiler produces before manually writing SIMD.

But compilers are severely limited in what they can auto-vectorize and are in general very poor at it. Auto-vectorization has been an active area of compiler research for decades, and recent research still begins from the observation that production compilers regularly miss vectorization opportunities. This isn't a problem I expect to disappear soon.

More importantly, when this loop matters enough for me to care about a 5x speedup, I want the vectorization to be explicit and predictable. I don't want an unrelated code change or compiler update to quietly turn it back into a scalar loop.

Everyone Should Know SIMD

Every developer should be able to recognize the opportunity and, most importantly, should not be scared of SIMD. If you see a hot loop scanning, comparing, counting, or transforming a large amount of contiguous data, you should be able to imagine processing it a vector-width chunk at a time.

This post demonstrates that these common cases follow a very regular pattern that you quickly get used to. And with good language support, you don't need to know any assembly or CPU-specific quirks to get easy improvements.

Everyone should know SIMD enough to do this.5

Footnotes

Very impressive projects like simdutf and simdjson use extremely complex SIMD tricks to achieve their goals. But this isn't what I'd consider "everyday SIMD." ↩
C0 controls extend beyond 0xF. This is the cutoff Ghostty uses for this specific code path; ESC and other control-sequence handling happens elsewhere. ↩
Generic vectors remove the CPU-specific syntax, not CPU-specific code generation. Zig still lowers these operations to the instruction set enabled for the target. Ghostty falls back to scalar code when it can't choose a supported vector width. ↩
The comparison itself is one vector operation. Loading the vector, reducing the result, and locating the failed lane require additional instructions. The important part is that we're doing multiple comparisons at once. ↩
This post was based on a Lobsters comment I wrote. ↩

Pledging Another $400,000 to the Zig Software Foundation

2026-06-21T00:00:00+00:00

My family is pledging another $400,000 1 to the Zig Software Foundation (ZSF). This brings our total pledged support for ZSF to $700,000, after our initial donation in 2024.

Zig continues to earn my respect as a technical project and as a community. The 2026 devlog shows steady progress on the hard problems of building an excellent language and compiler. I also deeply respect the project's approach to maintainership and community, reflected in initiatives like Loris Cro's Contributor Poker and Zig's AI Ban. That philosophy continues to attract and develop some of the most talented people in open source.

Recently, Zig's strict no-LLM contribution policy became a public topic of discussion again, especially in the context of Bun's Zig fork and Rust rewrite. I have no problem with what Bun did, I think Bun is a great project, and I'm not interested in turning this into a Bun post. Instead, what stood out to me was how quickly people villainized one another. Too much of the conversation lacked empathy and respect for viewpoints different from our own.

I use AI heavily. I've written about my AI adoption journey and shipping real features with AI assistance. I'm also quite vocal about remaining rational about its capabilities and frustrated with its negative impacts on open source.

The point is that I have opinions. Those opinions don't fully align with ZSF's approach. And yet, I have nothing but respect for ZSF: the people, the policies, and the project. Part of what makes the internet and open source great is that projects can be weird and different. They can set unusual boundaries, build their own culture, and pursue quality in ways that won't make sense to everyone.

Zig is exceptional software: ambitious, practical, independent, and unusually serious about quality. Ghostty exists in large part because Zig made it possible for me to build the kind of software I wanted to build. This is why I support Zig.

I'm proud to support Zig and the Zig Software Foundation again. Please consider donating if you can.

Footnotes

$200,000 per year split over two years, the same structure as our 2024 donation. ↩

Ghostty Is Leaving GitHub

2026-04-28T00:00:00+00:00

Writing this makes me irrationally sad, but Ghostty will be leaving GitHub 1.

I'm GitHub user 1299, joined Feb 2008.

Since then, I've opened GitHub every single day. Every day, multiple times per day, for over 18 years. Over half my life. A handful of exceptions in there (I'd love to see the data), but I can't imagine more than a week per year.

GitHub is the place that has made me the most happy. I always made time for it. When I went through tough breakups? I lost myself in open source... on GitHub. During college at 4 AM when everyone is passed out? Let me get one commit in. During my honeymoon while my wife is still asleep? Yeah, GitHub. It's where I've historically been happiest and wanted to be.

Even the annoying stuff! Some people doom scroll social media. I've been doom scrolling GitHub issues since before that was a word. On vacations I'd have bookmarks of different projects on GitHub I wanted to study. Not just source code, but OSS processes, how other maintainers react to difficult situations. Etc. Believe it or not, I like this.

Some might call this sick, but my hobby and work and passion all align and for most of my life they got to also live in one place on the internet: GitHub.

Did you know I started Vagrant (my first successful open source project) in large part because I hoped it would get me a job at GitHub? It's no secret, I've said this repeatedly, and in my first public talk about Vagrant, when I was a mere 20 years old, I joked "maybe GitHub will hire me if it's good!"

GitHub was my dream job. I didn't ever get to work there (not their fault). But it was the perfect place I wanted to be. The engineers were incredible, the product was incredible, and it was something I lived and breathed every day. I still do and consistently have... for these 18 years. Enough time for an entire human to become an adult, all on GitHub.

Lately, I've been very publicly critical of GitHub. I've been mean about it. I've been angry about it. I've hurt people's feelings. I've been lashing out. Because GitHub is failing me, every single day, and it is personal. It is irrationally personal. I love GitHub more than a person should love a thing, and I'm mad at it. I'm sorry about the hurt feelings to the people working on it.

I've felt this way for a long time, but for the past month I've kept a journal where I put an "X" next to every date where a GitHub outage has negatively impacted my ability to work 2. Almost every day has an X. On the day I am writing this post, I've been unable to do any PR review for ~2 hours because there is a GitHub Actions outage 3. This is no longer a place for serious work if it just blocks you out for hours per day, every day.

It's not a fun place for me to be anymore. I want to be there but it doesn't want me to be there. I want to get work done and it doesn't want me to get work done. I want to ship software and it doesn't want me to ship software.

I want it to be better, but I also want to code. And I can't code with GitHub anymore. I'm sorry. After 18 years, I've got to go. I'd love to come back one day, but this will have to be predicated on real results and improvements, not words and promises.

I'll share more details about where the Ghostty project will be moving to in the coming months. We have a plan but I'm also very much still in discussions with multiple providers (both commercial and FOSS).

It'll take us time to remove all of our dependencies on GitHub and we have a plan in place to do it as incrementally as possible. We plan on keeping a read-only mirror available on GitHub at the current URL.

My personal projects and other work will remain on GitHub for now. Ghostty is where I, our maintainers, and our open source community are most impacted so that is the focus of this change. We'll see where it goes after that.

Footnotes

The timing of this is coincidental with the large outage on April 27, 2026. We've been discussing and putting together a plan to leave GitHub for months, and this blog post was written over a week ago. We only made the final decision this week. ↩
To the "Git is distributed!" crowd: the issue isn't Git, it's the infrastructure we rely on around it: issues, PRs, Actions, etc. ↩
This is not the large Elasticsearch outage they had on April 27, 2026. This blog post was written a week before that, so this was a different outage. ↩

Simdutf Can Now Be Used Without libc++ or libc++abi

2026-04-15T00:00:00+00:00

As of this PR, simdutf can be used without libc++ or libc++abi 1.

Simdutf was the final remaining libc++ dependency in libghostty-vt 2. After updating Ghostty to use this new simdutf build, we were able to remove libc++ and libc++abi completely from our dependencies.

The Benefits of Not Depending on libc++

Not depending on libc++ makes a library more portable (embedded, WebAssembly, freestanding environments), simplifies cross-compilation (no target-specific C++ standard library needed), reduces binary size, and can simplify static linking.

As a general purpose, low-level library, simdutf should be as portable and flexible as possible. If a downstream consumer can easily use libc++, great! But if they can't, they shouldn't be blocked from using simdutf since it fundamentally doesn't need it.

libc++ vs libc++abi

There are two parts to extricating a program from libc++.

First, libc++ is the C++ standard library, which provides things like std::vector, std::string, etc. If you import <vector> or even the libc C++ fallbacks like <cstring>, you're depending on libc++.

The sneakier part is libc++abi, which provides the C++ ABI, including things like exception handling, virtual function tables, RTTI, etc. If you use any C++ features that require these, you're depending on libc++abi, even if you don't import any C++ standard library headers at all.

For example, the minimal C++ program below depends on libc++abi because it uses function-local static variables, which require thread-safe initialization that is part of the C++ ABI:

struct Implementation {
    int version;
};

const Implementation& get_impl() {
    static const Implementation impl{1};
    return impl;
}

int main() {
    return get_impl().version;
}

Extricating simdutf from libc++

Let's talk about libc++ first (not the ABI).

simdutf is a C++ library that makes heavy use of the latest and greatest C++ features and though I don't know him personally, Daniel Lemire seems to really love utilizing C++ features to their fullest extent. So, simdutf is very much a C++ project.

For there to be any chance that my changes would be accepted, I had to make sure that the project could continue to use C++ features without it being a headache.

STL Usage

The approach I decided to take was to introduce a stl_compat.h header that centralizes all of the C++ standard library types. In normal libc++ mode, everything in stl_compat.h is a simple include or minimal alias to the corresponding C++ standard library type with no runtime overhead.

In NO_LIBCXX mode, stl_compat.h provides its own implementations of the C++ types that simdutf uses, but only just enough for them to be compatible with what simdutf needs. For example, stl_compat.h provides its own implementation of std::pair.

As a result, the changes required end up mostly looking like this throughout the diff:

-std::pair<const char *, char32_t *>
+internal::pair<const char *, char32_t *>
arm_convert_latin1_to_utf32(const char *buf, size_t len,
                            char32_t *utf32_output) {

ABI Compatibility

My goal was to retain as much ABI compatibility as possible. Some of the public ABI expose C++ types such as std::string, so in those scenarios, ABI had to be broken. Otherwise, it is fully retained.

Given SIMDUTF_NO_LIBCXX is a new feature that applies changes to the compilation unit, I felt that it was acceptable to break ABI only when this flag is present. In the existing case where the NO_LIBCXX flag is not present, the ABI is fully retained and simdutf can be updated without breaking ABI for existing users.

I was pleasantly surprised to find that the ABI breakage was very minimal, and only applied to a handful of diagnostic functions (e.g. to get the name of the active implementation) and helpers to work with other C++ types (e.g. text encoding std::string). Since by definition someone using SIMDUTF_NO_LIBCXX is not interested in libc++, these ABI breakages felt like a feature rather than a bug.

Extricating simdutf from libc++abi

This task was significantly more complex.

The main problem was that libc++abi dependencies don't usually show up as obvious source-level includes. They show up because the compiler quietly emits calls into the C++ ABI runtime for ordinary-looking language features. To detect these, I had to write a script that decompiles the object files and looks for symbols such as __cxa_guard_acquire.

The biggest offender in simdutf was the runtime dispatch layer. The original code relied heavily on function-local static variables. In C++, those locals are guarded by thread-safe initialization helpers such as __cxa_guard_acquire and __cxa_guard_release, which are provided by the C++ ABI runtime. So even though the code didn't mention libc++abi anywhere, the compiled object still depended on it. The fix for this is to use translation-unit static variables instead of function-local statics in NO_LIBCXX mode.

#if SIMDUTF_IMPLEMENTATION_ICELAKE
  #ifdef SIMDUTF_NO_LIBCXX
static const icelake::implementation icelake_singleton{};
  #endif
static const icelake::implementation *get_icelake_singleton() {
  #ifdef SIMDUTF_NO_LIBCXX
  return &icelake_singleton;
  #else
  static const icelake::implementation icelake_singleton{};
  return &icelake_singleton;
  #endif
}
#endif

Next, simdutf models each backend as a subclass of an abstract implementation interface. That design can stay, but abstract-class vtables still reference __cxa_pure_virtual for impossible-to-call pure virtual entries. In SIMDUTF_NO_LIBCXX mode I chose to provide a tiny local shim and ensure the runtime never actually reaches it. I marked this as weak so that the symbol can be overridden by the C++ ABI if it is present.

#ifdef SIMDUTF_NO_LIBCXX
// The abstract implementation vtable still carries pure-virtual slots even
// though correct dispatch never reaches them in this build mode. Provide the
// narrowest possible ABI shim so stricter no-libcxx objects do not require
// libc++abi just for this unreachable hook. Keep it weak so a toolchain's real
// libc++abi definition wins if one is linked in anyway.
extern "C" SIMDUTF_WEAK [[noreturn]] void __cxa_pure_virtual() noexcept {
  __builtin_trap();
}
#endif

Finally, I wrote a script to audit the build with -fno-exceptions and -fno-rtti and check that no symbols such as __cxa_guard_*, __gxx_personality, __cxa_throw, typeinfo, or __dynamic_cast ever show up. This was added to the simdutf CI to ensure that we never accidentally reintroduce libc++abi dependencies in the future for NO_LIBCXX builds.

Validation

Internal

simdutf is a correctness and performance critical library, so I had to be sure my changes didn't impact either of those. I modified the pre-existing test and benchmark suites to run in both NO_LIBCXX and normal modes and ensured that all tests passed and benchmarks were unaffected.

The important part about this is that I committed the changes necessary to ensure that the NO_LIBCXX mode is compatible with the existing test and benchmark suites. This means that future changes to simdutf can continue to validate both.

External: Ghostty

Next, I updated Ghostty to use the new simdutf from my fork, updated our builds to use SIMDUTF_NO_LIBCXX, and added our own suite of tests to verify our artifacts have no dependencies on libc++ or libc++abi.

Ghostty has a robust set of tests that verify our UTF-8 decoding behavior (especially invalid inputs). And Ghostty has a built-in benchmark suite that tests our UTF-8 throughput in a variety of scenarios. I ran all the Ghostty tests and benchmarks and verified that they all passed and that our UTF-8 performance was unaffected, as expected.

Pull Request

Getting something working and getting something merged are two different things.

I know too well as a maintainer myself the disparity between "this works" and "this can be merged." I know the challenges of verifying someone's work and being confident in maintaining it going forward. I know the challenge of opening a large PR and not having clarity of why it is being opened. And I know the burden of recent AI slop.

So I put in the effort I would want from an all-star contributor and tried to be that person for the simdutf maintainers.

First, I reviewed the entire diff (yes, all ~3,000 lines of it). Then I reviewed it again. I re-read the entire diff by hand three or four times. I made multiple changes based on things I probably would've commented on myself, even if functionally it was fine.

Next, I hand-wrote a detailed PR description that explains the motivation, the approach, the limitations, and the validation. I wanted to make sure that the maintainers were aware of the details but also how much thought I put into the details.

Finally, I disclosed that I did use AI to assist me in writing the code. But I made it clear that I manually reviewed everything, I didn't use AI in writing any of the PR description or comments, and that I was capable and comfortable as a human to defend and modify any proposed changes.

Ironically, the full diff took me about 2 hours to put together, but the extra validation work and PR preparation took me about 3 hours. I spent more time on the human boundary than the code itself, as we should out of respect for the effort maintainers put into their projects.

Final Status

The simdutf PR is still under review. Initial feedback is positive, and I'm open to any and all changes requested of me. There's a possibility that the maintainers will not want to merge it, and that's okay, too.

If you want to use simdutf without libc++ or libc++abi, you can use my fork in the meantime. The same instructions for producing an amalgamated single-file plus header build apply. When building the C++ and including the header, just make sure to define SIMDUTF_NO_LIBCXX to get the no-libc++ version of the library.

The Ghostty PR is now merged. As such, libghostty-vt no longer depends on libc++ or libc++abi for SIMD builds.

Footnotes

libc++ is the C++ standard library (e.g. std::vector, std::string, etc.) and libc++abi is the C++ ABI library (e.g. exception handling, RTTI, etc.). ↩
Note that with SIMD disabled, libghostty-vt has always had zero dependencies, not even libc. It is a fully freestanding library. ↩

The Building Block Economy

2026-04-07T00:00:00+00:00

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.1

Ghostty in 18 months: one million daily macOS update checks.
libghostty in 2 months: multiple millions of daily users.2

Similar growth trajectories can be seen in other "building block" technologies: Pi Mono, Next.js, Tailwind, etc.

Experiencing this firsthand as well as witnessing it in other ecosystems has fundamentally shifted how I view the practice of product and software development today, regardless of commercial vs non-commercial goals.

This article was written by hand, without the assistance of AI. I love and use AI abundantly, but I draw the line personally at content like this. I want my personal blog to reflect my genuine thoughts and feelings.

Imports Are Up

I use the term "building block" to describe how they're being used because they're being assembled today in a very different way than former decades. I don't use the term "library" or "framework" because it extends even up to "applications" (e.g. the Ghostty GUI app has more forks than ever before with customized patches on top, which is awesome).

The factory of today is agentic 3. I say that as objective truth, regardless of what your feelings about it are. You can argue that 99% of the stuff coming out of these factories is total crap, but you can't argue the sheer quantity of stuff coming out. The numbers are everywhere spanning tech stacks and industries and they're undeniable.

AI is okay at building everything from scratch, but it is really good at gluing together high quality, well documented, and proven components. And, AI prefers to do this when it can unless explicitly prompted otherwise. This is the "building block" nature of software today: we're more than ever before grabbing off the shelf components and gluing them together.

Humans, of course, have always done this as well. For my entire career, human software developers have preferred to build on top of proven primitives. But the natural barrier to entry of understanding the component pieces well enough to even slap them together was high enough to limit the ecosystem. This barrier is now gone.

Exports Are Up

Coming out of these factories is of course software. So much software.

There are negatives to this. I think the negatives are obvious enough that I'm not going to dedicate much time to them, but I want to recognize they exist: security vulnerabilities, instability, a general lack of understanding about how load-bearing systems might work.

But there are a huge amount of positives:

The quality bar is lower. A mainline application used by a large cross-section of users has to weigh every feature against every other feature: how do they interact? does it make sense for the long term vision? can I maintain this for millions of users? A factory artifact targeting one to hundreds of users doesn't need to care about this. You can ship faster and looser, as a result.
The awareness is greater. A mainline application can't do everything. It usually optimizes for the use cases that the most users need and use. A factory artifact can optimize for a tiny cross-section of users, and these users gain awareness of the building block as a result. I'm seeing this hugely in Ghostty, as very niche communities are getting terminals.
The maintenance burden is lower. It is easier than ever to say "no thank you" to feature requests, because you're offering a key part of the means to production. My challenges with slop requests are very public, to the point I made a "no machine", but I'm also feeling less and less bad every day about saying "no."
R&D is outsourced. It is so much easier now as a maintainer to look at what others are doing, see working proof of concepts, and decide what you want to bring back to mainline. There's way less talk and way more walk. And while others walk you can cherry pick the best ideas (this is fair: you're giving away a building block and they're giving away their ideas).

The Impact

This is changing how I view software and product development.

I'm much more purposeful about creating building blocks and encouraging applications or forks on top of that. I think this is resulting in a happier community, a larger community, and ultimately better mainline software.

High-quality applications aren't disappearing. And high-quality applications produced by the developers of the building block aren't disappearing. For most software categories, I think there will always be a majority group that doesn't want personalized slop software and wants a polished, well maintained, and well supported application.

Instead, I think the mainline application is becoming more stable and more purposeful in its feature set thanks to the building block economy. The stability comes from a much larger and diverse user group. The feature set comes from the massive ecosystem of outsourced R&D. The mainline application is still measured, high quality, and well maintained, but it's for a specific group.

The Elephant in the Room: Commercialization

The obvious question that follows is what this can mean for commercialization. Closed source, commercial software appears to be at a massive disadvantage. And it is.

Agents will more readily pick open and free software over closed and commercial. At the time of writing this article, this is an objective truth. Independent research labs running experiments on popular models have found repeatedly that under diverse circumstances, models pick open and free alternatives over commercial. So far.

But, I don't have a concrete answer here, because unlike product and software development, I'm not directly building a commercializable product right now. I have thoughts, and as with all hard things, I think the answer is nuanced. But, I don't want to give the illusion of talking authoritatively about this so I'm going to avoid it. When I walk the walk and learn more, I'll share more.

I'm once again simply acknowledging that this challenge obviously exists.

The Shift Has Happened

We have to accept that building blocks and software factories rule everything around us and accept and internalize the consequences of that.

We can choose to run the other direction and create enclaves where we fight against it. Or we can choose to submit ourselves completely to the chaos. People who know me know I'm far less extreme in my actions and carry different opinions depending on context.

The point is the shift has already happened. We're living in it.

Footnotes

The building blocks themselves must usually be high quality, robust, and well documented, though. ↩
Getting exact numbers is obviously hard since Ghostty has no real tracking. We can see aggregate update file checks for macOS. We have no visibility at all into Linux. libghostty has no tracking but tools integrating libghostty might and have shared aggregates with us. ↩
I use the term "agent" here to simply mean a large language model with access to tools in a loop. People sometimes think I'm trying to be hype or cute by using marketing terms, but I am using this as a specific, well accepted definition. ↩

My AI Adoption Journey

2026-02-05T00:00:00+00:00

Table of Contents

My experience adopting any meaningful tool is that I've necessarily gone through three phases: (1) a period of inefficiency (2) a period of adequacy, then finally (3) a period of workflow and life-altering discovery.

In most cases, I have to force myself through phase 1 and 2 because I usually have a workflow I'm already happy and comfortable with. Adopting a tool feels like work, and I do not want to put in the effort, but I usually do in an effort to be a well-rounded person of my craft.

This is my journey of how I found value in AI tooling and what I'm trying next with it. In an ocean of overly dramatic, hyped takes, I hope this represents a more nuanced, measured approach to my views on AI and how they've changed over time.

This blog post was fully written by hand, in my own words. I hate that I have to say that but especially given the subject matter, I want to be explicit about it.

Step 1: Drop the Chatbot

Immediately cease trying to perform meaningful work via a chatbot (e.g. ChatGPT, Gemini on the web, etc.). Chatbots have real value and are a daily part of my AI workflow, but their utility in coding is highly limited because you're mostly hoping they come up with the right results based on their prior training, and correcting them involves a human (you) to tell them they're wrong repeatedly. It is inefficient.

I think everyone's first experience with AI is a chat interface. And I think everyone's first experience trying to code with AI has been asking a chat interface to write code.

While I was still a heavy AI skeptic, my first "oh wow" moment was pasting a screenshot of Zed's command palette into Gemini, asking it to reproduce it with SwiftUI, and being truly flabbergasted that it did it very well. The command palette that ships for macOS in Ghostty today is only very lightly modified from what Gemini produced for me in seconds.

But when I tried to reproduce that behavior for other tasks, I was left disappointed. In the context of brownfield projects, I found the chat interface produced poor results very often, and I found myself very frustrated copying and pasting code and command output to and from the interface. It was very obviously far less efficient than me doing the work myself.

To find value, you must use an agent. An agent is the industry-adopted term for an LLM that can chat and invoke external behavior in a loop 1 At a bare minimum, the agent must have the ability to: read files, execute programs, and make HTTP requests.

Step 2: Reproduce Your Own Work

The next phase on my journey I tried Claude Code. I'll cut to the chase: I initially wasn't impressed. I just wasn't getting good results out of my sessions. I felt I had to touch up everything it produced and this process was taking more time than if I had just done it myself. I read blog posts, watched videos, but just wasn't that impressed.

Instead of giving up, I forced myself to reproduce all my manual commits with agentic ones. I literally did the work twice. I'd do the work manually, and then I'd fight an agent to produce identical results in terms of quality and function (without it being able to see my manual solution, of course).

This was excruciating, because it got in the way of simply getting things done. But I've been around the block with non-AI tools enough to know that friction is natural, and I can't come to a firm, defensible conclusion without exhausting my efforts.

But, expertise formed. I quickly discovered for myself from first principles what others were already saying, but discovering it myself resulted in a stronger fundamental understanding.

Break down sessions into separate clear, actionable tasks. Don't try to "draw the owl" in one mega session.
For vague requests, split the work into separate planning vs. execution sessions.
If you give an agent a way to verify its work, it more often than not fixes its own mistakes and prevents regressions.

More generally, I also found the edges of what agents -- at the time -- were good at, what they weren't good at, and for the tasks they were good at how to achieve the results I wanted.

All of this led to significant efficiency gains, to the point where I was starting to naturally use agents in a way that I felt was no slower than doing it myself (but I still didn't feel it was any faster, since I was mostly babysitting an agent).

The negative space here is worth reiterating: part of the efficiency gains here were understanding when not to reach for an agent. Using an agent for something it'll likely fail at is obviously a big waste of time and having the knowledge to avoid that completely leads to time savings 2.

At this stage, I was finding adequate value with agents that I was happy to use them in my workflow, but still didn't feel like I was seeing any net efficiency gains. I didn't care though, I was content at this point with AI as a tool.

Step 3: End-of-Day Agents

To try to find some efficiency, I next started up a new pattern: block out the last 30 minutes of every day to kick off one or more agents. My hypothesis was that perhaps I could gain some efficiency if the agent can make some positive progress in the times I can't work anyways. Basically: instead of trying to do more in the time I have, try to do more in the time I don't have.

Similar to the previous task, I at first found this both unsuccessful and annoying. But, I once again quickly found different categories of work that were really helpful:

Deep research sessions where I'd ask agents to survey some field, such as finding all libraries in a specific language with a specific license type and producing multi-page summaries for each on their pros, cons, development activity, social sentiment, etc.
Parallel agents attempting different vague ideas I had but didn't have time to get started on. I didn't expect them to produce something I'd ever ship here, but perhaps could illuminate some unknown unknowns when I got to the task the next day.
Issue and PR triage/review. Agents are good at using gh (GitHub CLI), so I manually scripted a quick way to spin up a bunch in parallel to triage issues. I would NOT allow agents to respond, I just wanted reports the next day to try to guide me towards high value or low effort tasks.

To be clear, I did not go as far as others went to have agents running in loops all night. In most cases, agents completed their tasks in less than half an hour. But, the latter part of the working day, I'm usually tired and coming out of flow and find myself too personally inefficient, so shifting my effort to spinning up these agents I found gave me a "warm start" the next morning that got me working more quickly than I would've otherwise.

I was happy, and I was starting to feel like I was doing more than I was doing prior to AI, if only slightly.

Step 4: Outsource the Slam Dunks

By this point, I was getting very confident about what tasks my AI was and wasn't great at. I had really high confidence with certain tasks that the AI would achieve a mostly-correct solution. So the next step on my journey was: let agents do all of that work while I worked on other tasks.

More specifically, I would start each day by taking the results of my prior night's triage agents, filter them manually to find the issues that an agent will almost certainly solve well, and then keep them going in the background (one at a time, not in parallel).

Meanwhile, I'd work on something else. I wasn't going to social media (any more than usual without AI), I wasn't watching videos, etc. I was in my own, normal, pre-AI deep thinking mode working on something I wanted to work on or had to work on.

Very important at this stage: turn off agent desktop notifications. Context switching is very expensive. In order to remain efficient, I found that it was my job as a human to be in control of when I interrupt the agent, not the other way around. Don't let the agent notify you. During natural breaks in your work, tab over and check on it, then carry on.

Importantly, I think the "work on something else" helps counteract the highly publicized Anthropic skill formation paper. Well, you're trading off: not forming skills for the tasks you're delegating to the agent while continuing to form skills naturally in the tasks you continue to work on manually.

At this point I was firmly in the "no way I can go back" territory. I felt more efficient, but even if I wasn't, the thing I liked the most was that I could now focus my coding and thinking on tasks I really loved while still adequately completing the tasks I didn't.

Step 5: Engineer the Harness

At risk of stating the obvious: agents are much more efficient when they produce the right result the first time, or at worst produce a result that requires minimal touch-ups. The most sure-fire way to achieve this is to give the agent fast, high quality tools to automatically tell it when it is wrong.

I don't know if there is a broad industry-accepted term for this yet, but I've grown to calling this "harness engineering." It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again. I don't need to invent any new terms here; if another one exists, I'll jump on the bandwagon.

This comes in two forms:

Better implicit prompting (AGENTS.md). For simple things, like the agent repeatedly running the wrong commands or finding the wrong APIs, update the AGENTS.md (or equivalent). Here is an example from Ghostty. Each line in that file is based on a bad agent behavior, and it almost completely resolved them all.
Actual, programmed tools. For example, scripts to take screenshots, run filtered tests, etc etc. This is usually paired with an AGENTS.md change to let it know about this existing.

This is where I'm at today. I'm making an earnest effort whenever I see an agent do a Bad Thing to prevent it from ever doing that bad thing again. Or, conversely, I'm making an earnest effort for agents to be able to verify they're doing a Good Thing.

Step 6: Always Have an Agent Running

Simultaneous to step 5, I'm also operating under the goal of having an agent running at all times. If an agent isn't running, I ask myself "is there something an agent could be doing for me right now?"

I particularly like to combine this with slower, more thoughtful models like Amp's deep mode (which is basically just GPT-5.2-Codex) which can take upwards of 30+ minutes to make small changes. The flip side of that is that it does tend to produce very good results.

I'm not [yet?] running multiple agents, and currently don't really want to. I find having the one agent running is a good balance for me right now between being able to do deep, manual work I find enjoyable, and babysitting my kind of stupid and yet mysteriously productive robot friend.

The "have an agent running at all times" goal is still just a goal. I'd say right now I'm maybe effective at having a background agent running 10 to 20% of a normal working day. But, I'm actively working to improve that.

I don't want to run agents for the sake of running agents. I only want to run them when there is a task I think would be truly helpful to me. Part of the challenge of this goal is improving my own workflows and tools so that I can have a constant stream of high quality work to do that I can delegate. Which, even without AI, is important!

Today

And that's where I'm at today.

Through this journey, I've personally reached a point where I'm having success with modern AI tooling and I believe I'm approaching it with the proper measured view that is grounded in reality. I really don't care one way or the other if AI is here to stay 3, I'm a software craftsman that just wants to build stuff for the love of the game.

The whole landscape is moving so rapidly that I'm sure I'll look back at this post very quickly and laugh at my naivete. But, as they say, if you can't be embarassed about your past self, you're probably not growing. I just hope I'll grow in the right direction!

I have no skin in the game here 4, and there are of course other reasons behind utility to avoid using AI. I fully respect anyone's individual decisions regarding it. I'm not here to convince you! For those interested, I just wanted to share my personal approach to navigating these new tools and give a glimpse about how I approach new tools in general, regardless of AI.

Footnotes

Modern coding models like Opus and Codex are specifically trained to bias towards using tools compared to conversational models. ↩
Due to the rapid pace of innovation in models, I have to constantly revisit my priors on this one. ↩
The skill formation issues particularly in juniors without a strong grasp of fundamentals deeply worries me, however. ↩
I don't work for, invest in, or advise any AI companies. ↩

Don't Trip[wire] Yourself: Testing Error Recovery in Zig

2026-01-21T00:00:00+00:00

I've written a library called Tripwire 1 for injecting failures into Zig programs for the express purpose of testing error handling paths. Outside of unit tests, it is completely optimized away and has zero runtime cost (space or time).

Zig has a language feature errdefer for running code on block exit only when an error is being returned. The idea is simple: if an error occurs, you need to "undo" your partial effects so that when the function returns an error, the world state can be in some well-defined state.

Ironically, error cleanup is one of the most error-prone parts of Zig programs and is a consistent source of resource leaks and memory corruption.

This is easily understood: error codepaths are typically much less frequently executed and triggering them in tests can be difficult. As a result, they usually are only cognitively reviewed once or twice during development, and never truly exercised until a user hits them in production.

Errors in Zig

This section covers some background on how errors work in general in Zig. If you're familiar with Zig error handling, feel free to skip this section.

All functions in Zig can return error values. An error value acts a bit like an enum and looks like this: error.OutOfMemory. Error values are collected into name sets known as error sets. And functions can return either an error or a success value using something called an error union.

You can wrap an error union (usually a function call result) with try to unwrap the value or return the error.

And, finally, the key point for this post, you can put errdefer anywhere and when an error is returned (either directly or via try), then all prior errdefer statements in the current scope will be executed in reverse order.

All-in-all, it looks a bit like this in a toy example:

fn create(alloc: Allocator) !*Widget {
    const self = try alloc.create(Widget);
    errdefer alloc.destroy(self);

    self.* = try .init(alloc);
    errdefer self.deinit();

    const file = try std.fs.cwd().openFile("config.txt", .{});
    // etc...

    return self;
}

In this example, you can see the basic path:

After allocating room for Widget, if we see an error we should deallocate.
After initializing the Widget, if we see an error we should deinitialize it.
etc.

This is a quintessential Zig pattern, and you will see it all over the Zig standard library and in most Zig programs. This is an easy case where errdefer is obviously correct even without tests.

But the real world gets messy fast.2

Why So Fragile?

It is also useful background to understand why it is so difficult to test error handling codepaths in Zig.

Zig provides some great utilities for program correctness. First, it has a number of runtime safety checks covering things from index of bounds to null dereferencing and so on. Next, Zig's parameterized allocators make it easier to test out of memory scenarios, constrained memory environments, and so on. Finally, Zig has a builtin test framework and encourages writing tests culturally.

But, it has no mechanism to trigger errors to test errdefer. For memory allocation errors, you can use specialized allocators like the std.testing.failing_allocator, but getting it exactly configured right in complex code that does many allocations and whose allocations may be conditional is tricky and fragile.

You always get defer testing for free if you unit test your code because defers run unconditionally on block exit. But errdefer only runs when errors occur, so if you can't trigger the error, you can't test the corresponding errdefer!

And besides tooling, error handling code by its nature is more rarely executed and the state of the world when an error occurs is often more complex than the success path (since it is also may be dependent on where the error occurred).

Tripwire

I ultimately grew tired of eyeballing error handling code and hoping it was correct, or spending hours trying to write tests that create a perfect-but-fragile scenario to trigger an exact error path. So, I wrote Tripwire.

Tripwire is a small, single-file library 1 that lets you put named points in your code where you can trigger errors during tests. Outside of tests, it is written in such a way that it is completely optimized away (takes no memory and emits no machine code).

Conceptually it works like this:

How tripwire injects failures

Click to trigger:

fn init(alloc: Allocator) !*Self {

try tw.check(.alloc_buffer);

const buf = try alloc.alloc(u8, 1024);

errdefer alloc.free(buf);

try tw.check(.open_file); ← error injected!

const file = try openFile("config");

errdefer file.close();

return self;

}

Triggering .open_file: Buffer was allocated, so errdefer alloc.free(buf) must run. If it's missing or wrong, the test fails with a memory leak!

With code, it looks like this:

const tripwire = @import("tripwire.zig");

// Define a tripwire module with named failure points. The second
// argument is the function itself to get its error set.
const init_tw = tripwire.module(enum {
    alloc_buffer,
    open_file,
}, init);

fn init(alloc: Allocator) !*Self {
    // Check the tripwire before the fallible operation.
    // In tests, this can be configured to return an error.
    // In release builds, this compiles to nothing.
    try init_tw.check(.alloc_buffer);
    const buf = try alloc.alloc(u8, 1024);
    errdefer alloc.free(buf);

    try init_tw.check(.open_file);
    const file = try std.fs.cwd().openFile("config.txt", .{});
    errdefer file.close();

    // ...
}

test "init error on open_file" {
    // Configure the tripwire to fail at the open_file point.
    try init_tw.errorAlways(.open_file, error.OutOfMemory);
    // Call the function and expect the error.
    try std.testing.expectError(error.OutOfMemory, init(std.testing.allocator));
    // End the tripwire session and reset state.
    // This also verifies the tripwire was actually hit.
    try init_tw.end(.reset);
}

The key insight is that std.testing.allocator will fail the test if any memory is leaked. So by triggering an error at .open_file, we force the errdefer alloc.free(buf) to run. If that errdefer was missing or wrong, the test would fail with a memory leak. In more complex scenarios, you'd add additional state testing in the unit test after the error is tripped.

Another common pattern I use is to iterate through all possible failure points to get complete coverage:

test "init handles all error points" {
    for (std.meta.tags(init_tw.FailPoint)) |point| {
        try init_tw.errorAlways(point, error.OutOfMemory);
        try std.testing.expectError(error.OutOfMemory, init(std.testing.allocator));
        try init_tw.end(.reset);
    }
}

As I said before, in practice you probably need a bit more expectations after the tripwire end to verify that your world state is sensible. But even at a basic level, this makes it easy to ensure no runtime safety checks or leaks are detected.

In addition to errorAlways, you can use errorAfter to only trigger an error after a certain number of times that that failure point has been reached. And end will verify that it was triggered. This is useful to catch resource leakage or state corruption due to poor loop cleanup.

Zero-Cost Outside of Tests

Outside of tests, Tripwire emits no machine code and uses no memory; it is completely optimized away.

To do this, we use Zig's comptime to detect the test framework:

/// Whether our module is enabled or not.
pub const enabled = builtin.is_test;

And use that to conditionally make our functions no-ops:

pub fn check(point: FailPoint) callconv(callingConvention()) Error!void {
  if (comptime !enabled) return;
  // actually do stuff
}

We also use comptime to set the calling convention so that the function is inlined if we're not enabled:

/// Our calling convention is inline if our tripwire module is
/// NOT enabled, so that all calls to `check` are optimized away.
fn callingConvention() std.builtin.CallingConvention {
    return if (!enabled) .@"inline" else .auto;
}

Some have told me this isn't necessary, but we've seen real compilations produce machine code with full function call overhead to a function with an empty body and only a ret. Inlining fixes this, until we figure out what is causing that.

And finally, the Zig compiler only analyzes and emits code for declarations that are actively referenced (or volatile). Since no code references this state when Tripwire is disabled, none of our global state gets emitted into the binary, either.

Bugs, Bugs

I integrated Tripwire into Ghostty in only a handful of places and immediately uncovered many bugs. In the initial PR I fixed ~6 errdefer bugs. They've all never been known to trigger in the real world but they are bugs nonetheless.

And most importantly, the bugs are now fixed paired with unit tests that verified they exist! If I remove the fix, the tests fail!

I plan to continue to integrate Tripwire into more parts of the Ghostty codebase and to ensure that I'm considering errdefer testing for any newly written code by myself, maintainers, or contributors.

Please, copy the file if you find it useful and use it in your own projects! Ghostty is MIT licensed and Tripwire is fully self-contained in a single file. Use it!

Footnotes

It is a single file. Copy and paste it in your project if you want to use it. ↩ ↩2
I originally had a bunch of examples in this post but I think it made the post much too long and it's easier to just take a look at some of the commits in PR 8249 and PR 10401. ↩

Finding and Fixing Ghostty's Largest Memory Leak

2026-01-10T00:00:00+00:00

A few months ago, users started reporting that Ghostty was consuming absurd amounts of memory, with one user reporting 37 GB after 10 days of uptime. Today, I'm happy to say the fix has been found and merged. This post is an overview of what caused the leak, a look at some of Ghostty's internals, and some brief descriptions of how we tracked it down.1

The leak was present since at least Ghostty 1.0, but it is only recently that popular CLI applications (particularly Claude Code) started producing the correct conditions to trigger it at scale. The limited conditions that triggered the leak are what made it particularly tricky to diagnose.

The fix is merged and is available in tip/nightly releases, and will be part of the tagged 1.3 release in March.

The PageList

To understand the bug, we first need to understand how Ghostty manages terminal memory. Ghostty uses a data structure called the PageList to store terminal content. PageList is a doubly-linked list of memory pages that store the terminal content (characters, styles, hyperlinks, etc.).

PageList: A doubly-linked list of memory pages

Page 1 oldest scrollback

Page 2

Page 3

Page 4 newest active screen

The underlying "pages" are not single virtual memory pages but they are a contiguous block of memory aligned to page boundaries and composed of an even multiple of system pages.2

These pages are allocated using mmap. mmap isn't particularly fast, so to avoid constant syscalls, we use a memory pool. When we need a new page, we pull from the pool. When we're done with a page, we return it to the pool for reuse.

The pool uses a standard size for pages. Think of it like buying standard-sized shipping boxes: most things people ship fit in a standard box, and having a standard box comes with various efficiencies.

But sometimes terminals need more memory than a standard page provides. If a set of lines has many emoji, styles, or hyperlinks, we need a larger page. In these cases, we allocate a non-standard page directly with mmap, bypassing the pool entirely. This is typically a rare scenario.

Two types of page allocations

Standard Pages (from pool)

• Fixed size

• Returned to pool when freed

• Reusable for future allocations

Non-Standard Pages (direct mmap)

• Variable size (larger than standard)

• Must call munmap to free

• Cannot be reused

When we "free" a page, we apply some simple logic:

If the page is <= standard size: return it to the pool
If the page is > standard size: call munmap to free it

This is the core background for terminal memory management in Ghostty, and the idea itself is sound. A logic bug around an optimization is what produced the leak, as we'll see next.

There's one more background detail we need to cover to understand the bug: scrollback pruning.

Ghostty has a scrollback-limit configuration that caps how much history is retained. When you hit this limit, we delete the oldest pages in the scrollback buffer to free up memory.

But this often happens in a super hot path (e.g. when outputting large amounts of data quickly), and allocating and freeing memory pages is expensive, even with the pool. Therefore, we have an optimization: reuse the oldest page as the newest page when we reach the limit.

Scrollback pruning: reusing the oldest page

Before: at scrollback limit

Page 1 to be pruned

Page 2

Page 3

Page 4

Remove from front, reuse at back

After: page reused at end

Page 2 now oldest

Page 3

Page 4

Page 1 reused!

This optimization works great. It requires zero allocations and uses only some quick pointer manipulations to move the page from the front to the back of the list. We do some metadata cleanup to "clear" the page but otherwise leave the previous memory intact.

It's fast and empirically speeds up scrollback-heavy workloads significantly.

The Bug

During the scrollback pruning optimization, we always resized our page back to standard size. But we didn't resize the underlying memory allocation itself, we only noted the resize in the metadata. The underlying memory was still the large non-standard mmap allocation, but now the PageList thought it was standard sized.

How metadata desync causes the leak

Allocate non-standard page

metadata:

2× std

mmap:

std

+extra

Scrollback prunes & reuses

metadata:

std_size

mmap:

std

+extra

BUG: metadata reset to std_size, but mmap unchanged!

Free the page

metadata:

std_size

mmap:

LEAKED

std_size, assume pooled. munmap never called!

Standard Non-standard Leaked

Eventually, we'd free the page under various circumstances (e.g. when the user closes the terminal, but also other times). At that point, we'd see the page memory was within the standard size, assume it was part of the pool, and we would never call munmap on it. A classic leak.

This all seems pretty obvious, but the issue is that non-standard pages are rare by design. The goal of our design and optimizations is that standard pages are the common case and provide a fast-path. Only very specific scenarios produce non-standard pages and they're usually not produced in large quantities.

But the rise of Claude Code changed this. For some reason, Claude Code's CLI produces a lot of multi-codepoint grapheme outputs which force Ghostty to regularly use non-standard pages. Additionally, Claude Code uses the primary screen and produces a significant amount of scrollback output. These things combined together created the perfect storm to trigger the leak in huge quantities.

I want to be explicit that this bug is not Claude Code's fault. Claude Code is simply exercising Ghostty in a way that exposes this long-standing bug.

The Fix

The fix is conceptually simple: never reuse non-standard pages. If we encounter a non-standard page during scrollback pruning, we destroy it properly (calling munmap) and allocate a fresh standard-sized page from the pool.

The core of the fix is in the snippet below, but some extra work was needed to fix up some other bits of accounting we have:

if (first.data.memory.len > std_size) {
    self.destroyNode(first);
    break :prune;
}

We could've also reused the non-standard page and just retained the large memory size, but until we have data that shows otherwise, we're still operating under the assumption that standard pages are the common case and it makes sense to reset back to a standard pooled page.

Other users have recommended more complex strategies (e.g. maintaining some metrics on how often non-standard pages are used and adjusting our assumptions accordingly), but more research is needed before making those changes. This change is simple, fixes the bug, and aligns with our current assumptions.

As part of the fix, I added support for virtual memory tags on macOS provided by the Mach kernel. This lets us tag our PageList memory allocations with a specific identifier that shows up in various tooling.

inline fn pageAllocator() Allocator {
    // In tests we use our testing allocator so we can detect leaks.
    if (builtin.is_test) return std.testing.allocator;

    // On non-macOS we use our standard Zig page allocator.
    if (!builtin.target.os.tag.isDarwin()) return std.heap.page_allocator;

    // On macOS we want to tag our memory so we can assign it to our
    // core terminal usage.
    const mach = @import("../os/mach.zig");
    return mach.taggedPageAllocator(.application_specific_1);
}

Now when debugging memory on macOS, Ghostty's PageList memory shows up with a specific tag instead of being lumped in with everything else. This made it trivial to identify the leak, associate it with the PageList, and also verify that the fix worked by observing the tagged memory being properly freed.

Preventing Leaks in Ghostty

We do a lot of work in the Ghostty project to find and prevent memory leaks:

In debug builds and unit tests, we use leak-detecting Zig allocators.
The CI runs valgrind on our full unit test suite on every commit to find more than just leaks, such as undefined memory usage.
We regularly run the macOS GUI via macOS Instruments to look for leaks particularly in the Swift codebase.
We run every GTK-related PR using Valgrind (the full GUI) to look for leaks in the GTK codepath that isn't unit tested.

This has worked really well to date, but unfortunately it didn't catch this particular leak because it only triggers under very specific conditions that our tests didn't reproduce. The merged PR includes a test that does reproduce the leak to prevent regressions in the future.

Conclusion

This was the largest known memory leak in Ghostty to date, and the only reported leak that has been confirmed by more than a single user. We'll continue to monitor and address memory reports as they come in, but remember that reproduction is the key to diagnosing and fixing memory leaks!

Big thanks to @grishy who finally got me a reliable reproduction so I could analyze the issue myself. Their own analysis reached the same conclusion as mine, and the reproduction let me verify both our understandings independently.

Thanks also to everyone who reported this issue with detailed diagnostics. The community's analysis, especially around the footprint output and VM region counting, gave me important clues that pointed toward the PageList as the culprit.

Footnotes

This post was written without the use of AI. AI was used to assist in some of the diagrams, but they were all reviewed for correctness by a human. None of the text content was AI-generated. ↩
The reason for this is not important for this blog post, but it is an interesting detail on its own. ↩

Ghostty Is Now Non-Profit

2025-12-03T00:00:00+00:00

Ghostty is now fiscally sponsored by Hack Club, a registered 501(c)(3) non-profit.

Fiscal sponsorship is a legal and financial arrangement in which a recognized non-profit extends its tax-exempt status to a project that aligns with its mission. This allows Ghostty to operate as a charitable initiative while Hack Club manages compliance, donations, accounting, and governance oversight.

Being non-profit clearly demonstrates our commitment to keeping Ghostty free and open source for everyone. It paves the way for a model for sustainable development beyond my personal involvement. And it also provides important legal protections and assurances to the people and communities that adopt and use Ghostty.

Why a Non-Profit?

Since the beginning of the project in 2023 and the private beta days of Ghostty, I've repeatedly expressed my intention that Ghostty legally become a non-profit. This intention stems from several core beliefs I have.

First, I want to lay bricks for a sustainable future for Ghostty that doesn't depend on my personal involvement technically or financially. Financially, I am still the largest donor to the project, and I intend to remain so, but a non-profit structure allows others to contribute financially without fear of misappropriation or misuse of funds (as protected by legal requirements and oversight from the fiscal sponsor).

Second, I want to squelch any possible concerns about a "rug pull". A non-profit structure provides enforceable assurances: the mission cannot be quietly changed, funds cannot be diverted to private benefit, and the project cannot be sold off or repurposed for commercial gain. The structure legally binds Ghostty to the public-benefit purpose it was created to serve.

Finally, despite being decades-old technology, terminals and terminal-related technologies remain foundational to modern computing and software infrastructure. They're often out of the limelight, but they're ever present on developer machines, embedded in IDEs, visible as read-only consoles for continuous integration and cloud services, and still one of the primary ways remote access is done on servers around the world.

I believe infrastructure of this kind should be stewarded by a mission-driven, non-commercial entity that prioritizes public benefit over private profit. That structure increases trust, encourages adoption, and creates the conditions for Ghostty to grow into a widely used and impactful piece of open-source infrastructure.

What This Means For Ghostty

From a technical perspective, nothing changes for Ghostty. Our technical goals for the project remain the same, the license (MIT) remains the same, and we continue our work towards better Ghostty GUI releases and libghostty.

Financially, Ghostty can now accept tax-deductible donations in the United States. This opens up new avenues for funding the project and sustaining development over the long term. Most immediately, I'm excited to begin compensating contributors, but I also intend to support upstream dependencies, fund community events, and pay for boring operational costs.

All our financial transactions will be transparent down to individual transactions for both inflows and outflows. You can view our public ledger at Ghostty's page on Hack Club Bank. At the time of writing, this is empty, but you'll soon see some initial funding from me and the beginning of paying for some of our operational costs.

All applicable names, marks, and intellectual property associated with Ghostty have been transferred to Hack Club and are now owned under the non-profit umbrella. Copyright continues to be held by individual contributors under the continued and existing license structure.

From a leadership perspective, I remain the project lead and final authority on all decisions, but as stated earlier, the creation of a non-profit structure lays the groundwork for an eventual future beyond this model.

Important note: no funds will be sent to me (Mitchell Hashimoto) or used in any way that personally benefits me. Since I'm both the largest donor and lead of this project, this is a legally guaranteed protection. But also for altruistic reasons, all funds will be directed towards the needs of the project and its community.

Supporting Hack Club

As our fiscal sponsor, Hack Club provides essential services to Ghostty, including accounting, legal compliance, and governance oversight. To support this, 7% of all donations to Ghostty go to Hack Club to cover these costs in addition to supporting their broader mission of empowering young people around the world interested in technology and coding.

In the words of Zach Latta, Hack Club's founder and executive director this is a "good-for-good" trade. Instead of donor fees going to a for-profit management company or covering pure overhead of a single project, the fees go to another non-profit doing important work in the tech community and the overhead is amortized across many projects.

In addition to the 7% fees, my family is personally donating $150,000 directly to the Hack Club project1 (not to Ghostty within it). Hack Club does amazing work and I would've supported them regardless of their fiscal sponsorship of Ghostty, but I wanted to pair these two things together to amplify the impact of both.

Donate

Please consider donating to support Ghostty's continued development.

I recognize that Ghostty is already in an abnormally fortunate position to have myself as a backer, but I do envision a future where Ghostty is more equally supported by a broader community. And with our new structure, you can be assured about the usage of your funds towards public-benefit goals.

This post isn't meant to directly be a fundraising pitch so it is purposely lacking critical details about our funding goals, budget, project goals, project metrics, etc. I'll work on those in the future. In the mean time, if you're interested in talking more about supporting Ghostty, please email me at m@mitchellh.com.

Your contribution helps sustain development and keeps Ghostty free and open source for everyone. Donations are tax-deductible in the United States.

DAF or Foundation

Use the EIN above and specify “Ghostty” as the recipient

7% of donations go to Hack Club to cover administrative costs and support their mission.

Thank You

I'm thankful for Hack Club and their team for working with us to make this happen. I'm also thankful for the Ghostty community who has supported this project and has trusted me and continues to trust me to steward it responsibly.

For more information about Ghostty's non-profit structure, see the dedicated page on Ghostty's website.

Footnotes

We haven't finalized the transfer of the funds yet, but it is initiated and will be completed in the coming weeks. ↩

Vibing a Non-Trivial Ghostty Feature

2025-10-11T00:00:00+00:00

I recently shipped a non-trivial Ghostty feature (unobtrusive macOS automatic updates) that was largely developed with AI.

I'm regularly asked to share non-trivial examples of how I use AI and agentic coding tools and this felt like a golden opportunity to walk through my process with a well-scoped, non-trivial, real-world, shipping feature 1.

This post will share every single agentic coding session I had on the path to shipping this feature, unedited and in full. Alongside it, I'll provide some additional context about my process and reasoning. And yes, I'll also share the token cost for those curious about that, too.

Important: there is a lot of human coding, too. I almost always go in after an AI does work and iterate myself for awhile, too. Rather than say that at every turn, I'm just saying it once here. Therefore, you may see some discrepancies between what the AI produced and what ended up in the final code. This is intentional and I believe good AI drivers are experts in their domains and utilize AI as an assistant, not a replacement.

The Feature

The finished feature this blog post is about is the macOS unobtrusive update notification feature. This feature shows update status within the terminal window without interrupting work by creating windows, grabbing focus, etc.

Let's set the stage for what lead to this feature (pun intended, as you'll see shortly). During a high-profile OpenAI keynote, a demo was rudely interrupted by a Ghostty update prompt:

I wanted to ensure that never happened again 2. The path I decided to take was to make update notifications unobtrusive. Instead of popping up a window, the app would instead show a small, non-modal GUI element somewhere that wouldn't interrupt the user.

Pre-AI Planning

So I pulled out my AI tooling. Absolutely not. I began by coming up with a rough plan of how I wanted this to work. Ghostty uses Sparkle, an extremely popular macOS update framework. I poked around their docs and found that they support custom UI through Obj-C protocols. You have to reimplement a ton of stuff from scratch, but it is possible.

Okay, so I had a rough idea of backend. For frontend, I wasn't really sure (and it isn't my area of expertise). I had this really vague idea that it should be a little button embedded in the title bar, and I know macOS supports custom UI in the titlebar via titlebar accessory controllers, but beyond that I didn't have much of a sense of how it should look or feel.

But that's enough to get started. AI is a very good prototyper, so even knowing what you don't know is useful enough to get started. I had a strong enough sense of the big picture.

First Session: Prototyping the UI

Here is my first agentic coding session, with the starting prompt:

I want to enable custom, unobtrusive update notifications and installs by customizing SPUUserDriver. Let's start by planning the custom UI we'll need. We'll ONLY work on UI. Create a plan for creating SwiftUI views that can show the various states that are required by SPUUserDriver. I think the best place for these to show up is in the macOS window titlebars on the top-right. Create a plan to put it there. Consult the oracle.

Frequent question: "What is the oracle?" It is an Amp-specific read-only subagent that uses a slower, higher-cost model that is generally better at thinking about things. I consult the oracle for all planning.

To start, I decided to prototype the UI first.

Notice here that I don't send the agent off to build the full feature. There are a couple reasons for this. First and foremost, I still don't even know what I want the UI/UX to be like, so I can't possibly coherently expect an AI to do that for me amongst other changes. Second, smaller chunks of work are easier to review, understand, and iterate on.

Another thing to notice is that I ask it to only create a plan and not to write any code. Since this is a relatively vague request, it's important that I review a plan before it goes off and does a ton of work (and spends a ton of tokens doing it).

Tip: Creating a comprehensive plan interactively with an agent is a really important first-step for anything non-trivial. I usually also save it out (via the agent) to something like spec.md and in future sessions I can say "Consult the @spec.md and work on some task".

The agent came up with an agreeable enough plan that I let it go ahead and implement it. You can see the rest of my conversations as I iterate on that.

The UI it made was directionally very good. It had a ton of polish issues (spacing, colors, etc.) but seeing the UI gave me the spark of inspiration I needed to know what I wanted.

Tip: I very often use AI for inspiration. In this case, I ended up keeping a lot (not all) of the UI code it made, but I will very often prompt an agent, throw away everything it did, and redo it myself (manually!). I find the "zero to one" stage of creation very difficult and time consuming and AI is excellent at being my muse.

Hitting a Wall

You can see in chats 11 to 14 that we're entering the slop zone. The code the agent created has a critical bug, and it's absolutely failing to fix it. And I have no idea how to fix it, either.

I'll often make these few hail mary attempts to fix a bug. If the agent can figure it out, I can study it and learn myself. If it doesn't, it costs me very little. If the agent figures it out and I don't understand it, I back it out. I'm not shipping code I don't understand. While it's failing, I'm also tabbed out searching the issue and trying to figure it out myself.

It's at this point that I know I need to step back, review what it did, and come up with my own plans. It's time to educate myself and think critically. AI is no longer the solution; it is a liability.

Cleanup Sessions

I spend the next few sessions guiding the agent to clean up the code.

The second session focused on moving some methods around into better places I recognized:

Let's move the pill background, foreground, and badge functions from @macos/Sources/Features/Update/UpdateAccessoryView.swift to @macos/Sources/Features/Update/UpdateViewModel.swift and make them more generic (background, foreground, badge)

The third session added documentation to the code:

Update the docs for @UpdateBadge.swift

Tip: Adding documentation is a really important step because it helps reaffirm your own understanding of the code as well as educate future agents that may read and modify this code. I find agents do much better when they have both natural language descriptions as well as the code itself.

The fourth session moves the view model to an app-global location, since the original work put it in a window scope and update information is app scoped.

Move the update view model data to AppDelegate since the update information will be app-global.

Throughout these, I am usually dropping in and making minor manual changes as well.

The cleanup step is really important. To cleanup effectively you have to have a pretty good understanding of the code, so this forces me to not blindly accept AI-written code. Subsequently, better organized and documented code helps future agentic sessions perform better.

I sometimes tongue-in-cheek refer to this as the "anti-slop session".

Facing "The Bug"

Time to get back to that bug that I found in that initial session. I once again spent a few sessions trying to get the agent to figure this out. I start vague, and slowly get more specific with how I'd approach it.

First, the vague session:

For standard, native tabs, the update accesory view is not visible. It should remain visible in the titlebar of the window.

Failure. Then, I get more specific:

We need to update @macos/Sources/Features/Terminal/Window Styles/TerminalTabsTitlebarTahoe.swift tab bar constraints to align the right edge of the tab bar with the left edge of the update accessory view so it remains visible.

Failure. Then, I try a different, specific approach:

What if we changed the @macos/Sources/Features/Terminal/Window Styles/TitlebarTabsTahoeTerminalWindow.swift to make the tab bar a top accessory view rather than a bottom one to make our tabs go into the titlebar?

Failure. One last attempt:

The "right accessory view" and layout of @macos/Sources/Features/Terminal/Window Styles/TitlebarTabsTahoeTerminalWindow.swift is conflictig with the update accessory view setup in @macos/Sources/Features/Terminal/Window Styles/TerminalWindow.swift Can we constrain the tab bar to always appear left of the update notice?

Failure.

This whole time, I've also spent time trying to solve this myself through manual research and human effort. My more specific prompts are based on things I've learned through that process. But overall, it was clearly not working.

I don't think I can figure this out on my own, so I decide to pivot. I decided that for these problematic titlebar styles, let's put the update notices in the bottom-right corner of the window overlaid on top of the content view rather than in the titlebar.

I need to support this anyways because Ghostty has a configuration to hide the titlebar entirely. So, even if I can solve the titlebar styling issue later, I still need to support this other mode.

My next session moves forward with this plan with a very specific prompt:

Augment the @macos/Sources/Features/Update system to also support an overlay approach in @macos/Sources/Features/Terminal/TerminalView.swift The update notice should appear at the bottom of the window. It should go over the text (so it doesn't resize the terminal view). All clicking behaviors should otherwise be the same as the accessory view.

It did a really good job with this. I did a lot of manual polish after (moving stuff around, renaming things, etc.) but the core work was solid.

Here is a video of the feature shortly after this session, showcasing how the update notice appears in the bottom-right corner of the window for certain titlebar styles or when the titlebar is hidden:

Starting the Backend

The UI was feeling good enough. I had noted a bunch of polish issues I wanted to tackle later but I wanted to move on to the backend work primarily to see if I'd discover any unknown unknowns that threw a wrench in my plans.

I manually created a file with a scaffold of incomplete functions and various TODO comments. I then started a session to complete that work for me:

Complete the @macos/Sources/Features/Update/UpdateDriver.swift Read the Sparkle documentaiton as necessary to understand the functionality. https://sparkle-project.org/documentation/api-reference/Protocols.html

Tip: AI is very good at fill-in-the-blank or draw-the-rest-of-the-owl. My pattern here of creating scaffolding with descriptive function names, parameters, todo comments, etc. is a really common one for me and it works very well.

It actually did a really bad job here and I ended up throwing all of this code away. The code it produced worked, but it was obviously the wrong approach. It conflated a lot of different concerns and the way it was storing state in the driver was clearly wrong.

When I studied what it did, I realized it was because the view model was structured in a suboptimal way, so I switched gears into cleanup mode to give AI (and humans, if I chose to write it myself) the better framework to work with.

Cleanup Again, Big Time

Experience has taught me that the cleanliness of a UI frontend and business logic backend is often dictated by the quality of the view model in between. So I spent some time manually restructured the view model. This involved switching to a tagged union rather than the struct with a bunch of optionals. I renamed some types, moved stuff around.

I knew from experience that this small bit of manual work in the middle would set the agents up for success in future sessions for both the frontend and backend. After completing it, I continued with a marathon set of cleanup sessions.

After doing the restructuring, the first thing I did was ask the agent to once again complete the owl, this time inspecting my changes and updating dependent code to the new style and removing the old:

Update @macos/Sources/Features/Update/UpdateViewModel.swift to use the new UpdateState exclusively. Rename state2 to state (remove the old state).

Then I asked it remove additional dead code:

I think we can get rid of UpdateUIActions. They're not used anymore since our UpdateState has callbacks.

Then I broke the build myself cleaning up some things. I had a meeting to hop onto so I decided to let the agent fix it while I was busy:

Run the build and fix the errors

Tip: "I broke a bunch of things, please fix my mess." is another frequent use case I have for agents. I'd say generally this fits within the same fill-in-the-blank pattern as before.

Later, I started doing some refactors on some of the views again:

Turn each @macos/Sources/Features/Update/UpdatePopoverView.swift case into a dedicated fileprivate Swift view that takes the typed value as its parameter so that we can remove the guards.

More cleanup:

Change iconName in @macos/Sources/Features/Update/UpdateViewModel.swift to be an optional, return nil for blank. Update usage.

Simulation

In my first UI session, I had the agent create some demo code so I could see the UI in action without real update checks. But update flows have a number of scenarios and up to this point I only tested the happy path.

In my next session I extracted the simulation code into a dedicated file and asked the agent to create more scenarios:

Extract the update simulation code in @macos/Sources/App/macOS/AppDelegate.swift into a dedicated file in @macos/Sources/Features/Update . This should contain multiple simulation scenarios (happy path, not found, errors, etc.) so that we can easily try different demos.

Tip: Agents are great at generating tests and simulations. The simulation code specifically that it generated here is honestly pretty gross but it works and it's not part of the release binary so the quality doesn't matter to me. I didn't even bother cleaning it up beyond the basics you can see in the session.

I then ran the various simulations and found a number of UX improvements.

Last Mile

At this point, I had a working backend and frontend and I needed to hook it all up.

My next session prompted the agent to do this:

Make an UpdateController class the same as https://github.com/sparkle-project/Sparkle/blob/2.x/Sparkle/SPUStandardUpdaterController.m but for our updater types.

This required some back and forth and manual polish, but it got there.

I then made some minor improvements:

For our update available state with the appcast, look at https://sparkle-project.org/documentation/api-reference/Classes/SUAppcastItem.html and show other relevant metadata if its set. For example, content length for size.

Anything Else?

My last prompt to an agent is always to ask what else I might be missing. I do this regardless of if I manually wrote the code myself or not.

Are there any other improvements you can see to be made with the @macos/Sources/Features/Update feature? Don't write any code. Consult the oracle. Consider parts of the code that can also get more unit tests added.

This highlighted some real issues, so I went ahead and asked it to implement them. I find its easier to tell the agent "okay just do it all" rather than ask it specific things to do, since I can always easily clean it up in selective commits later.

An amusing thing in this session is that the agent started going down a really crazy rabbit hole and so I stepped in to stop it:

Stop stop stop. Undo all the main actor stuff.

I also noticed that it did something rather poorly when there is a better way:

For the error message, instead of truncating, isn't there a SwiftUI standard way to do this? We should add an additional UI element they can use to view the whole message.

Cost and Time

The work took a total of 16 separate sessions totalling $15.98 in token spend on Amp 3. I won't try to speculate whether this is expensive or cheap in general, but I will say for me personally I spent more than that in coffee shops in the two calendar days I spent on this feature.

The total "wall clock" time I spent on this feature I estimate around 8 hours. I only spend around 4 hours a day on the computer the first and last commit span 3 days. But I also didn't spend all of my time on this feature. For example, I shipped a Ghostty update, was a guest on ThePrimeagen for an hour, and gave a guest presentation at Zoo's annual all-hands, all during the hours I have available for "computer work" during the same days I was working on this feature 4. So, I think the 8 hour estimate is generous.

Many people on the internet argue whether AI enables you to work faster or not. In this case, I think I shipped this faster than I would have if I had done it all myself, in particular because iterating on minor SwiftUI styling is so tedious and time consuming for me personally and AI does it so well.

I think the faster/slower argument for me personally is missing the thing I like the most: the AI can work for me while I step away to do other things. Here is a picture I took of one of my cleanup sessions while I was making breakfast for my family:

There's all sorts of dismissals about this, such as "I don't want to be coding while I'm cooking" or "Be more present" or whatever. If that's how you want to be, that's fine. In my case, in this specific example, I'm the first person awake in my household and I prep breakfast while everyone else is still asleep. I don't do this every waking moment.

All this is to say: it works for me. I'm really, really not trying to convince you. I'm not associated financially with any AI company. But as someone who has a lot of success with AI tooling and likes to talk about it, people ask me to share examples all the time. That's what I'm doing here.

End

I think the feature is beautiful, works great, and after a final manual review I merged it 5. For Ghostty users who are on the tip release, it is available now. For Ghostty users who are on tagged releases, this feature will be available in Ghostty 1.3.

I'm an outspoken advocate about the importance of sharing agentic coding sessions publicly 6, with one of the reasons being that it's an incredibly powerful way to educate others about how to use these tools effectively. I hope this post helps demonstrate that.

Footnotes

It is currently only shipped to nightly beta testers ("tip" testers) but that is a group of thousands of people. It is merged and will be in the next stable Ghostty release. ↩
Yes, it was good marketing. No, it was not on purpose. And no, I'm not celebrating it, because you don't want users to a fear a tool will take advantage of them. You want to trust that it's there to help. I want presenters (or anyone, really) to want to use Ghostty, and caring about stuff like this is part of that. ↩
The most poetic though would've been to use OpenAI Codex for this. I'm sure it would've done great! This post isn't an advertisement for Amp, it just happens to be the agentic coding tool I use the most currently. ↩
I have a toddler at home so my "computer time" is very scheduled and very limited. 😁 ↩
"Final manual review" is super super super important. This probably shouldn't be a footnote, but I couldn't find a better place to emphasize it. Please don't ever ship AI-written code without a thorough manual review. ↩
My reasoning for this could also be its own blog post, so I'm going to avoid explaining myself further here beyond what I already have. ↩

Zig Builds Are Getting Faster

2025-10-03T00:00:00+00:00

Andrew Kelley famously (or infamously, depending on your views) said "the compiler is too damn slow, that's why we have bugs."1

As a result, one of the primary stated goals of Zig for years has been faster compile times. The Zig team has been working on extremely hard problems to make this a reality (such as yeeting LLVM, writing their own code generation backends, building their own linkers, and marching towards incremental compilation in general).2

The fruits of this multi-year labor are finally starting to show with Zig 0.15.1. The Ghostty project just completed upgrading to Zig 0.15.1, and I'd like to share some real-world build times.3

Build Script Compilation

Zig 0.14: 7sec 167ms
Zig 0.15: 1sec 702ms

This is the time it takes to build the build.zig script itself. The times above were measured by running zig build --help.

A well-written build script should only rebuild itself rarely. However, this is a cost every new uncached source build will pay (e.g. a user downloading the project to build from source one time). As such, it directly impacts the time to build a usable binary.

Full Uncached Ghostty Binary

Zig 0.14: 41sec
Zig 0.15: 32sec

This includes the time to build the build script itself. Given the prior results, Zig 0.15 is building everything else ~2 seconds faster. But, you can still see in wall time the change in this initial build time.

Important: most of this is still using LLVM. Ghostty still can't fully build and link using the self-hosted x86_64 backend, since the backend still has bugs. So, this just shows the general improvements in the Zig compiler itself, even with LLVM in the picture.

Once Ghostty can use the self-hosted x86_64 backend completely, I expect this time to plummet to around 25 seconds or less, fully half the time it would take with Zig 0.14.

Incremental Build (Ghostty Executable)

Zig 0.14: 19sec
Zig 0.15: 16sec

This is the time it takes to rebuild Ghostty after a one-line change to the most core terminal emulation code (adding a log function call to the escape sequence parser).

This build has a fully cached build script and dependency graph, so it is only rebuilding what it needs to. Incremental compilation in Zig isn't functional yet, so this still recompiles a considerable amount of code. Additionally, as with the prior section, this is still using LLVM. By simply dropping LLVM out of the picture, I expect this time to drop to around 12 seconds or so (less the time LLVM is emitting).

Going further, once Zig supports incremental compilation, I expect we'll be able to measure incremental builds like this within milliseconds at worst. But, let's wait and see when that is reality.

Incremental Build (libghostty-vt)

Zig 0.14: 2sec 884ms
Zig 0.15: 975ms

This is the time it takes to rebuild only libghostty-vt after a one-line change. Unlike the Ghostty executable, libghostty-vt is fully functional with the self-hosted x86_64 backend, so this shows the differences in build times without LLVM in the picture.

Similar to the Ghostty executable, this is still rebuilding the full Zig module for libghostty-vt, since incremental compilation isn't fully functional yet. I expect this to also drop to single-digit milliseconds at worst once incremental compilation is a reality.

But still, a sub-second build time for a non-trivial library is amazing. This is the library I'm spending most of my time working on right now, and even in a few short days since upgrading to Zig 0.15.1, I've felt a huge difference in my workflow. Previously, I might tab out to read an email between builds or tests, but now its so fast I can stay in flow in my terminal.

This improvement is most indicative of what's to come in the short term. The self-hosted x86_64 backend is already stable enough to build all debug builds by default and the aarch64 backend is getting there, too. We aren't able to build the full Ghostty executable yet, but I bet this will get ironed out within months.

Faster Builds Are Here

As you can see, building Ghostty with Zig 0.15.1 is faster in every single scenario, despite the fact that a lot of Ghostty still can't even take advantage of the self-hosted backend! And despite the fact that incremental compilation isn't functional yet!

I've loved betting on Zig for Ghostty, and I love that they're focusing on compile times. These improvements are real, and they're here now. And I suspect in the next couple years, the results posted today will look downright slow. 😜

Footnotes

Timestamped link: https://youtu.be/5eL_LcxwwHg?t=565 ↩
This ignores an astronomical amount of work that has gone into making every aspect of the Zig compiler faster, more parallelizable, etc. ↩
All measurements done on the same x86_64 Linux machine. ↩

Libghostty Is Coming

2025-09-22T00:00:00+00:00

Over two years ago, in one of my first public talks about Ghostty, I shared my vision for libghostty: an embeddable library for any application to embed their own fully functional, modern, and fast terminal emulator. Libghostty is finally starting to take shape, and I'm excited to share more details about my plans for it.

The first libghostty library will be libghostty-vt: a zero-dependency library that provides an API for parsing terminal sequences and maintaining terminal state, extracted directly from Ghostty's real-world proven core. It doesn't even require libc!

Disclaimer: This post is predominantly a roadmap update for libghostty and announcing what will be the first shippable component of it. The Zig API is available for testing now, but the C API is not ready and will be coming very shortly. In both cases, it is early testing quality and not ready for general usage.

Why libghostty?

Let's start with some background on why I believe libghostty must exist.

There are hundreds of programs that implement some form of terminal emulation. The most obvious are the actual general purpose terminal emulators like Ghostty, Kitty, iTerm2, etc. But terminal multiplexers like tmux or zellij are also full terminal emulators Editors embed their own terminal emulators too, such as jediterm for JetBrains products, Xterm.js for VS Code, or Alacritty in Zed.

In addition to fully functional terminal emulators, many websites and applications implement read-only terminal emulation to display logs or command output. For example, GitHub Actions output parses simple color sequences (but not much else). And hosting providers like Vercel or Render implement a simple form of terminal emulation allowing line clearing and redrawing within build logs as well as parsing colors.

Many of these implementations are ad-hoc, one-off solutions. They aren't using any shared library or codebase.2 Terminal emulation is a classic problem that appears simple on the surface but is riddled with unexpected complexities and edge cases.3 As a result, most of these implementations are incomplete, buggy, and slow.4

Beyond correctness, implementing any form of terminal emulation is a waste of time for most developers. Terminal emulation is not the core business of JetBrains, Visual Studio Code, GitHub, Vercel, Render, etc. It'd benefit them if they could have a stable, reusable solution that's consistent everywhere.

My answer to this is libghostty: a cross-platform, minimal dependency library that exposes a C API so feature-rich, correct, and fast terminal functionality can be embedded by any application anywhere.

The Beginning: `libghostty-vt`

The first libghostty library will be libghostty-vt: a zero-dependency (not even libc) library that provides an API for parsing terminal sequences and maintaining terminal state such as cursor position, current styles, text wrapping, and more.

Parsing terminal sequences is the most core functionality of a terminal emulator, and is required by full terminal emulators like Ghostty down to simple read-only style-only views such as GitHub Actions or Vercel build output.

The state diagram might appear relatively simple at first glance, but an implementation is unexpectedly challenging to get right. For example, Jediterm doesn't handle intermediates correctly, causing the widely supported "change cursor shape" sequence to swallow a character in every JetBrains editor at the time of this post.

For style-only parsing, many developers skip the full state diagram. Instead, they do some light web searching, parse simple ANSI sequences such as \e[31 or \e[41m, and claim "color support." But style-only sequences are vastly more complex than that, for example they support RGB which itself can be in a dozen formats. And I still haven't found a single web console that renders this complex style sequence correctly.5

libghostty-vt aims to fix all of this.

libghostty-vt is extracted from Ghostty and inherits all of the real world benefits: SIMD-optimized parsing, very good Unicode support, highly optimized memory usage, a robust fuzzed and Valgrind-tested codebase, excellent feature compatibility such as parsing Kitty Graphics Protocol or Tmux Control Mode, and more.

All of this is packaged up into a single zero-dependency C API (it doesn't even rely on libc), allowing it to be easily embedded into any popular language ecosystem.

Given the minimal footprint, libghostty-vt will be widely portable. Initial targets will be macOS and Linux for both x86_64 and aarch64 architectures, since those are the primary targets for Ghostty the application. But I plan to expand support to additional targets such as Windows, embedded devices, and the web via WASM. libghostty will have broader support than Ghostty the GUI, due to its tighter scope.

The Long Term

libghostty-vt is just the beginning. Longer term, we will provide more libghostty-<x> libs that expose additional functionality such as input handling (keyboard encoding is a big one), GPU rendering (provide us with an OpenGL or Metal surface and we'll take care of the rest), GTK widgets and Swift frameworks that handle the entire terminal view, and more.

As fundamental pieces stabilize, we will continue to offer more and more functionality. These will be structured as a family of libraries to minimize dependency requirements, code size, and overall maintenance complexity.

`libghostty-vt` Status

I just merged the pull request exposing libghostty-vt as a Zig module. This PR includes a minimal example program, too. If you're a Zig developer, you can start experimenting with libghostty-vt immediately.

The C API isn't ready yet, but it is what I'm working on right now and it'll be available for testing soon. All of the work required is defining the C API, since the core logic is of course all there and has been used by Ghostty for years. Plus, the Ghostty macOS app already consumes an internal-only C API.

If you look at the internal-only C header, please ignore the mess. It isn't a good C API. It is internal-only and exists to satisfy the needs of the macOS application. This isn't a generally consumable libghostty, although it is used by real commercial products already to embed Ghostty. We'll take a clean slate approach defining the C API for wider usage.

I plan to version libghostty separately from Ghostty the application. This blog post marks the public alpha (not promising API stability) and I'm hoping to motivate some developers to come use it and eventually write some language bindings once the C API is ready.

I hope to ship a tagged version of libghostty-vt within the next 6 months, but it'll all depend on if its ready or not.

Looking for Feedback

We're at the critical stage of libghostty where we're designing the API, and the best way to design an API is with feedback from real consumers. Ghostty is one consumer, we have some community members working on other libghostty-consuming projects, but we could use as many as we can get!

If you see a use case in your projects or organization for libghostty, please join the Ghostty Discord and collaborate with the developers working on this. If you don't want to join Discord, email me (email in the footer of this website).

The state of libghostty at this stage could be considered alpha, so don't expect a polished, stable experience. We're looking for hackers that want to get on the ground early.

The "alpha" quality is with respect to the API (functions and types) itself. The core logic is shared with Ghostty and is extremely stable and proven in the real world.

The Next Frontier

I'm super excited that Ghostty the application has finally reached the stability where we can start moving towards the libghostty goal. libghostty is the next frontier for Ghostty and I think it has the ability to make a far larger impact than Ghostty can as a standalone application itself.

Don't worry, there's plenty of changes for Ghostty the application and none of this diminishes my excitement or plans for that. Wider usage of libghostty will result in a more feature rich and stable Ghostty application, too, since Ghostty itself is a consumer of libghostty.

Boo. 👻

Footnotes

These own the pty to their children, parse all the escape codes, manage screen state, and ultimately "render" by emitting their own escape codes to a parent terminal emulator. ↩
Many websites do use Xterm.js and the GTK ecosystem has libvte. But this only covers a tiny fraction of the landscape and each of the aforementioned examples are limited in their own scope. ↩
I've spent the better part of 3 years working on terminal emulation and we're still finding weird edge cases. ↩
Here are a couple real examples of impactful issues: Jediterm didn't handle intermediates properly, Apple's Terminal.app just bleeds DCS sequences into the output. I'm not calling anyone out specifically, just showing that these issues exist and terminal emulation is very hard to get right. ↩
A lot of general terminal emulators also got this wrong, including Ghostty just 9 months ago. ↩

You Have to Feel It

2025-08-30T00:00:00+00:00

You see a series of checkboxes checked. Schedules met. Requirements satisfied. Demos delivered. It's a good day. Good job, you, good job! A promotion is in sight.

But you didn't feel it. You didn't feel it.

We, as people, feel something with every interaction. Frustration, joy, relief, confidence. A feeling. A person interacts with our work. Our work evokes a feeling. The feeling matters. The feeling is part of the work. The desired feeling is part of the requirements.

When you feel it, you know. The feature makes you smile when you use it. It fits right in, like it was always meant to be there. You want to use it again. You want to tell people about it.

This is the difference. This is what metrics, specifications, and demos miss. They don't capture the feeling. For the people who will use and live in the work, the feeling is part of their daily experience. Which means you can't stop at checking the boxes on paper. You have to sit with it, use it, live with it.

You have to feel it.

Advice for Tech Non-Profits

2025-08-20T00:00:00+00:00

My family and I regularly contribute to various philanthropic causes. In the range of contributions we make, I've noticed that technical non-profits are far and away the worst at attracting eager donors like myself when compared to other causes.

In this blog post, I'll share what I've learned from my own activity with other causes as well as what I've learned from spending more time with donors in general. This blog post will be biased towards larger donations, but I think many of these concepts translate nicely to smaller donations as well.

I am highlighting tech non-profits specifically because these are all concepts that I find other causes get right more often than not, whereas tech consistently gets them wrong. I also have a bias towards wanting technical organizations to become more successful.

How do I donate?

It is surprisingly difficult to simply figure out: how am I supposed to give you money?

Tech projects usually nail the metaphorical swipe-a-credit-card donations to provide small one-time amounts and specific smaller tiers ($X/month). But a lot of donors don't work this way. I don't work this way.

I donate through a donor-advised fund (DAF). To donate, I need -- at a minimum -- the verifiable EIN of a tax-exempt organization (DAFs can only contribute to registered non-profits). On top of that, I usually need a physical address and the contact information for a real human that can work with the fund managers to process the donation. DAFs are just one of many vehicles for donation, though.

The best non-profits have a dedicated "Donate" page that has an obvious and easily accessible list of donation methods: credit card, check, donor-advised funds, employer matching, stocks, legacy giving (will, trust, retirement accounts), etc. Each donation method leads to its own dedicated page with very specific information about how to donate via that method.

It may sound obvious, but you want to make it as easy as possible to initiate the financial transaction. And yet, a lot of non-profits make this needlessly difficult.

Why should I donate?

Attracting donors is not so different from attracting customers: you have to engage in some level of marketing. For non-profits, the question is: why should I donate?

Technical people tend to be bad at this for their own technical projects. So its not surprising to me that technical people are also often bad at this for their non-profits they're involved with.

I, too, used to have the attitude of "the value is obvious" or perhaps the idea that "if you build it, they will come." This is true for a small, small segment of the "market,"1 but for the much larger segment, you have to educate.

Aim to answer the following questions:

What do you do?
Why is what you do important?
Who is benefiting from what you do?
Why do you need money to do what you do?
What have you done recently?
How has money enabled you to do what you did recently?
How much money do you need to do what you do?
Why do you need that much? Is it going up, or down? Why?
How are you spending your money?
Who else is donating?
Why aren't more people donating?

A lot of these questions -- especially the financial ones -- can be answered by reading an IRS Form 990 2, but giving a more human-friendly version of the information is always helpful.

Technical projects often don't answer any of this. They either consider their value obvious or simply point to the projects they build and expecting the viewer to gather enough information based on that.

But that isn't enough. I'm a technical person, I can look at a project and understand its technical value. I can conclude "yes, this is a cool thing that I'd like to continue to exist." But that doesn't answer the very basic questions of: how much and why? Beyond that, there's so many more questions I have (as listed above). If you want to attract more donations and appeal to a broader donor base, you must answer these very basic questions.

What is my donation doing?

A non-profit typically issues an annual impact report. I've only seen a couple technical non-profits produce an impact report and of those, they were extremely amateur compared to the average non-technical non-profit. Most don't produce an impact report at all, which is a terrible mistake.

An impact report is the human-friendly annual report of what the organization achieved and its goals for subsequent years. It usually includes a report of the financial health of the organization, as well.

The couple technical ones I've seen 3 did a good job on the what, but it read too much like a product keynote. The what was good! But its more important to relate that to finances: how did the finances lead to that? how will more finances achieve more? what is the strategy for increasing fundraising?

These are all important questions for few reasons.

First, a donor generally doesn't want to be part of a small group of donors. I specifically care deeply that the organization will have a healthy group of donors so that I'm just a piece. Fundraising goals and marketing is part of that. I'll donate more if I know more people are donating.

Second, the larger the fundraised amount (either individually or in aggregate), the more I want to see results, mainly so that the money isn't being wasted. I think most non-profits aren't trying to waste money, but the goal of a non-profit is to achieve some public good, and its easy to inefficiently allocate funds. Non-profits especially can't afford to be inefficient allocating funds (but too many are).

To that end, impact reports should also contain measurable goals. And in subsequent reports they should contain reflections on those goals. One thing I really try to look for is cases where a goal was missed and how that organization reacted. As with other things, how one deals with failure often speaks more loudly than how one deals with success.

Some people misunderstand the desire for measurable goals and results as a growth mindset and needing to do more, more, more. That's not the ask. The goals are about accountability, even if they're steady goals.

If I can't find that information, its okay, because the next thing I'll do is try to talk to a real human, which I cover next.

Unreasonable Effectiveness of Human Connection

Talking to a human is unreasonably effective. You can discover information, align goals, resolve arguments, and more so much more quickly and easily by talking to someone face to face.

Technical non-profits tend to lack a meaningful amount of face to face connection. They lean too hard on asynchronous, textual mediums such as IRC, Matrix, or email. This sort of conversation may work for technical work and communities, but it doesn't work for financial transactions (non-profit or otherwise).

I can understand the expectation that donors should do their own research, consume the various written material, and be self-sufficient. This is how a lot of technical projects -- especially open source -- work. But that's not how you do sales, and a non-profit is ironically a strongly sales-driven organization.

Let me repeat that, because its the uncomfortable truth that a lot of people don't like to process: non-profit organizations are sales-driven organizations. You have to engage in a lot of the standard tactics a business has to in order to attract and retain donors in order to pursue your mission statement (which, for a non-profit, is by definition a public good, which is very nice).

My advice for technical organizations is to make it easy to get in touch with a real human being via phone (yes, a phone!) or at worst a video call. In 30 minutes to an hour, a prospective or current donor can not only receive information, but connect in a way that is very difficult to do in other ways.

This is also a retention strategy. Schedule meetings with your existing larger donors. If you're in town (or they're particularly heavy donors), try to schedule dinners. If you're going to be at the same conference, schedule a lunch or drinks. Use this time to remind them of the mission, the recent achievements, how much they're helping, etc.

Honestly, become friends. I genuinely mean this. For for-profit organizations, it can be a lot more transactional. For non-profits that are mission-driven, these are usually people that are highly philosophically aligned and its likely you'll get along at a personal level. Become friends, it makes the whole thing a lot more fun for both parties.

Conclusion

A for-profit is a machine that takes money and returns more money to investors. A non-profit is a machine that takes money and returns social impact to donors. They're very different, and yet uncomfortably alike.

I believe people sometimes tend to believe a non-profit organically gets donations from little-known sources -- the larger group of do-gooders. But, most successful non-profits I've worked with (even the smaller ones) that also do the best work have people aggressively working on the "business" of donations. This should be unsurprising, since the ability of most non-profits in the early stage is directly correlated to the funding they can get 4.

I used to wonder why a non-profit needs a CEO/President, sometimes with a group of full time employees. There's a lot of reasons, but attracting and retaining donors is a big, big job. Actually, its also a very well defined job, typically called "non-profit development."5 You can even go to school for it, similar to studying business management.

I want to see new and existing technical non-profits be successful. I think the vast ecosystem of existing technical non-profits are leaving a ton on the table by being -- quite frankly -- terrible at attracting and retaining donors. I hope this blog post helps illuminate the work involved and paints a roadmap of how non-profits can improve.

Footnotes

I'm sorry, but despite being a non-profit, you inherit a lot of the same challenges that a business has. ↩
I've gotten really adept at reading 990s. ↩
I don't want to link them because I'm not trying to call anyone out. ↩
At later stages with larger dollar amounts, it can be hard to scale that success. ↩
If you web search for "non-profit development" you'll find many resources. ↩

We Rewrote the Ghostty GTK Application

2025-08-14T00:00:00+00:00

We just completed rewriting the Ghostty GTK application fully embracing the GObject type system from Zig and also verifying with Valgrind every step of the way. The result is a more feature rich, stable, and maintainable Ghostty on Linux and BSD.

There are multiple interesting, technical topics from this process, but I want to focus in on two (1) interfacing with the GObject type system from Zig and (2) verifying a GTK application with Valgrind and reflecting on the memory issues Valgrind found in a Zig codebase.

Background

First, some quick background. Ghostty is a cross-platform (macOS, Linux, FreeBSD) terminal emulator. Ghostty sets itself apart from other cross-platform terminal emulators by using a platform-native application or GUI framework for each platform 1.

On macOS, Ghostty is a multi-thousand line Swift application built with Xcode. On Linux and BSD, Ghostty is a multi-thousand line GTK application leveraging direct integrations with X11, Wayland, etc. Tying it all together, there is a very large shared core written in Zig that exports a C ABI compatible API.

For full motivation on why Ghostty was the way it was before and why we decided to rewrite the GTK application now, see the original "gtk-ng" PR. I'm going to keep this post focused on the takeaways rather than the motivation.

GObject Type System and Zig

Whatever your feelings are about OOP and memory management, the reality is that if you choose GTK, you're forced into interfacing in some way with the GObject type system. You can't avoid it.

Well you can avoid it and we did avoid it. And it leads to a mess trying to tie the lifetimes of your non-reference-counted objects to the reference counted ones. There was an entire class of bug that kept popping up in the Ghostty GTK application that could basically be summed up as: the Zig memory or the GTK memory has been freed, but not both.

Besides the correctness issues, avoiding the object system also forced us away from using GTK-native features such as signals (events), properties (which can be bound to by GUI elements), actions (invoking one-way behavior from afar), and more.

Let's look at a concrete example: reloadable configuration. The configuration in Ghostty is represented by a Zig-owned Config structure. Many different parts of the GUI need to be aware of the configuration: windows, tabs, menus, splits, etc.

Reloading configuration was a complicated, CPU-intensive (relatively), and error-prone task because we had to ensure the entire GUI updated before we could free the old Config.

Now, the Zig Config structure is wrapped in a reference-counted GhosttyConfig GObject. When we reload the config, we overwrite our property and let the GObject property change notification system ripple through the application (sometimes across multiple event loop ticks). When the old configuration no longer has any references, it frees. Conceptually much simpler.

In addition to memory management, we can now more easily create custom GTK widgets. This let us fully embrace modern GTK UI technologies such as Blueprint. For example, here is our terminal window Blueprint file. This has already led to more easily introducing GUI features like a new GTK titlebar tabs option, an animated border on bell, etc.

Valgrind with GTK and Zig

This topic deserves an entire blog post on its own. The gist of it is that from the first PR to the last, we've run every change and Ghostty feature through Valgrind and addressed any issues to ensure that there are no memory leaks, undefined memory access, etc.

Running Valgrind on a GTK application is pretty nasty. We need a pretty large suppression file. I know its a lot, but 80% of that file is provided by GTK itself. The remainder is primarily 3rd party libraries and GPU drivers. There are perhaps one or two suppressions I find suspicious (and commented as such).

The important part is we were able to identify a number of bugs along the way that would've definitely slipped under the radar. For example, I learned that if you forget to clear a GObject WeakRef during dispose, it'll cause undefined memory access in the target (referenced) object when it disposes at some point in the future (can be hours, days!). That undefined memory access happens to be fine 99% of the time, but once in awhile it causes a crash. Fun! Valgrind found this without problem.

Memory safety seems to... erm... activate certain conversations. So let me say two things:

Our Zig codebase had one leak and one undefined memory access. That was really surprising to me (in a good way). Our Zig codebase is large, complex, and uses tons of memory tricks for performance that could easily lead to unsafe behaviors. I thought we'd have a lot more issues, honestly. Also, the one leak found was during calling a 3rd party C API (so Zig couldn't detect it). So this is a huge success.

Zig has a leak-detecting debug allocator and various safety checks that are only on during debug and test builds in the Ghostty project. Additionally, Zig has integrations with Valgrind. For example, Zig emits a Valgrind client request to mark some memory as undefined whenever you set a value as undefined (keyword) in Zig. This helps find even more issues.

This experience has really shown me that this is working, despite not having any of these protections in our release builds.
All other memory issues revolved around C API boundaries. Every other issue we found (and there were dozens) was directly within the complex lifetimes of the GObject system or on C API boundaries. My takeaway here is that you absolutely need tooling like Valgrind to safely call across C APIs (even if they're not written in C).

For most complex libraries that expose a C API, the C API represents a boundary where object lifetime is transferred or blurred. Whatever language you're using to interact with it, the safety you're guaranteed is only as good as understanding the semantics of the API and writing a good wrapper.

The features Zig provides around memory safety are well documented. There are a lot of academic or theoretical discussions about what Zig does or does not do and whether that's good or bad. Those are valuable discussions to be had, but so are empirical results. This process is showing empirical results from a large, complex, multi-threaded, multi-platform Zig project when every individual feature is run with scrutiny under Valgrind. Takeaway from that what you want, I don't want to start any flame wars!

Going forward, I plan to continue to run every GTK PR within Valgrind and improving our project documentation so maintainers and contributors can do so as well (we already have a couple up and running!).

Conclusion

This is now my 5th time writing the GUI part of Ghostty from scratch: once with GLFW, once on macOS with SwiftUI, then on macOS with AppKit plus SwiftUI, once on Linux with GTK procedurally, and now on Linux with GTK and the full GObject type system.

Each time, I've learned something new and valuable, and I've carried that experience into each iteration (and across platforms). Even this time, I've learned some new tricks that I plan on taking back over to macOS.

I want to also highlight that the entire GTK subsystem maintenance team hopped on board to help complete the rewrite. They did a lot of work, too.

The new, rewritten Ghostty GTK application is now the default when you build Ghostty from source on main, and will be shipped to everyone in the 1.2 release coming in just a few weeks.

Footnotes

Linux people get really worked up when I say "platform-native". There is no such thing on Linux, but reasonable people agree that something like a GTK app (or Qt) feels "native" on most desktops over other applications. ↩

"As Code"

2025-03-04T00:00:00+00:00

I've always personally defined the "as code" suffix in "X as Code" to mean "a system of principles or rules"1. This is in contrast to the popular interpretation of "as code" to mean "as programming."

I feel the need to write this short blog post and clarify my intent because I'm often personally a target of this misunderstanding due to my history of starting Terraform 2 which is a flagship "X as Code" tool.

My intent with "X as Code"3 was always to get knowledge out of people's heads and into a more inscribed system. Once inscribed, knowledge and process can be shared, versioned, iterated upon, etc.

The relation to programming is that codified knowledge tends to also be computer-readable and comes with the full benefits of that (e.g. automation, validation, etc). However, I don't believe that implies that all the requirements of modern programming should be applied to "as code" systems.

As an additional point of history, I coauthored the Tao of HashiCorp over a decade ago (before Terraform!) and this mindset is still present in the two "codification" sections, which remain mostly unchanged since their original writing. This helps provide additional framing for my intent with "as code."

Please do not take this post as a criticism of the "as programming" ideals, a claim that "as code" is perfect, or that "as code" should always be interpreted this way 4. None of these are true. I only want to clarify my personal intent and use of the term historically.

Footnotes

https://www.merriam-webster.com/dictionary/code ↩
I haven't worked on Terraform in years and I left HashiCorp in 2023. I also only claim credit for starting Terraform (and I wasn't alone); it has been maintained by others for many, many years now. ↩
I did not coin the term "X as Code" or "Infrastructure as Code." I don't know who did but it predates Terraform and my career. Some unsolicited business advice: don't create new market categories, enter existing ones and let your competitors bear the cost of educating the market. ↩
The definitions of things is a social process, after all. Where the herd goes, so will we all. ↩

Welcoming Ghostty Subsystem Maintainers

2025-02-07T00:00:00+00:00

I'm excited to share that there are eight newly promoted subsystem maintainers for Ghostty. These are the first maintainers to be promoted since the project's creation, and I'm thrilled to see the project grow in this way. Adding additional, independent maintainers is an important part of any open source project's long-term health and stability.

While Ghostty has only been public for a little over a month, the project was in private beta for almost two years. A benefit of this is that members of the community have already made significant contributions to the project and repeatedly shown themselves to be kind and helpful to others.

All of the new maintainers announced today were part of the private beta and have been active contributors and community members for months if not over a year. They each have dozens of individual merged PRs into Ghostty already, but have also been helpful and active in issues, Discord, etc.

Please join me in welcoming the following maintainers, in alphabetical order:

@gpanders - Terminal Emulation
@jcollie - Linux and GTK
@jparise - Shell Integration
@pluiedev - Linux and GTK
@Qwerasd - Font and Rendering
@rockorager - Terminal Emulation
@trag1c - Discord bot
@tristan957 - Linux and GTK

Subsystems

We've decided to follow a subsystem maintainer model for Ghostty. Rather than promoting "core maintainers" who are responsible for every part of the project, we've identified key subsystems within the project with subject matter experts and promoted these people to a position of authority within their respective subsystems.

The exact "subsystems" emerge organically as contributors show themselves to be knowledgeable, excited, and interested in a particular area of the project. To start, we've identified the following subsystems, in no particular order:

Terminal Emulation - Responsible for escape sequences, pty handling, subprocess management, etc.
GTK - Responsible for the GTK app runtime and Linux in general. Also includes the lower level X11/Wayland integrations, cgroup management, and so on.
macOS - Responsible for the macOS app runtime and macOS-specific features, configurations, etc. No one was promoted to this subsystem today, but we expect to add maintainers here in the future.
Font - Responsible for font discovery, rasterization, shaping, coloring, etc. Anything font-related. Covers all platforms, so these people have expertise with FreeType, CoreText, etc.
Renderer - Responsible for core rendering abstractions as well as specific renderers like OpenGL and Metal. More generally responsible for any issues related to rendering.
Shell - Responsible for shell completions, shell detection, and any other shell interactions. Expected to cover all supported shells, including bash, zsh, fish, etc.
Discord Bot - Responsible for the Discord bot, which is an important part of our community management and support.

Privileges, Responsibilities, and Goals

The goal of promoting subsystem maintainers is to enable Ghostty to scale more effectively. Issues can be resolved more quickly and improvements can be shipped faster when trusted maintainers have autonomy to make decisions within their subsystems.

Subsystem maintainers have the ability to independently define the roadmap of their respective subsystems, triage issues, merge pull requests, etc.

Subsystem maintainership is a voluntary role and maintainers are not expected to dedicate any amount of time to the project. However, if a maintainer is inactive for a long period of time, they may be removed from the maintainers list to avoid bitrot or outdated information.

Notably, maintainers have NO OBLIGATION to review pull requests or issues in their subsystem. They have full discretion to review or not review anything they want. This isn't a job! It is a role of trust and authority and the expectation is that maintainers will use their best judgement and work on what they find interesting and rewarding for themselves and the project.

For more specific details on the subsystem maintainer process, see the CODEOWNERS file. There is a detailed comment that outlines the entire system.

Welcome and Thanks

I want to extend a personal thank you to each of the new maintainers both for accepting the role as well as their already significant contributions to the project. Besides that, they've all just been wonderful people to get to know and work with.

Please join me in welcoming these new maintainers to the Ghostty project. 👻

Ghostty: Reflecting on Reaching 1.0

2024-12-26T00:00:00+00:00

This isn't a release announcement. Ghostty 1.0 is out. You can download it and read about it on the Ghostty website. This is a personal reflection on the project.

Ghostty 1.0 is out.

If you told me two years ago that I would be releasing a terminal emulator, I wouldn't have believed you. I've always been a fan of the terminal, my entire career was built around shipping terminal-first software. But they're a solved problem, right? That's what I thought.

I started the project in 2022 merely as a way to play with Zig, do some graphics programming, and deepen my understanding of terminals. I never intended to release it. I didn't think there was innovation to be had. I thought I would learn a lot over a few months and move on.

But as I worked on it, I looked at other terminals differently. I saw tradeoffs that I didn't like. I saw features that I wanted. I saw performance that I could improve. I saw stagnation. There are many fantastic terminals out there and you should use them if they work for you. But I wanted something different and thought maybe others did too.

And so Ghostty was born. It's not perfect, it's not done, it's not for everyone. But it's mine. It's a reflection of my values and my vision for what a terminal could be.

To learn more about how Ghostty differentiates itself from other terminals and my vision for the project, read the Ghostty 1.0 is coming post.

The Private Beta

The most controversial part of Ghostty was the private beta. Oh boy, the private beta. I vastly underestimated the effect this would have on the project. Good and bad.

The Private Beta: The Good

First, why a private beta? The primary reason was to manage my own personal bandwidth. I began publicly sharing the project shortly before my first child was born. I have experience launching software and I knew the stress that comes with it. I wanted to avoid that stress and be able to focus on my family. I felt I could curate a small group of interested users to throttle issues, only increasing the user base as I felt comfortable.

A secondary, but much less important reason was that I felt a terminal emulator more than most software either works or it doesn't. You can't ship a terminal emulator that emulates only half the features Vim needs. You can't incrementally improve a terminal emulator below a certain threshold of functionality. I wanted to ensure that the first public release met that threshold. I wanted people to be able to use it productively and professionally right away.

On these two fronts, the private beta was a massive success (far beyond my expectations). I was able to manage my bandwidth and focus on my family. For the first year of my daughter's life, I woke her up every morning, I played with her every wake window, I went to every doctor's appointment, I was there for every milestone 1.

And the beta community was amazing. They were patient, they were understanding, they were helpful. They found bugs, they provided feedback, and they made Ghostty so much better than it would have been without them. I can't thank them enough.

The Private Beta: The Bad

Everything else was an unintended consequence of the private beta. The hype, the frustration from those who couldn't get in, the elitisim perceived by some, etc.

I didn't anticipate the hype. Some people think I am lying when I say this. I'm not. I'm not so naive to think that private betas and exclusive access don't generate hype in principle. But I didn't think many people at all would be interested in a terminal emulator. I thought I was building boring software for a niche audience. No hype!

But I was wrong, and the consequences were real. People were frustrated that they couldn't get in. People felt left out. People felt like I was being fake to generate hype. The waitlist grew larger than I was comfortable allowing in (given my prior stated priorities).

I'm sorry about that. All I can say is that I didn't intend for this to happen. I ramped up beta invites to try to get as many people in as I felt comfortable with (well, a bit beyond that). We ended the beta at around 5,000 users in a Discord of 28,000 at the time. Not quite the percentage of access I wanted for people but more than I could handle.

The good news is Ghostty is now public and everyone can use it! I hope we can put the negative aspects of the private beta behind us and focus on the future.

One more negative aspect of the hype is the expectation of Ghostty being revolutionary. It is and it isn't. Ghostty has different goals and tradeoffs than other terminals. For those looking for those properties, Ghostty is a breath of fresh air and does things that no other terminal does. But for others, it's just a terminal. And that's okay. I hope you find a terminal that works for you and I don't claim that Ghostty is the end all be all of terminals.

The Tech Stack

Ghostty has an unconventional tech stack and architecture: Zig for the core and platform-specific code for the GUIs. More details on the tech stack can be found in the original talk I gave on Ghostty.

Two years later, I'm extremely happy with the tech stack and architecture. I think it was the right choice for the project but more than that, I think this architecture could be the right choice for many projects 2.

Zig has been an absolute joy to work with. I have fun writing Zig every single day and that fun hasn't diminished a bit over two years. The build system is fantastic, the community is amazing, and the core maintainers are brilliant. My excitement is well known and I've also put my money where my mouth is by sponsoring the Zig Software Foundation.

The split between shared core written in Zig and platform-specific GUIs has also been a success. I've been able to effortless integrate platform-native experiences into Ghostty while keeping over 90% of the code shared.

The beta community has also had no problem contributing to the project. I think this shows that despite being a new, niche language, Zig is easily approachable and productive for new contributors. This is great news for the future of the project.

The community that formed around Ghostty was unexpected and amazing.

To be specific, I'm talking about the private beta community. The public community is a bit of a wild west due to the unstructured nature of not having access to the software. But the private community has focus and purpose and it has been a joy to be a part of.

The Ghostty community is a group of people who are passionate about terminals (of course!) but also about performance, design, software quality, doing things right and for the right reasons. It's a group of people that are pleasant to be around and collaborate with. It's a group of people that I've really enjoyed getting to know and I'm excited to continue to work with.

For me personally, it's also unlikely because most people in the Ghostty community are also new to my work. Most don't have a background in infrastructure and therefore aren't familiar with my previous work. It has been fun to build a new community and it reminds me a lot of the early days of my career when I was building a community around my first open source project.

A Post-1.0 Future

Ghostty 1.0 is out but the project is far from done for me. Even the 1.0 is less complete than I would have liked! But I had to draw a line in the sand somewhere and I think the 1.0 turned out great.

For the short term, I want to continue focusing on the "best existing terminal" goal. I want to shore up the features that didn't make it into 1.0 and fix the bugs that are still present. I want to make sure that the foundation that Ghostty is built on is solid for future innovation.

In the medium but not too long term (within 2025), I want to shift focus to release a stable and standalone libghostty that can be used by other projects to build their own terminal emulator frontends. I think libghostty is the most promising part of the project for the long term impact Ghostty can have within the tech community.

But, regardless of goals, Ghostty will always first and foremost be a passion project for me. I work on this project because it's fun and I want to make sure the community and I don't lose sight of that.

Thanks

I believe nothing in this world is accomplished alone. I may have started Ghostty alone but I didn't finish it alone and I have so many people to show appreciation for along the way.

The impact of the Ghostty beta community cannot be overstated. I said this already in this post but Ghostty is only as feature rich and polished as it is thanks to the attention to detail and feedback of the beta community. I'm extremely grateful to everyone who participated in the beta and helped make Ghostty what it is today.

The Discord mods deserve a special shoutout. They worked hard to keep the peace and keep the community focused on the right things. I could see their effort daily in trying to create an environment that allowed me to focus and the beta community to thrive. We have less than 10 mods for 30,000 people and they did an amazing job given the circumstances 3.

And finally, and most importantly, I want to thank my wife. We're first time parents and juggling a new baby with a side project I wanted to find time to work on was no small feat (even with the private beta aspect). She helped me find the time to work on Ghostty and she patiently listened (fell asleep) to my ramblings about font rendering.

I hope you enjoy Ghostty 1.0 and feel the love and care that went into it. I'm excited to see where we go from here!

Footnotes

I had to leave for a couple weeks over the first year so I did miss some days, but I was as present as I could be. ↩
I'm not saying I invented it! But it isn't something I see often. ↩
I will acknowledge that the mods and I wielded the ban hammer liberally. I'm sure we kicked out some good people. But given the size of the Discord we had very little patience for people who acted out. ↩