Porting Ghostty to Rust

Rustty is a port of Ghostty from Zig to Rust, done over 112 days with Claude Code agents.

The two terminals below run one shell session in your browser, each drawn by a different terminal engine compiled to WebAssembly: Rustty's in the first and Ghostty's in the second. Type in either one. The shell's output goes to both, so you can compare what each engine draws.

The front end is wterm, an Apache-licensed terminal for the web from Vercel Labs. wterm draws what a terminal engine hands it through a small interface, and one of the engines it ships, @wterm/ghostty, is Ghostty's Zig code compiled to WebAssembly. I had Claude write a second implementation of that interface on top of Rustty's engine, function for function, so wterm runs the Rust engine without a change to its own code. The two binaries are close in size, the Rust one slightly larger. The shell is just-bash, also from Vercel Labs: a bash interpreter written in TypeScript with an in-memory filesystem, so what you type stays in your browser.

The scripts in the demo folder exercise the engine on purpose: true colour, the underline styles, wide and combining characters, hyperlinks and window titles. One limit you can hit is images: wterm's Zig build can draw kitty graphics, but Rustty's engine leaves that feature out of its WebAssembly build, following Ghostty's own default for that target, so the Rust engine draws none. It is a known gap between the two engines on this page. I compared the two engines' terminal state on recorded sessions of real programs (ls, git log, vim, top and less), on hand-written edge cases and on seeded random byte streams. They were identical on every recorded session. Elsewhere they differ in a short list of cases, nearly all traced to wterm shipping an older Ghostty release than Rustty's reference commit. Rustty itself still has no web terminal app, as the limitations say; this one borrows wterm's.

Ghostty is a terminal emulator written in Zig by Mitchell Hashimoto and its contributors. Rustty is a port of it to Rust: the terminal engine, the font and rendering stack, the app runtimes, the C API libraries and the build, with Ghostty's macOS Swift app running on top. Rustty's behaviour is defined by Ghostty's, so most of the credit for it belongs to Ghostty's authors.

The scope is narrow on purpose. Rustty aims for parity with one pinned Ghostty commit: everything Ghostty does at that commit, nothing it does not. The one exception is bugs. When the port finds a Ghostty bug, it fixes it instead of copying it.

Rustty ran on one Claude subscription that I shared with other projects, and the subscription's weekly limit set its pace. Agents committed on 59 of the 112 days. Without the limits, I estimate the same work would have taken about 46 days (41–51).

Unless a figure says otherwise, everything in this article was measured on 2026-10-10 at Rustty 58aa62a81, against Ghostty 246f70287, the reference commit at that time, on a MacBook Pro, Apple M4 Pro, 14 cores, 48 GB. Two kinds of figures are older. The Linux sanitizer runs are from the previous reference commit, a60e9e2a5, and their re-run at the current one is still to come. Figures drawn from the Claude Code and Codex session records (prompts, usage and cost) stop at 8 October, because later sessions include the research for this article and cannot be told apart from the port's own. Line counts are code lines as counted by tokei. The Zig side includes the Zig dependencies the port also covers: the libxev event loop, libvaxis, z2d and zf.

The card's test counts differ in scope: 7,287 Rust tests across every crate, including the ported libxev, libvaxis and z2d and the -sys wrappers, against 4,433 test blocks in Ghostty's src/ alone. Matched module by module, with the dependencies on both sides, it is 7,221 against 4,911, the comparison the translation lens uses. The stricter check is per module. In all 211 mapped Zig modules, the Rust test count is at or above the Zig one, and none falls below.

I went back through my prompt history to remember why I started this. Before that night there is no question about porting Ghostty, or about Zig. I was a Ghostty user and nothing more. The honest answer is that I wanted to see what was possible, and partly that it seemed like agents could do it. The first prompts were typed on the night of 20–21 June, Pacific time, in a directory that held no Rustty yet:

21:42 · "Checkout ghostty repo on github, in ~/projects."

22:40 · "…help me gauge any benefits (perf, rendering latency, memory, etc. others too) to doing a rust zig->rust port."

23:08 · "Assume I wanted to go ahead and do it, a full fidelity port, 100% functional parity, verified by all tests ported, every assertion, full coverage no exceptions…"

00:27 · "Lets call our port rustty…"

None of this was a plan yet. The third prompt is still hypothetical ("Assume I wanted to go ahead"), and the name came last. From that last prompt, Claude wrote a prompt kit: a "Parity Constitution", a master prompt and one prompt per phase. The kit pinned Ghostty 4749c4e93, Zig 0.15.2 and the baseline machine. One line in it set the priorities for the rest of the project: "Parity is the invariant; performance is the gradient". I launched the master prompt, and agents wrote the plan. The first commit landed 17 h 54 min after the clone prompt.

"Port" has a specific meaning here. It is a set of commitments, each one checked by a test or a gate:

• Parity with one pinned commit. The reference started at 4749c4e93 and moved forward 8 times, to 246f70287. A change on Ghostty's main branch counts only after the reference moves past it and the port absorbs it. I call the porting that brings the port up to a new reference commit an upstream catch-up.
• Nothing lost, comments included. The full-fidelity rule says: "Every comment is preserved — doc comments, inline comments, TODOs, license headers, ASCII diagrams, citations/spec references. […] Comments are NEVER dropped or summarized away." A fuzzy-matching check tracks 34,371 distinctive Ghostty comments and finds none missing, and 79 deliberately not carried, each excused by a written rule.
• The same C libraries. FreeType, HarfBuzz and the rest are vendored and built from source, with no pure-Rust substitutes. Ghostty itself is never a build dependency. It is only a reference to compare against.
• A byte-compatible C ABI. Rustty's terminal library ships the same header family as libghostty-vt: 35/35 headers and 208/208 functions. The embedding API, which the macOS app calls, maps 91/91 entry points one to one.
• The Swift app is reused, not ported. On 12 July, Ghostty's macOS app was imported byte-identical: 35,733 lines, the same count as Ghostty's at the first reference commit. At first it linked through ghostty_* alias symbols. A later rebrand renamed it to call rustty_* directly. The work was the C ABI underneath it.
• Parity is the whole scope. Two prompts drew the boundary. On 30 July: "Everything is in scope if ghostty supports it." On 28 September: "the aim is rustty parity with the exception of copying bugs".

The bug exception arrived late, on 11 September. Before that, the port copied Ghostty's bugs faithfully and noted them for upstream. The rule that replaced this begins: "Fidelity is owed to what the reference is for, not to its bugs." A later section tells that story. In short, 136 live defects in Ghostty and its dependencies are fixed in the port instead of reproduced, and 142 recorded defects are listed in a public log of deliberate differences from Ghostty.

No Rust was written on the first day until Ghostty had been turned into numbers the port would have to match. On 21 June, agents worked on the pinned checkout:

• They ran Ghostty's full test suite and confirmed it passed.
• They inventoried every Zig test block: 3,234 tests holding 11,975 assertions.
• They counted 42,069 comment lines across the 512 files of src/.
• They recorded 28 benchmark results and the binary sizes of Ghostty's release build as the performance baseline.
• They built a byte-level differential harness and showed that it fails against an empty port, so a pass from it means something.

The port's rules state the idea plainly: "Every test {} block → a Rust test, assertion-for-assertion." The test count taken on the first day is a contract. The first audit then caught the contract itself being wrong. The first count missed the tests that Zig names with an identifier instead of a string, and two documents had frozen the total at 3,189. Under an exact-match reading, a complete port would have failed the gate. The phase's reviewer re-derived the total and blocked the plan until both documents said 3,234.

Gates went in on the first day too, and from the start they had to prove they could fail. In 10 of 12 of the first gate scripts, a self-test injects a violation and expects red: a crate cycle, a corrupted byte, or a crate marked done with zero tests. The rule behind them:

Never weaken, skip, xfail, or loosen a test or gate. A red gate that cannot be made green honestly → STOP and surface a precise blocker.

Memory-safety checking also started early. Miri became the primary undefined-behaviour and leak gate on day 1, in place of a custom tracking allocator. On day 3 I asked for AddressSanitizer and LeakSanitizer to complement it, and a sanitizer-matrix gate followed the same day.

The widget replays the contract filling up. Each square is one Zig test. It turns copper when its module's Rust test count reaches it. 86% of the first-day contract was covered within a week. The whole of it was covered on 30 July, one day before the reference moved for the first time. After that the target kept moving. Every move of the reference brought new Zig tests. The widget counts string-named and anonymous test blocks, the form its per-module mapping can match: 3,189 at the first reference commit (the contract's 3,234 also counts the identifier-named tests) and 4,433 at the current one.

A count is a weak contract, and the widget shows where. When upstream added tests to a module that already had surplus Rust tests, the count was met before anything was ported. That happened to 616 of 1,049 newly added Zig tests. So a per-name checklist joined the count: every live Zig test must name its Rust counterpart or give a written reason. The census in the last panel previews a later failure, tests that passed while checking nothing, which the section on checks covers. At the current reference commit, the checklist stands at 4,287 of 4,287. It matches tests by name, so it covers the string-named Zig tests outside the build and benchmark code, a subset of the 4,433 blocks counted above. 7,287 Rust tests stand behind it.

Zig compiles Ghostty's src/ as one module, and its files import each other freely. At the first reference commit, the runtime imports among its 512 files formed a single strongly connected component of 345 files, with 1,410 import edges inside it. From any of those files you can follow imports and come back to it. The hub is easy to miss. quirks.zig, a small assert helper, is imported by 113 files in the cycle. One font workaround in it imports the font package, so the assert helper reached the font stack, and from there config, the app runtime and the renderer.

Cargo does not allow cycles between crates, so the port needed crate boundaries across which no import points upward. The crate-structure design written on day 1 listed 14 cuts. The rule for them was strict: "Cycle-breaking refactors […] are behavior-preserving structural changes ONLY". A cut may move code. It may not change logic, comments or tests. By mechanism, they break down like this:

• Six traits. A lower crate defines an interface, and the upper crate implements it. For example, the renderer defines the inspector overlay it draws, and core depends on the app-runtime interface traits instead of the GTK or macOS backends.
• Five moves. A file or type moves down into a lower crate. The backend enums went to a build-config crate, and grid sizes to shared render types.
• Two splits. The global.zig hub became a leaf crate holding process-wide state, and the C API layer moved out of the terminal engine into a crate on top of it.
• One injection. Config passes the values the font stack needs, so font never depends on config.

The widget tests each cut by removing it while keeping all the others. Every removal leaves a cycle in Cargo's terms, so every cut is load-bearing. After the planned cuts, a smaller knot of renderer, inspector, terminal I/O, core and crash files remained. It held together through one upward edge, from the crash reporter into the surface. One more seam cut it: a small trait local to the crash crate, which core's surface implements.

Three of the layering decisions shaped the code more than the others:

• Font sits below the terminal engine. The font crate does pure parsing (OpenType, sprites, atlas, metrics). The terminal crate depends on it, never the reverse. Shaping, which needs the terminal's types, moved into a separate crate above both. This was decided on 25 June.
• The renderer owns its view of the configuration. Config depends on the renderer, because a config change is sent to the renderer as a message. So the renderer cannot name a config type.
• Process spawning lives in terminal I/O. The original plan put Ghostty's Command.zig in core, which created a new cycle. It moved to the terminal-I/O crate, which core already depends on.

The renderer's case shows the pattern. In Ghostty, the renderer reads fields straight off the config struct (src/renderer/generic.zig at 4749c4e93):

pub fn init(
    alloc_gpa: Allocator,
    config: *const configpkg.Config,
) !DerivedConfig {
    // …
    // Get our font styles
    var font_styles = font.CodepointResolver.StyleStatus.initFill(true);
    font_styles.set(.bold, config.@"font-style-bold" != .false);
    // …
    return .{
        .background_opacity = @max(0, @min(1, config.@"background-opacity")),
        .background_opacity_cells = config.@"background-opacity-cells",
        .font_thicken = config.@"font-thicken",

In Rustty, the renderer defines a trait with one accessor per config field, and rustty-config implements it for its Config. The body of init stays line-for-line comparable with the Zig (crates/rustty-renderer/src/config.rs and generic.rs at 58aa62a81):

pub trait RendererConfig {
    fn font_thicken(&self) -> bool;
    fn font_thicken_strength(&self) -> u8;
    fn background_opacity(&self) -> f64; // init clamps @max(0,@min(1,x))
    // …
    fn font_style_bold(&self) -> bool; // config.@"font-style-bold" != .false
    // …
}

pub fn init<C: RendererConfig>(
    alloc_gpa: Global,
    config: &C,
) -> Result<DerivedConfig, DerivedConfigError> {
    // …
    let mut font_styles = StyleStatus::init_fill(true);
    font_styles.set(Style::Bold, config.font_style_bold());
    // …
    Ok(DerivedConfig {
        background_opacity: config.background_opacity().clamp(0.0, 1.0),
        background_opacity_cells: config.background_opacity_cells(),
        font_thicken: config.font_thicken(),

On day 1, 29 crates were scaffolded from the plan, in leaves-first order. Porting followed that order only loosely. The terminal engine sits in the middle of the graph but went first, because everything above it needed it. Ghostty's own cycle kept growing during the port, to 403 files at the current reference commit, and the crate graph stayed acyclic through every reference move. Today the workspace has 61 packages and no cycle, and its longest dependency chain is 18 hops.

The terminal engine went first, and fast. Between 21 and 25 June, rustty-vt grew from 6,996 to 135,431 lines, and from 113 to 2,032 tests. By 28 June the workspace had 3,005 tests, close to the size of the whole contract.

The upper tiers came next: config, font, terminal I/O, core, the embedded app runtime and the renderer. They ran into a problem the engine did not have. Ghostty's Surface.zig and App.zig call straight into subsystems that were not ported yet: the GPU renderer, the event loop and the inspector. Instead of waiting, the port gave each missing subsystem a real placeholder type whose methods panic with unimplemented!(). The code that calls those subsystems was ported in full, compiled and reviewed as real Rust. When a subsystem landed, the placeholder gave way to the real port. A dated audit lists every unimplemented!() that remains in the code, with its reason.

Each milestone ran as a Claude Code Workflow script. The usual shape was design, adversarial review of the design, port, then verify, with Miri in the verify step of most scripts. 155 of these scripts were written before 10 July. The human side was small and mostly about getting out of the way. In the 18 days from 22 June to 9 July I sent 116 prompts, and 418 commits landed, 3.6 per prompt. About a fifth of the typed ones began with "continue", "resume" or "retry", often after a usage limit. The first limit came on day 2: "The workflow stopped due to API throttling, please resume it". Others pushed the agents to decide for themselves:

06-25 · "Next time, after detailed tradeoff review, make a recommendation and just continue autonomously (no need to block on me)"

07-08 · "keep going, your call- stop stopping to ask me, youre supposed to progress autonomously."

On 8 July the plan settled on macOS first, with Ghostty's Swift app reused on top of a Rust C ABI. Metal drew its first pixels on day 19. On 12 July the Swift app was imported unchanged. Twenty minutes later, a commit recorded a runnable Rustty terminal on macOS: Ghostty's own app driving the Rust port, on day 22.

The widget shows every hour of the port: commits as cells, my prompts as dots. The prompts themselves, word for word, are in Every prompt. The first three weeks are at the top. The pattern that holds across the whole port is visible early. Agents kept committing overnight and for hours after the last prompt. Up to 8 October, 52% of non-merge commits landed more than an hour after my last prompt, and the hands-on prompting added up to about 79 hours.

By 9 July the history was still linear, with 452 commits and no merges. The method was about to change. Two days before the macOS app first ran, the port adopted new rules and a new kind of audit, and the next section explains why.

On 10 July, day 20 of the port, I paused the porting and asked for an audit of what had been built. Two days earlier, Jarred Sumner had published "Rewriting Bun in Rust", an account of Bun's own port from Zig to Rust. My prompt asked agents to read it, follow its links into the Bun repository and its deleted porting guide, and see what applied to Rustty. It also admitted something:

02:43 · "…note that I haven't validated my port at all […] and possibly catch bugs I haven't uncovered yet."

Three ideas in that write-up shaped what came next: a field-by-field ledger of who owns each pointer, written before pointer-heavy code is ported; a committed count of every unsafe site; and a list of the regression classes that had escaped Bun's tests. Rustty built its own version of each. A research workflow tagged each idea against the rules already in place, as adopt, adapt, already covered or reject. That afternoon six new rules were ratified. They covered explicit semantics for each Zig builtin replaced by a Rust primitive, compile-time work that stays compile-time, unsafe accounting, greppable porting markers, separate implementer and reviewer agents, and a verdict for every upstream commit.

The ledger came first. It has one row per pointer-typed field in Ghostty's pointer-heavy code: the file, struct and field, the Zig type, an ownership class (owned, shared, a borrowed field or parameter, an intrusive link, an FFI handle and so on), the Rust type an agent must use, and the evidence for the call. Its header tells agents how to use it:

Port agents consume this table VERBATIM: "trust it over local guessing". […] UNKNOWN => Option<NonNull<T>> + TODO(port).

It was filled retroactively for the 216 fields already ported, and from then on it applied in advance, under a new rule: "no pointer-heavy tier ports without its GHOSTTY_LIFETIMES.tsv rows landing first (2-reviewer consensus)." An audit of the existing code against it found 20 issues the same evening. The two medium-severity findings were latent aliasing undefined behaviour in the event loop's lock-free completion queue, in a branch no test reached yet. The fix two days later needed the queue in its own heap allocation. A one-line fix was not enough, and a small Miri model of the queue showed it.

The unsafe census made one committed search command the ground truth for the count. Next to it, a separate ledger tracks safe functions whose soundness rests on invariants the compiler does not check, which no grep for unsafe finds. The rule behind both sets a bar for calling such a function fixed:

"Fixed" bar: safe code cannot cause UB in a release build; debug assertions do not qualify; wrappers that hide the invariant do not qualify.

On 12 July, 8 regression detectors went into the check registry. Each one targets one class: byte slices reinterpreted as wider types, fixed buffers driven to capacity, constants folded into literals, compile-time work that drifted to run time (checked with golden bytes for every escape sequence the terminal emits), invariants that two crates must agree on, a sanitizer canary that must fail, unexplained copies, and comments that no longer describe the Rust behaviour. They entered as progress checks, with self-tests.

The timeline puts these changes among the others, each at the commit that introduced it. The era bands make one point plainly. Over the two months after the realignment the commit rate fell only slightly, from 23.8 to 20.0 a day; what changed was what a commit had to show. The third band starts with the never-port-a-bug rule on 11 September, and that rule's section returns to it.

The first payoff came the night after the realignment, on 11 July. A Miri run over all 2,037 terminal-engine tests, the first full one, found undefined behaviour in 9 search tests, and it was fixed about 7 hours later. The ledger had no rows for the search code, so it could not have caught this one. Miri did. By 10 October the ledger had grown from 216 rows to 314, and the check registry from 12 entries on the day of the realignment to 105.

Most of the memory-safety bugs the port introduced share one cause. Zig and Rust disagree about what a pointer promises.

In Zig, *T and []T are addresses. Two of them may point at the same memory, one may write while the other reads, and nothing in the language tracks which one came first. Rust references make promises the compiler relies on: a &mut T is the only live way to reach that T, and nothing writes through a &T while it is live. Breaking a promise is undefined behaviour by definition, even when the program seems to work, and that definition is what lets the optimizer assume the promise holds. Miri checks executions against two formal models of these rules. Stacked Borrows keeps a stack of tags for each memory location, one per reference or raw pointer derived from it. Writing through a tag pops every tag above it; reading through it pops only the unique tags (from &mut) above it. Using a tag that has been popped is undefined behaviour. Tree Borrows, the newer model, arranges tags in a tree whose nodes change state (reserved, active, frozen, disabled), and it accepts some patterns that Stacked Borrows rejects. The port checks every pure-Rust crate under Stacked Borrows and the pointer-heavy code under Tree Borrows as well.

The rule that trips up a direct translation is the protector. A reference passed as a function argument is protected for the whole call. Any access during the call that would pop or disable its tag is undefined behaviour on the spot, even if the function never uses the reference again. Ghostty's Zig often passes *Page, *Row or []Cell into a function that re-reads the same memory another way, for example an integrity assertion that walks the page list. Miri first caught this on 24 June in Screen::clear_cells. The agent's note from the fix states the asymmetry: "the Zig reference passes *Page / *Row / []Cell — Zig pointers/slices are UNPROTECTED — so it's sound there. The Rust &mut is a Rust-only over-constraint." The fix made those arguments raw pointers, with a short-lived &mut taken only for each mutation and dropped before any re-read. That became the rule. Today 135 public functions take raw-pointer arguments and carry a lint allowance that cites the Zig signature. They are safe functions whose soundness rests on callers passing valid pointers, which is exactly the class the ledger of unsound safe wrappers tracks. The first tab of the lens below shows the clear_cells pair.

The protector also applies to memory that is freed rather than read. Ghostty's startHyperlink passes its slices to startHyperlinkOnce, which explicitly allows them to point into the hyperlink it is about to replace (src/terminal/Screen.zig at a60e9e2a5):

fn startHyperlinkOnce(
    self: *Screen,
    source: hyperlink.Hyperlink,
) (Allocator.Error || Page.InsertHyperlinkError)!void {
    // Allocate our new Hyperlink entry in non-page memory. This
    // lets us quickly get access to URI, ID.
    const link = try self.alloc.create(hyperlink.Hyperlink);
    errdefer self.alloc.destroy(link);
    link.* = try source.dupe(self.alloc);
    errdefer link.deinit(self.alloc);

    // End any prior hyperlink only after duplicating the new value. The
    // source slices are allowed to reference our current hyperlink.
    self.endHyperlink();

The contract holds in Zig because a slice carries no promise. A Rust &[u8] argument does: dropping the allocation it points into, while the call is still running, is undefined behaviour even though the slice is never read again. A Miri sweep found this on 30 July. The port now keeps a safe entry point for callers that cannot alias, and an unsafe one with raw slice pointers that carries Zig's contract (crates/rustty-vt/src/screen/attrs.rs at 58aa62a81):

pub fn start_hyperlink(
    &mut self,
    uri: &[u8],
    id_: Option<&[u8]>,
) -> Result<(), pagelist::grow::IncreaseCapacityError> {
    // SAFETY: `uri`/`id_` are live readable slices for the whole call, and
    // per this function's documented restriction they do not alias the
    // current hyperlink state.
    unsafe { self.start_hyperlink_raw(uri as *const [u8], id_.map(|id| id as *const [u8])) }
}
// …
pub unsafe fn start_hyperlink_raw(
    &mut self,
    uri: *const [u8],
    id_: Option<*const [u8]>,
) -> Result<(), pagelist::grow::IncreaseCapacityError> {

A second difference is provenance: a Rust pointer may only access the memory it was derived from. Under Stacked Borrows, a pointer made from a reference to one field may access only that field. Tree Borrows is more permissive here, but the port must pass both. Ghostty's C API writes a style's eight boolean flags with one 8-byte store that starts at the first flag (src/terminal/c/style.zig at a60e9e2a5):

pub fn write(s: style.Style, out: *Style) void {
    // …
    // We have to align(1) because we're ptrCasting a u8 pointer.
    @as(*align(1) u64, @ptrCast(&out.bold)).* = bytes: {
        // …
        break :bytes @bitCast(bytes);
    };

Ported as &mut out.bold cast to *mut u64, under Stacked Borrows, the store reaches seven bytes outside its provenance. The fix on 27 September derives the pointer from the whole struct and adds the field offset (crates/rustty-vt-c/src/style.rs at 58aa62a81):

// SAFETY: the eight bool fields are consecutive starting at `bold`
// (const-asserted below) with unique 0/1 representations, so the
// unaligned 8-byte store writes exactly those fields. The pointer is
// derived from the whole `Style`, not from `&mut out.bold`: a
// one-byte field reference carries provenance for that byte only,
// and an 8-byte store through it is out of bounds (Stacked Borrows; […]).
unsafe {
    let base = out as *mut Style as *mut u8;
    (base.add(core::mem::offset_of!(Style, bold)) as *mut u64).write_unaligned(bytes)
};

The same arithmetic, run backwards, ports Zig's @fieldParentPtr (C's container_of): subtract the field's offset_of! from a raw pointer to the field to recover its parent. That is sound only when the field pointer carries the parent's provenance, for example one derived from the handle Box::into_raw returned, not from &mut parent.field. Intrusive lists use a per-type trait that returns the address of the link field, so the code never forms a &mut to an element that another pointer still references. The lens's second tab shows both.

The hardest cases are long-lived aliases. In the renderer's row loop, a run iterator holds a raw pointer to the font shaper inside the renderer for the whole loop, and the loop calls the shaper as it goes (src/renderer/generic.zig at a60e9e2a5):

var run_iter = self.font_shaper.runIterator(run_iter_opts);
var shaper_run: ?font.shape.TextRun = try run_iter.next(self.alloc);
// …
        // Otherwise we have to shape them.
        const new_cells = try self.font_shaper.shape(run);

In Rust, self.font_shaper.shape(run) creates a new reference to the shaper beside the iterator's pointer, a sibling. Under both models that pops or disables the iterator's tag, so its next step is undefined behaviour. The design reviewer flagged the hazard and proposed taking the whole renderer as a raw pointer. A Miri model showed that this was necessary but not sufficient: alone, it was still undefined behaviour under both models. The clean structure needed both halves. The shaper is called through the iterator's own pointer, a child of its tag, and the helpers called inside the loop take the renderer as a raw pointer (self_raw below) with narrow field access, instead of a whole &mut self (the fix; crates/rustty-renderer/src/generic/macos_impl/cells.rs at 58aa62a81):

let self_raw: *mut Renderer = self;
let mut run_iter = self.font_shaper.run_iterator(run_iter_opts);
let mut shaper_run: Option<shape::TextRun> = run_iter.next(self.alloc)?;
// …
            // Otherwise we have to shape them.
            // SAFETY ([…]): shape THROUGH the
            // hook's own raw `*mut Shaper` (`run_iter.hooks.
            // shaper`), a child reborrow that does NOT pop the
            // hook — a `self.font_shaper.shape(...)` sibling
            // reborrow WOULD pop it (Miri-proven UB). Same Shaper
            // object, byte-identical to the reference `self.
            // font_shaper.shape(run)`.
            let new_cells = unsafe { (*run_iter.hooks.shaper).shape(run) }?;

That case set the method. Much of the pointer-heavy code calls Metal, CoreText or C libraries that Miri cannot execute, so its tests cannot run under Miri. Instead, each aliasing question gets an isolated proof harness: a small crate with no FFI that reproduces the exact borrow shape, with candidate designs run under both models. The design that came out of the shaper fix says it directly: "do NOT hand-reason SB" (Stacked Borrows); test it under Miri instead. The repository now holds 33 of these harnesses. The next widget replays four of the port's bugs through the implementer, the reviewer, Miri's borrow stack and the fix.

The record is a floor, because port bugs before September were tracked only in commit messages. It still shows the shape. The port introduced at least 83 memory-safety defects in 39 events, and Miri caught 64 of them, directly, through a harness or by proving an audit's finding. 62 were aliasing or provenance undefined behaviour, a class of bug that exists because Rust has an aliasing model and Zig does not. The sanitizers found 7, and none of those was aliasing. In October the Tree Borrows lane found two more bugs, both in tests: page tests passed &mut temporaries where the code takes raw row pointers, and a debug-only integrity read then froze the borrow before the next write, a sequence Stacked Borrows accepts. The tests now pass raw pointers, as Ghostty's do.

The kickoff rule put parity first and performance second, so the first head-to-head waited until 15 July. Rustty won none of the benchmarks against Ghostty's release build (0/14), and the suite was 42.0% slower. That night I asked for a worktree for the performance work and left:

00:47 · "Go autonomous from now, I won't be around to approve anything"

Between 01:18 and 10:41 on 16 July, agents landed 29 performance commits. At the end, Rustty won 14/14, with the suite −21.7%, the terminal parser 2.85× faster and screen cloning 2.42× faster. The replay steps through the night one measured build at a time.

These numbers hold only because of how they were measured:

• The same benchmark on both sides. rustty-bench is a one-to-one port of Ghostty's benchmark CLI, and both read byte-identical input corpora. The Rust synthetic-data generator produces the same bytes as Ghostty's for the same seed.
• Comparable builds. Ghostty's benchmark is built with -Doptimize=ReleaseFast. A build without that flag once gave misleading numbers. Rust uses a release-fast profile that differs from the shipped release profile in one way only: overflow checks are off, as in ReleaseFast. The shipped build keeps them on, to trap where Zig's ReleaseSafe traps.
• Same-session Zig. Each figure is the median of seven (later nine) timed runs after one discarded warm-up, run one at a time, and Ghostty is re-measured in the same session as every Rust build. Across four sessions, the same unchanged Zig binary measured the terminal parser 11.8% apart. Session matters for Rust too: the same pre-fix Rust code measured +42.0% on the suite in the 15 July session and +14.9% in the 16 July session. So the starting gap overstates what the night's code changes closed. Part of it was the session.
• Per-operation slopes, not wall clock. Every wall-clock figure includes process start-up. In August, an agent found that Rustty's process floor was about 3 ms lower than Ghostty's. On a benchmark that runs for a few milliseconds, that difference decides the result: the hyperlink lookup "won" by 15% on wall clock while running 7.5× slower per operation. Since then, short benchmarks run at several loop counts N, and the slope (t(N) − t(1)) / (N − 1) gives nanoseconds per operation.

Two results from that night shaped the rest of the code. Link-time optimisation helped the OSC parser and screen cloning by about 16% but slowed the terminal parser (322 → 531 ms), so it was reverted and banned in a comment above the profile in Cargo.toml. Without it, every hot public function called across crates needs #[inline], which Zig, compiling everything as one unit, never needed. And instruction-level profiling of screen cloning found a parity bug rather than a speed-up. Ghostty's break :hyperlink leaves only a labelled block, so the style handling after it still runs for that cell. The port had used continue, which skipped it, so a cell with both a hyperlink and a style lost its style on a same-page clone. The translation compiled and passed every existing test.

The August round widened the matrix to newer benchmarks, measured against Ghostty's main branch, and found the main source of performance gaps: Zig compile-time parameters and constants that the port had turned into runtime values. A compile-time width parameter that became a runtime enum, for example, turned a fixed-size store into a memcpy call per cell. Fixing those took snapshot encoding from +295% to +16% relative to Zig and left Rustty faster on 23 of 33 configurations. In the same round, swapping hot assert! calls for debug_assert! made the code slower. In a release build assert! still checks its condition, and the optimizer can use that condition afterwards; debug_assert! removes both the check and that knowledge. Some of those asserts were what removed later bounds checks.

On 7 October, at 12752b2ac, two reference commits before the current one, and on an idle machine, Rustty won 14/14 again in two independent runs, with the suite −27.9%. The workloads had changed with the reference, so those ratios are not comparable with July's. At the current reference commit, 246f70287, the suite ran again on 10 October with the same harness, and Rustty won 14/14 with the suite −27.4%. The terminal parser ran in 23% of Ghostty's time and the OSC parser in 30%. The closest benchmark, terminal-stream, lost its first nine-run round by 1.3% and won the harness's built-in eighteen-run re-run by 2.1%; an independent run of the performance check gave a suite −27.7%.

Ghostty kept moving during the port. Between the first reference commit and the current one, upstream landed 1,169 non-merge commits (+185,622 / −33,862 lines, summed over the moves), and Ghostty's Zig code grew by +34.0%. The port moved its reference 8 times to keep up. One rule governs every move:

updating the reference checkout does not port anything — "a merge does NOT port the fix; only an explicit .rs change does".

The first move ported the upstream range first and moved the reference at the end. 47.6 hours passed between the new reference commit landing upstream and the port adopting it. From the second move on 17 August, at my direction, the order was reversed. The port moves the reference first, runs every check against it, records which checks went red, and then ports until they are green again. The red counts became the progress meter. At the second move, 1,230 reference comments had no Rust counterpart and 36 Zig tests had none. At the third, the counts were 1,536 comments and 295 tests, 202 of them in the kitty module, for new clipboard, drag-and-drop and graphics-animation features. From then on, each catch-up ended when the counts were back at zero.

The wait to adopt a new reference commit dropped to as little as 1.7 hours at the third move. It was not a steady decline: the last move waited 7.7 hours, and the median was 7.55 hours. Catch-ups also got shorter, but not steadily. The second took 7.6 days from move to finish, the seventh 9.7 hours and the eighth 74 minutes, though part of the eighth's porting merged just before its move.

The matrix shows where the work landed. 43% of the upstream churn was in the terminal engine. One move also exposed a weakness in the checks themselves. At the fifth move, on 1 September, the per-module test-count check stayed green, but only because two new upstream files were outside the list it read. 23 new Zig tests were invisible to it. The next section is about that kind of green.

The seventh move, on 7 October, arrived with 411 reference comments and 73 Zig test blocks missing. The catch-up closed 9.7 hours later with both counts back at zero. Ghostty moved again while that catch-up was being verified: the eighth move, on 9 October, brought 12 upstream non-merge commits, among them a soft terminal reset, and arrived with 19 reference comments and 8 Zig test blocks missing. The comment, test and symbol checks were green again 74 minutes after the move, and porting that range recorded one more Ghostty defect, an origin-mode cursor outside the margins that the terminal formatter replays at the wrong position.

The check registry is where "parity" is written down precisely enough to fail. It had 11 entries on the first day and has 105 today. 79 of them must pass. The other 26 track progress toward a target while the code they measure is unfinished, and they start failing once a crate claims to be done. Every check also has to prove it can fail. 27 registry entries are self-tests that inject a violation into a check and require it to go red, and 58 of 93 check scripts carry a self-test of their own.

The hardest lesson was about checks that pass without checking anything. On 30 July, the check that guarded the close of the main porting phase was green, and had been for days. It took its list of open work from the roadmap, a hand-maintained checklist. Ticking off three finished workstreams turned it red. Its green had depended on rows staying nominally open. Two faults pointed in opposite directions. Four roadmap rows contradicted commits that were already merged, and a struck-through row still counted as open, so work it owned passed on the strength of a retracted line. The note the agents wrote down afterwards states the lesson: "a green result proves nothing until you check what the green rests on". Since then, a check that derives its verdict from a document asserts that its derived sets do not overlap, and its self-test breaks each requirement on the real rows and demands a rejection. It also fails loudly when no row exercises a requirement, and it prints every accepted exception on every green run.

The same failure came back in other forms. One was the test-count check that missed new upstream files. Another was the silent skip. A test that cannot find a resource it needs, such as a font or a display, and returns early reports ok. On 23 September a new check found 185 such sites. The rule written that day:

A Rust test that returns early reports ok, which cannot be told apart from a pass.

Now a test that cannot always run is either compiled out by cfg, marked ignored, or calls a helper that turns its skip into a failure on lanes that have the resource. When last counted, at 1d22ba80d, 6,325 of 7,270 tests had no skip mechanism at all.

One check exists because of a crash. On 15 July, every dynamically populated macOS menu shortcut was blank. The cause was a struct returned by value across the C interface. TriggerC embedded a modifier type without a C layout, which made it 20 bytes in Rust against 12 in the header. On arm64, a returned struct larger than 16 bytes travels through a hidden pointer, and a smaller one comes back in registers. So Swift and Rust used different calling conventions for the same function. The fix commit records a SIGBUS on the first call, and the blank shortcuts in the app. A lint allowance had hidden the compiler's warning. The check added that day compiles a probe with clang and requires every type returned by value through the embedding header to carry a Rust size assertion that matches it.

The checks that define parity go past counts where they can:

• Comments. A first check compared comment line counts per crate, and a dropped comment slipped past it. Its replacement matches content: every distinctive Ghostty comment, a phrase of five words or more, must have a fuzzy match in the port's comments after the rename. At the current reference commit, 34,371 comments match and none is missing. 79 are deliberately not carried, and each of those rows has to prove its reason mechanically.
• Tests. In each of the 211 mapped modules, the Rust test count is at or above Zig's.
• Escape sequences. A later check runs the esctest2 suite against both terminal libraries and requires the same outcome and log for every test: 567 tests, with identical results on both sides.
• The C interface. Rustty's terminal library matches Ghostty's on 35/35 headers, 208/208 functions and 79/79 enum sentinels that force C compilers to size enums as int. The embedding API maps 91/91 entry points.

All of these checks were green when the latest catch-up closed at the current reference commit, and in the full validation run that followed it.

Until 11 September, the port copied Ghostty's bugs. When a translation reached a crash in the reference, the agent ported the crash, marked it as deliberate fidelity and recorded it for a later upstream report (one example). The rule changed over one GTK file. That morning a parity task ported how Ghostty reads the reply of the desktop portal's global-shortcuts request. If the reply body has an unexpected shape, params_.get leaves vardict null while response stays 0 (src/apprt/gtk/class/global_shortcuts.zig at a60e9e2a5):

var response: u32 = 0;
var vardict: ?*glib.Variant = null;
defer if (vardict) |v| v.unref();
params_.get("(u@a{sv})", &response, &vardict);

switch (response) {
    0 => {
        log.debug("request successful", .{});
        method.onResponse(self_cb, vardict.?);
    },
    1 => log.debug("request was cancelled by user", .{}),
    2 => log.warn("request ended unexpectedly", .{}),
    else => log.warn("unrecognized response code={}", .{response}),
}

Unwrapping a null optional with .? panics in a safety-checked build and is undefined behaviour in ReleaseFast. The signal subscription has no sender filter, so any process on the session bus can send such a body. The port reproduced the panic on purpose, with a note saying so. Half an hour after that commit, I wrote:

10:43 · "Wait, that seems odd. We shouldn't port the crash, please don't. Fix it here, update the plan/rules accordingly, and document all issues like this so we can propose upstream fixes later. Do this for past work too…"

Four minutes later the rule was in the rules file, and a minute after that the panic was gone. A body without results now takes the reference's own "ended unexpectedly" branch (crates/rustty-apprt/src/gtk/class/global_shortcuts.rs at 58aa62a81):

let (response, vardict) = response_params(params);

// PORT NOTE: reference defect […]. A deliberate divergence […], not an oversight: a body that is
// not `(ua{sv})` leaves `response` 0 and `vardict` null, and the reference then
// runs `method.onResponse(self_cb, vardict.?)` — a panic in a safe build, undefined
// behaviour in ReleaseFast. It is reachable from ANY session-bus peer: this
// subscription, like the reference's (`:481-491`), has a null sender. […]
// code 0 without a vardict takes the `2` arm — the
// failed response it evidently is, with the reference's own "ended unexpectedly"
// warning — and `onResponse` is not called.
match (response, vardict) {
    (0, Some(vardict)) => {
        log::debug!(target: LOG_SCOPE, "request successful");
        self.on_response(method, &vardict);
    }
    // …
    (2, _) | (0, None) => log::warn!(target: LOG_SCOPE, "request ended unexpectedly"),

In plain words, the rule is this. A crash, undefined behaviour, leak or deadlock in Ghostty that real input can reach is not reproduced. The port implements what the reference evidently intends. A test proves the fix and must fail when the bug is put back. A port note marks the site, and the defect goes into a ledger with a proposed upstream fix. Assertions of real invariants still port as assertions. The rule also says how to decide:

When unsure, trace where the input comes from before deciding; "the reference also traps" is not by itself a reason to trap.

On 23 September the rule was extended to bugs that crash nothing but break the code's evident intent, such as output lost to a missing flush. Since then "the port implements the intended behaviour, not the bug", and every such difference also gets a line in a user-facing list of fixes.

The third band on the strategy timeline starts with this rule. From 11 September to 10 October, commits ran at 45.9 a day, about twice the earlier rate. The closing work of that period came as many small commits, one finding each, with its test first.

The ledger held 66 entries at the end of 11 September, most of them from a sweep of earlier work, so those dates record when an entry was written, not when the bug was found. It now holds 206: 173 in Ghostty and 33 in its dependencies, mostly libvaxis and libxev. 136 are live: 60 crashes, 19 cases of undefined behaviour, 14 leaks, 9 hangs or deadlocks, and 34 that break intent. The rest are latent (59, unreachable at the reference commit) or weaknesses in Ghostty's own tests (11).

A crash in a safety-checked build understates the problem, because Ghostty ships ReleaseFast, where those checks are compiled out. Each ledger entry states what happens in ReleaseFast. Read by hand, 37 of 60 crash entries become undefined behaviour there, 13 silently produce a wrong value, and 10 still terminate.

The ledger also shows how porting finds bugs. The method of discovery is a hand classification, so these counts are estimates:

• Reading and review found the most, 93, during parity audits, defect sweeps, translation and reviewer passes.
• Checked conversions found 30, and 29 of them are crashes. A Zig @intCast or an overflow on input-controlled data has to become try_from or checked arithmetic in Rust, and choosing between them forces someone to work out the range.
• Compiling code Zig never analyses found 17, none of them a crash. Zig type-checks lazily, so code that no build reaches can rot unnoticed. Rust compiles all of it.
• Bringing up other platforms found 25 (6 crashes), fault injection 12, porting Ghostty's tests 11 and the sanitizers 3.
• The rest: the type and borrow checker found 5, porting the build system 4 and live use of the port 4. The two crashes still to be reported privately were not classified by method.

Miri and fuzzing found none first. Zig has no aliasing model for Miri to check. Miri can only confirm a Rust model of an access pattern that was found some other way.

None of the defects has been reported upstream yet. Before any report, upstream had fixed 4 independently, three in Ghostty and one in Google Highway (not yet in Ghostty's pinned version), and partly fixed 5. That is independent evidence that the entries are real. Two crashes reachable from ordinary terminal output are to be reported privately, and one entry is obsolete upstream. The remaining 194 are unreported, each with a proposed fix ready to file, and 142 appear in the public list of fixes.

Every reviewer in the port so far was a Claude Code agent reviewing another Claude Code agent's work. At the end of July I wanted a review from a different vendor, so I ran Codex in the Codex app. Its instructions were to read both repositories, write only into one findings directory, change nothing, and check its own claims:

"I want you to report on things that you've actually verified. If you come up with a theory or flags, I want you to come up with a way to vet and verify it (do adverserial reviews of your own review comments)."

It ran twice, for about 43 hours between 31 July and 2 August (UTC). The first run began as an audit of non-macOS parity, split into workstreams, and returned 20 verified gaps. During it I widened the goal to every line of code, and the second run restarted with that goal. Codex listed 3,103,589 lines across both repositories and split the files into hash-pinned line ranges. It gave each range to a primary auditor and had a second agent independently replay every non-trivial result. Codex's goal loop kept itself going, with 203 automatic continuations against 10 messages from me. It spawned 667 workers, at most 6 at once. Its weekly usage meter went from 8% to 99% over the second run, and the audit stopped there. By then its strict ledger credited only 0.35% of the lines as mechanically verified, though the primary reviews had covered much more ground less formally. The output was a registry of 659 rows.

Eight days later, Claude Code agents took the registry as input. Rows that shared a root cause were folded into 147 groups. Each group went to its own read-only agent, which had to confirm or refute it against the current code without trusting the report's claims. Each fix batch then went to a fix agent followed by an independent verify agent. Everything landed in one commit: 532 files, 336 new proving tests and 4,660 tests passing.

Most of what Codex found was what a macOS-first plan had never exercised. Windows did not compile, with 25 errors cutting off the terminal engine, its C library and terminal I/O. FreeBSD selected a Linux-only GTK path and a macOS-only kqueue backend. Kitty graphics had never been rendered on Linux, and custom shaders were never applied. One finding paid off indirectly. It noted that the port had no coverage-guided fuzz target. The target added in response found a reachable panic: RGB::parse, called from the live OSC parser, sliced a Rust string at a byte that was not a character boundary, where Ghostty slices bytes and returns InvalidFormat. Parsing moved to &[u8].

The same separation of roles runs through the port's own work. The rule for it:

Split contexts: implementer, verifier, and fixer are separate agents; the verifier works a concrete violation checklist […] and defaults to not-ok-if-uncertain; the fixer makes surgical edits only and may skip a hallucinated finding with a note

Separately, the recovered transcripts hold 1,073 automated security-review sessions, most of them on Opus 4.7 at extra-high effort.

Precision is what matters in a second opinion. Of the 147 groups, 144 held up under independent checking and 3 were refuted. Claude agreed with Codex's severity on 144 of 147, and 140 were fixed and verified.

The tool for each kind of code was set early: Miri for pure-Rust crates, AddressSanitizer for crates that call into C, and Ghostty's own Valgrind job, reproduced. The lanes were added one by one. The first time every lane ran to completion was at 12752b2ac, two reference commits before the current one, between late September and 7 October.

On 1 October I questioned the cost of all this:

21:26 · "lets re-evaluate the value of these long running miri checks. do most rust projects even run with them?"

The design written that day kept Miri and changed how it runs. At the fifth reference move, the Miri lane had not finished in about 30 hours. Miri interprets the program, and libtest ran all of a crate's tests in one process. Running each test in its own process with nextest, several at a time, cut three groups of slow tests from 11,722 s to 1,687 s, 6.9× faster. At 12752b2ac, Stacked Borrows covered 38 crates in 13,354 s, and it covered the same crates again at the current reference commit. A second lane runs, with debug assertions off, the tests that are only practical under Miri that way, and at the current reference commit it passed 126 of 126. Tree Borrows covered the pointer-heavy code, and at the current reference commit also the 69 tests of the app core. The design also widened the sanitizer lanes around Miri. Each lane's latest complete run was at the current reference commit on macOS and for Valgrind, and at the previous one, a60e9e2a5, for the Linux sanitizers:

• AddressSanitizer: 10,077 tests on macOS.
• LeakSanitizer: 6,643 on macOS and 10,307 on the Linux VM.
• MemorySanitizer: 6,375, on the Linux VM only, since it has no macOS support.
• HWAddressSanitizer: 10,183, on the Linux VM only, since it needs aarch64 Linux.
• ThreadSanitizer: 3,900 on macOS and 4,536 on the Linux VM.
• Valgrind: 6,746 tests in 652 memcheck runs on Linux, with no errors in Rustty code once Mesa's EGL leaks were suppressed.

The matrix settles the question I asked. For the port's own bugs, unlike Ghostty's, Miri was the bug finder. Recorded per run, the Miri lanes found 41 port bugs: 18 under Stacked Borrows, 15 under Tree Borrows (all in test code) and 8 in the C API lane, against 10 for all sanitizer and test lanes combined. The sanitizers found what Miri cannot run: 3 defects on the upstream side, in C, C++ and FFI paths.

• Valgrind's first memcheck run found that Ghostty leaks a font collection when the shared glyph grid fails to initialize.
• LeakSanitizer's first macOS run found that Dear ImGui's Metal backend, built without automatic reference counting, leaks every frame.
• ThreadSanitizer found a data race in Google Highway. Two threads making their first SIMD call at the same time read and write its chosen-target mask without synchronization. The fix uses relaxed atomics in the vendored header.

At the previous reference commit, a60e9e2a5, every lane completed except Tree Borrows on the app core, which did not finish there. ThreadSanitizer on the Linux VM found a link regex compiled on a test thread before the Oniguruma library's one thread-safe initialisation, and the compile path now initialises first. At the current reference commit, 246f70287, the full check script ran on both hosts after the catch-up closed (merged in 58aa62a81). To fit a full run on one machine, the script had gained per-check timings, a parallel scheduler with a cap on heavy checks, sharded Valgrind and per-check build directories. On macOS, 98 checks were green, among them Miri under both borrow models; the sanitizers and one latency test first failed on two test-only problems, a full disk or machine load, and passed once fixed or re-run, and the others needed tools the Mac does not have. On the Linux VM, 94 checks were green, among them a complete Valgrind run. In a separate run at 58aa62a81, the full Windows workspace suite passed 6,418 tests with none failing. The Linux sanitizer lanes produced no result in that run, so the matrix shows them at a60e9e2a5 until their re-run at the current commit. Taking each lane at its latest complete run, the lanes of the first complete matrix add up to 58,767 test executions under a sanitizer or Valgrind, against 61,403 at 12752b2ac.

For the first two months, the port ran on Workflow scripts. Each one was a JavaScript file that fanned a milestone out to agents in a fixed shape: design, adversarial review of the design, port, verify. 211 were committed, the last on 25 August.

September changed the unit of work. A controlling session now wrote a plan and dispatched one subagent per task, each in its own git worktree. A separate reviewer subagent checked each branch before the controller merged it, one at a time. In September, 1,142 subagents worked across 214 worktrees, and subagents made 88.6% of the model calls. The longest unattended run was 180 commits, overnight from 23 to 24 September.

Three things changed with it:

• Disk became a limit. Each worktree builds its own target directory. On 23 September, about seven building worktrees filled the Mac's disk, and every tool call stalled. Since then, no more than three worktrees build at once, and each worktree and branch is deleted right after its merge.
• Context per call grew. The median went from 77k to 204k tokens. A controller holding a whole plan, and subagents reading the reference beside the port, both need more context.
• Models changed with usage allotments. The trailers of the 2,789 non-merge commits on the main line name the model. Opus 4.8 wrote 740 commits in the first five weeks. Opus 5 wrote 615 from late July, and Opus 5.5 1,046 from 23 September. Fable 5 (124), Sonnet 5.5 (57) and Haiku 5.5 (2) filled gaps, 7 commits name both Opus 4.8 and Fable 5, and 198 carry no trailer. Switches often followed a usage allotment running out, as on 10 August: "My Fable usage is about to expire, when it does, continue your work with Opus 5".

Up to 14:00 Pacific on 8 October, my prompts to Claude Code, on the Mac and the Linux VM, numbered 898 on 62 days, not counting the 13 founding prompts or the prompts I typed in the website folders. The change shows in commits per prompt. From 10 July to 31 August, there were 1.7 commits per prompt. From 1 September to 8 October, there were 5.8.

The prompts came in 97 sessions, each one Claude Code or Codex conversation on one machine. 43 of them hold only commands, such as switching the model or clearing the context. The rest are grouped by the part of the work they did, from the terminal engine to this article, under a title that is Claude Code's own, or one written by Claude where Claude Code kept none or I changed it. Sessions often ran side by side: on 31 July, the busiest day, 7 sessions had an instruction or a decision from me, most of them checking the port. Some sessions were resumed again and again; the longest held 168 prompts and spanned 14 days. The founding sessions, 3 of them, hold 13 prompts typed outside the repository. On the night of 20 June, before the repository existed, I weighed a port of Ghostty from Zig to Rust, planned it and named it in one session, and changed a setting in another, in the folder that preceded the repository; on 23 June came a short session in the Ghostty checkout.

The log below holds every prompt I sent to the port from 20 June to 11 October, 1,066 in all, from three sources: the prompt history of Claude Code on the Mac (879) and on the Linux VM (165), and the session logs of the Codex app (22). The founding prompts are part of it. Left out are the prompts I typed while building this website, the prompts that agents wrote for their subagents, and the automated Codex review sessions. Of the prompts, 847 are instructions and 43 only answer a choice or acknowledge; the other 176 are Claude Code commands and shell escapes, kept in the log but hidden until you show them. The text is verbatim, typos included. The internal labels in it, such as task and check names, keep their spelling, and hovering or focusing one explains it. The 60 prompts of the October sessions about this article are tagged as article work. The other prompt figures in this article stop at 14:00 Pacific on 8 October. This section runs to 11 October, when I extracted the prompts, so it also counts the 133 prompts typed after that cutoff, 83 of them port work.

Part of the record is gone. Model, effort and mode are unknown for 463 prompts, most of them typed on the Mac before 8 September, whose transcripts Claude Code deleted. For 96 more, the model shown comes from the Co-Authored-By trailer of a commit linked to the prompt, and is marked as inferred. Pasted text is not published; for 10 prompts it no longer exists. I made 23 redactions, for secrets, logins, email and IP addresses, my username and the name of an unrelated project. Each one reads [redacted: reason], and nothing else in the text was changed.

The port was paid for by subscription, not per token. Claude Max at the 20x tier covered the whole port. ChatGPT Pro covered one month, 18 July to 18 August, which included the Codex audit, and ChatGPT Plus the other months. The outlay attributable to Rustty, up to 8 October, is about $420:

• Claude: $361, the plan's $200 a month over the port's 3.61 months, with half counted toward Rustty because the subscription was shared with other projects.
• Codex: $61. Rustty was 30.5% of that Pro month's Codex usage. Rustty's Codex use on Plus was negligible.

Counting whole billing cycles instead of prorating, or Codex at half, gives a range of ~$420–$600. Any extra-usage credits come on top; their amount is unknown.

What the same tokens would cost at API list prices is a reference value, not money spent. Measuring it has a gap. Claude Code deletes local transcripts after about 30 days, so the Mac Claude telemetry before 8 September is gone. The recovered usage comes to $11,032 at list price, from the Mac and Linux VM Claude transcripts and the complete Codex logs. For the lost window, Mac Claude from 21 June to 7 September, the estimate assumes a maxed-out subscription in every week with Rustty activity, with 50% of it counted toward Rustty. Prompt history from those weeks shows limits being hit throughout. 7 of 15 quiet stretches in the commit history are bracketed by prompts about limits, such as "can we pause here, as I am approaching my token limit." (26 June).

The size of a maxed-out week comes from recovered weeks that ended at the weekly limit: $1,974–$4,262 at list price across all projects, $2,769 as the central value. In the recovered weeks, Rustty's measured share was 53.9%, which supports counting half. The lost window comes to ~$12.8k ($8.7k–$20.3k). The total reference value is ~$23.8k ($19.8k–$31.4k), about 56× what was paid.

The flat price came with a pace. The weekly limit reset every Tuesday afternoon, and the port ran to it. Of the 22 pauses in the commit history of twelve hours or more, 7 ended within five hours of a reset. Between June and August, agents made about 3 commits per running hour in the first three days after a reset and about 1.2 in the rest of the week, and the port ran fewer hours a day as the week went on. The analysis builds the estimate from the hours the port was actually running: about 46 days (41–51 days) instead of 112 days. The estimate keeps every piece of work and every hour I spent reading and answering the agents, and removes the stretches the usage limits left idle, counting the eleven days I split between a limit and other work as half chosen.

The token mix shows where that figure comes from. Cache reads were 96.5% of tokens but 55% of the list-price cost, because every call re-reads its context from the cache. Subagents and workflow runs accounted for 75.6% of the recovered usage at list price. In the recovered window from 8 September to 8 October, a commit came to $5.67 at list price. On the Codex side, one percentage point of the weekly meter corresponded to about $22 of list-price usage.

Early in July I asked the obvious question:

22:28 · "/btw Does the heavy use of unsafe defeat the purpose of Rust, in the port? Or not necessarily"

The answer starts with a count. The port's census is one committed command (.port/audits/count-unsafe.sh):

rg --no-config -n --column -o \
   'unsafe \{|unsafe fn|unsafe extern|unsafe impl|unsafe trait' \
   --glob '*.rs' --glob '!**/vendor/**' --glob '!**/cbits/**' \
   crates crates-sys xtask

It counts 22,240 sites in 838,127 physical lines of tracked Rust. Physical lines here means every line of every tracked .rs file outside vendored code, comments and blank lines included, not the code lines tokei counts. That gives 26.54 sites per 1,000 physical lines. Per code line the density would be higher. The figure has barely moved since 10 July, while the code grew 2.03×. It was 27.02 on 10 July (11,145 sites), peaked at 28.15 on 25 August and read 27.87 at a second census later that day.

Where the sites sit matters more than the total:

• Tests. By a heuristic count, about 58% of all sites are in test code. With a stricter rule for what counts as a test file, it is 52%. In the terminal engine, 6,185 sites are in tests against 1,714 outside them. Ghostty's tests manipulate pages, rows and cells through pointers, and the ported tests keep that shape.
• FFI. Per 1,000 physical lines of each crate, the inspector has 88.1, and 1,147 of 1,155 of its sites are outside tests, because it calls Dear ImGui through C. The terminal library's C API has 82.2.
• The rest. The terminal engine has 29.9 and the app runtime crate 9.6. The port of the z2d graphics library has none.

A count does not show soundness. The earlier sections cover the parts that do: the bar for calling a soundness bug fixed, the ledger of safe functions that rest on unchecked invariants, and the Miri lanes. The count shows where to look. At head, that is 26.54 sites per 1,000 physical lines, most of them in tests and at C boundaries.

The parity work closed with one difference still open: about 35 log sites print values in Rust's derived Debug format, where Zig prints its own format. Only log text differs, and the severity is low.

Each platform has a one-line claim, worded to match the evidence:

• macOS: "The main platform: it builds, runs, and carries all the Miri evidence and most of the sanitizer evidence."
• Linux (GTK): "The GTK app is ported and works in a Linux VM under Wayland and X11, tested by hand and by live-window tests; never run on a real GPU or on x86_64 Linux."
• Windows: "It builds, lints and passes the full workspace test suite on Windows; like Ghostty at this reference commit, there is no Windows app."
• FreeBSD: "Built, tested and run natively on FreeBSD in an arm64 VM: the GTK app runs under X11 and Wayland, tested by hand and by live-window tests; three DMA-BUF tests need a GPU driver the VM lacks, and it was never run on amd64." This claim is as of 110adad44, after the snapshot. On FreeBSD 15.1 the first workspace test run gave 6,665 passed and 23 failed; each failure was fixed or explained, and its test binary was run again and passed. The GTK runtime's tests give 163 passed and none failed, and 15 of the 18 live-window tests pass. The other three need DMA-BUF export, which FreeBSD's Mesa provides only with a GPU driver, and arm64 FreeBSD has none for the VM's virtual GPU. The run found bugs in the port: the app crashed at its first window, because the system's text layout library (Pango) mixed Rustty's bundled HarfBuzz with the system's newer one, and the event loop's thread pool could hang at shutdown. It also found that Ghostty's own terminal test expects the terminal's device name on FreeBSD, which Ghostty's code does not report there; Rustty reports it, as on Linux. The fixes that also touch Linux passed again in the Linux VM. I used the app by hand on that VM, typing, colours, CJK text, emoji, resizing and tabs, as the run record states; its setup and logs are committed with it. No sanitizer has run on FreeBSD.
• WebAssembly: "The terminal core and the font demo compile to WebAssembly and run in a browser, in Node and under wasmtime, where the event loop's WASI backend passes its tests; three example pages give the same output as Ghostty's. There is no web terminal app, and Ghostty has none either." This claim is as of 3a59e7edc, after the snapshot. Under wasmtime the event loop's tests give 34 passed and 2 ignored, because WASI has no threads. In headless Chrome, three of Ghostty's example pages and their Rustty copies, given the same inputs, match in all 139 compared outputs. The same check found that Ghostty's SGR example page has one entry too many in its table of attribute numbers, so it shows most attributes as a neighbour; Rustty's page uses the library's values. I also ran all five example pages by hand in Chrome on 10 October, at that commit; that run is my own statement, with no run record in the repository.

The Linux claim deserves its history. The GTK app was written on two aarch64 Linux VMs by Claude Code sessions running there: 77 commits on the first and about 75 on the second, between 16 and 23 July. A live terminal appeared in a GTK window on 18 July. I then used it next to Ghostty on GNOME under Wayland, in an Xfce session under X11 and in sway, and found real bugs. Typing was swallowed. It crashed after a right-click. Menus showed no shortcuts. The window title format differed, and clear failed on an unknown terminal type. The title bar was striped. After the quick-terminal check in sway, against Ghostty run first as the baseline, my verdict was "Is works exactly as Ghostty to me". All of it ran on software OpenGL. The x86_64 Linux CI jobs are written but have no recorded run.

What is still missing:

• Current-commit verification. The Linux sanitizer lanes (AddressSanitizer, LeakSanitizer, MemorySanitizer, HWAddressSanitizer and ThreadSanitizer) and the Linux run of the byte-for-byte differential check against Ghostty, with its test drivers built, have not yet run at the current reference commit; the sanitizers' latest results are from the previous one.
• Windows. The full workspace test suite passes, with three C libraries excluded, but there is no Windows app, as in Ghostty.
• The z2d port. It is a subset, from 19,812 Zig code lines to 9,907 Rust, and it tracks z2d 0.10.0 while Ghostty's reference commit uses 0.12.1.
• End-user performance. Every performance figure here is a library micro-benchmark. Startup time, input latency, frame rate and app memory were not measured.
• Upstream reports. None of the 206 ledger entries has been filed with Ghostty or its dependencies yet.

Every number in this article comes from one fact table. Hover over a number to see its source, its provenance and the commit or date it was measured at. Provenance is one of three kinds. Measured means computed from git, the code or the logs. Documented means read from a record the port keeps. Estimated means a model or a hand classification.

The prose, widgets and data pipeline were drafted with Claude (Claude Code) and reviewed by the author; every number links to its source.

• Snapshot. Rustty at 58aa62a81, Ghostty at 246f70287, 10 October 2026. Session-derived figures (prompts, usage, cost) stop at 8 October. Days are counted in Pacific time, with 21 June as day 1.
• Commits. git log at that commit, with merges identified by parent count. Non-merge counts differ slightly by ref set, and each figure's tooltip names its source.
• Lines. Zig and Rust are compared in tokei code lines, which exclude comments and blank lines, with vendored code excluded. Growth and unsafe density use physical lines of tracked, non-vendored .rs files. The two are never plotted on one axis.
• Tests. Rust counts #[test] functions. Zig counts test "name" and test { blocks, with identifier-named test blocks noted separately. The per-module comparison maps each Zig module to its Rust counterpart.
• Comments. A distinctive Ghostty comment, five words or more, counts as carried when it has a fuzzy match among the port's comments after the rename.
• Models. Co-Authored-By trailers, parsed with git's own trailer parser (git log --format='%(trailers:key=Co-Authored-By,valueonly)'). Commits without a trailer stay unattributed.
• Prompts and engaged time. Claude Code's prompt history on the Mac and the Linux VM. Engaged hours are an estimate that clusters prompts separated by less than half an hour.
• Cost. Per-call token counts from the recovered Claude Code and Codex transcripts, priced at LiteLLM's list rates, with cache writes at the five-minute rate. The lost window is modeled as described in the cost section. Paid figures use public plan prices.
• Performance. A one-to-one port of Ghostty's benchmark tool and byte-identical inputs, Zig built with -Doptimize=ReleaseFast and Rust with a profile that differs from release only in overflow checks. Each figure is the median of seven or nine runs after a warm-up, with Zig re-measured in the same session. Short benchmarks are reported as per-operation slopes over several loop counts, not wall clock.
• Defects. Parsed from the port's upstream-defect ledger. The class comes from each entry's own kind field. The discovery method and the ReleaseFast consequence are hand classifications.
• Unsafe. The committed census command shown in the unsafe section.
• Hardware. A MacBook Pro, Apple M4 Pro, 14 cores, 48 GB. The Linux VM runs Fedora 44, aarch64, 8 vCPU, about 10 GB of RAM, with software OpenGL (llvmpipe) on Apple silicon. Windows builds x86_64 targets (MSVC and GNU) under emulation on a Windows 11 ARM64 VM.