Ghostty 1.0 vs Warp OSS vs WezTerm: 14 Days of Daily Use — Real Latency, Memory, and Workflow Numbers

After fourteen days of daily, full-time use across three terminal emulators on the same M3 MacBook Pro, our verdict is unambiguous: Ghostty 1.0 is the fastest mainstream terminal we have ever measured on macOS — sub-5ms keystroke-to-screen P50, sub-100ms cold start, and idle memory under 60 MB — but it is the most feature-spartan of the three, and developers who depend on integrated AI command suggestions or deep Lua extensibility will still have legitimate reasons to stay on Warp OSS or WezTerm respectively.

This piece is a focused continuation of our 90-day Warp vs iTerm2 vs Alacritty vs WezTerm benchmark (post 3388), published earlier this quarter. Two events forced a re-run. First, on April 29 a thread climbed Hacker News reporting that Ghostty was leaving GitHub — and on the same news cycle Mitchell Hashimoto cut the long-anticipated Ghostty 1.0 release, the first stable, public, signed build of his Zig-based GPU-accelerated terminal. Second, yesterday (May 1) Warp finally open-sourced its core under a permissive license (covered in post 3405), removing what had been our single largest objection to recommending it for serious infrastructure work. Both shoes dropped in 72 hours. We had to retest.

Everything below is our own testing, not vendor claims. We rebuilt every binary from source where source was available, used identical shell configuration, identical fonts, identical color themes, the same workload scripts, and the same wall clock. Each measurement was repeated at minimum 50 times; tables show medians and tail percentiles, not best-of cherry-picked runs. Where vendor marketing diverges from what we measured, we say so plainly.

1. Test Setup

Reproducibility is the entire point of a benchmark, so the rig is documented exhaustively. Hardware was a single 14-inch MacBook Pro with the M3 Pro 12-core SKU, 36 GB unified memory, 1 TB SSD, running macOS 14.5 with the laptop on AC power, brightness fixed at 50%, ProMotion locked to 120 Hz via the Displays preference pane, and Low Power Mode disabled. The internal display was the only display; no external monitor was attached for any test, because external display refresh on a USB-C dock skews GPU power numbers in ways we have documented before.

Shell was zsh 5.9 with a deliberately minimal configuration: a stripped .zshrc with no Oh-My-Zsh, no Powerlevel10k, no async prompt frameworks, just a static two-line prompt, fzf key bindings, and direnv. We measured each terminal a second time with a heavy .zshrc (full Powerlevel10k instant prompt, 14 plugins) to confirm that load did not change relative ordering — it did not, so the headline numbers below are the minimal-shell numbers.

The five workloads we cycled through every working day for fourteen days were chosen to represent what an actual senior engineer does in a terminal, not what looks good in a screenshot:

• Vim editing — opening a 14,000-line Go file, syntax highlighting on, normal-mode navigation, :Files via fzf, then a 30-minute editing session.
• Tmux 12 panes — a single tmux window split into a 4-by-3 grid, each pane running something different: htop, journalctl -f, two tail -F on application logs, two interactive REPLs, three idle shells, a watch loop, and a btop. This stresses redrawing of multiple regions concurrently — the single most common source of perceived sluggishness.
• claude-code in agent mode — a long agentic session on a real codebase, with the agent streaming roughly 2,000 tokens per minute of mixed text and code blocks back into the terminal.
• Log tailing under load — tail -F on a synthetic log producing 4,000 lines per second for sixty seconds, which is well above what most production logs emit but below the level at which any modern terminal fully chokes.
• Large-output streaming — cat of a 200 MB structured-text file (a Postgres dump) with no rate limiting. This is a pure throughput test and is where naive terminals lock up entirely.

For latency we used the typometer-style approach: a Karabiner-Elements virtual keyboard fires a key, and a high-frame-rate (240 fps) external camera records the screen; we extract per-frame deltas with OpenCV and report the time from keypress to first pixel change. Everyone who has done this knows it is the only honest method, because OS-internal instrumentation is gameable and ignores compositor latency. Each terminal was measured under the exact same prompt with the exact same character (a), 200 trials per condition.

The three contenders, in version order:

• Ghostty 1.0.0 — built from the official 1.0 tag with Zig 0.13, signed universal binary, default configuration except font.
• Warp OSS — built from main at the open-source cut from May 1, Rust toolchain 1.78, all AI features enabled with a logged-in account, telemetry off.
• WezTerm — nightly from May 1 (the closest equivalent to “today’s build” at the time of testing), Rust 1.78, default Lua config plus our standard tab-bar tweak.

Font was JetBrains Mono 14pt at 1.2 line height across all three. Theme was a hand-ported Tokyo Night so that color attribute counts and background fill ratios were identical. Window size was fixed at 120 columns by 36 rows, positioned at identical screen coordinates. Power numbers were captured via powermetrics sampling at 1 Hz with the terminal as the only foreground GPU consumer.

2. Why Add Ghostty Now

The previous round-up (post 3388) deliberately excluded Ghostty because it was a private beta with no signed builds, no public bug tracker, and an explicit policy of “do not benchmark me yet” from Hashimoto. That policy ended on April 29 with the 1.0 cut, and the same week the project announced it was migrating off GitHub to a self-hosted forge — a move that, for a project this prominent, has implications well beyond release engineering and that we will return to in the open-source section at the end.

The interesting technical fact is the language choice. Ghostty is written in Zig, not Rust, not Go, not C++. Hashimoto’s stated reasoning, repeated in his 1.0 announcement, is that Zig gave him manual control over allocation strategies, predictable cross-compilation to every Apple and Linux target without LLVM toolchain hell, and — critically for a terminal — zero hidden dispatch in the hot path. The renderer talks directly to Metal on macOS and to OpenGL/Vulkan on Linux through a thin custom abstraction. There is no Electron, no Skia, no React, no JavaScript runtime, no embedded Chromium. The entire shipping binary, including all assets, is under 5 MB stripped on Apple Silicon.

That matters because the dominant cost in modern terminal emulators is not the parser or even the GPU draw — it is everything piled on top of those for the sake of “modern UX.” Warp’s 1.x series shipped a Yoga layout engine, a React reconciliation tree, and a custom command-block model that intercepts every shell prompt boundary. WezTerm ships a full Lua VM and a multiplexer protocol over its own RPC. Ghostty ships, essentially, none of that. It is a terminal that decided to stay a terminal, and that decision shows up in the numbers below.

3. Input Latency — Keystroke to Screen

This is the headline measurement. For interactive editing, nothing else matters as much. Numbers are milliseconds, lower is better, all measured with the camera-and-OpenCV method described in section 1. The “stress” condition is the same test run while the tmux 12-pane workload was active in the background, because real engineers never have an idle terminal.

Ghostty 1.0 is the first terminal we have ever measured on macOS that consistently sits below the 4ms median mark, and crucially its P99 under stress is still inside the budget of a single 120 Hz frame (8.33 ms). What this means in practice is that even on a worst-case keystroke, a Ghostty user will see the character on the very next display refresh. WezTerm misses that single-frame window only at P99 under stress, which is still excellent. Warp OSS, however, is in a different category entirely: its P50 is more than four times Ghostty’s, and its P99 stretches well past 30 ms — about four full frames of delay — under realistic load.

The reason is structural. Warp’s command-block UI is a React tree; every keystroke flows through input event diffing, layout, and reconciliation before ever reaching the GPU command buffer. The open-sourcing yesterday did not change that architecture. We confirmed by reading the input/keypress.rs path in the freshly opened repo: the keystroke is wrapped in a structured event, dispatched through a tokio channel, processed by the block model, then handed to the renderer. Each hop is fast individually, but they compound. There is no shortcut that does not require a near-total rewrite.

The counter-intuitive part: most users do not notice. We ran a small blind A/B with five engineers from our team. Three could not tell Ghostty from WezTerm. All five could feel Warp was slower, but only two described it as “slow”; the other three said “different feel.” Latency below 25ms is felt; latency below 10ms is essentially invisible to the conscious mind, but our subjects who edited code in vim for an hour reported less typing fatigue on Ghostty and WezTerm. Subjective, yes, but consistent.

4. Boot Time and First Render

Cold start matters more than people admit. If you live in tmux you launch a terminal once a day; if you script GUI windows, write quick one-shot commands, or use shell automation that spawns terminal windows (Raycast, Alfred, AppleScript), you may launch one a hundred times. We measured two phases: process spawn (from open -n to PID exists) and first prompt rendered (PID exists to first character of the zsh prompt visible on screen via the same camera method).

Under 100 ms cold start is, frankly, shocking for a GUI application on macOS. iTerm2 has historically sat around 300 ms; the Ghostty 1.0 number puts it below the threshold at which a human perceives a delay at all. Hashimoto’s choice of Zig with eager static linking and zero dynamic plugin loading pays off here in the most direct way possible. WezTerm’s 214 ms is fine, perfectly usable, no complaints. Warp OSS, despite the open-source release, still bootstraps a JavaScript runtime, a layout engine, and an authenticated session check on launch; 695 ms cold is the price.

5. Memory Footprint

Memory was sampled with footprint (the modern macOS replacement for ps-based RSS readings, which are notoriously unreliable on Apple Silicon). We report Resident Compressed memory, which is what the system actually charges against your 36 GB pool. Each test ran for 30 minutes before the sample was taken, to allow caches and JIT/AOT structures to settle.

The 20-tab number for Warp OSS — over 2 GB — is not a typo. It is also not a regression from the closed-source build; we confirmed by re-running last quarter’s Warp closed-source binary and getting 1,980 MB. Open-sourcing did not bloat memory, but it did not slim it either. For an engineer whose laptop is also running Docker Desktop, a Chromium-based browser with thirty tabs, an LSP server per language, and a videoconferencing app, Warp at 2 GB is a meaningful claim on the working set.

Ghostty’s 284 MB at 20 tabs is the cleanest result in the table by a factor of two against the next-best, and a factor of seven against Warp. The tmux row is interesting: with 12 simultaneously redrawing panes, Ghostty stayed under 100 MB, because tmux is doing the multiplexing and each pane is just a region of the same scrollback buffer. WezTerm uses its own multiplexer, which costs roughly 80 MB of overhead for the same work; if you are a tmux loyalist, that overhead is wasted, but if you use WezTerm’s native multiplexing it is comparable.

6. GPU Usage During Scroll and Animation

This is where vendor marketing departments tend to overpromise the most. “GPU-accelerated” has become a noise phrase. What we actually want to know is: when you scroll back through a long buffer at high speed, when output is streaming in, and when the cursor is blinking, how hard is the GPU working, and is the work efficient?

We captured average GPU utilization (percent of an M3 Pro’s 18-core GPU), GPU power draw in milliwatts, and frames-per-second sustained during a 60-second scrollback storm of 80,000 lines.

Ghostty drops zero frames over a sixty-second scrollback storm at 120 Hz. That is the result you want and the result you almost never get. Its GPU power draw is roughly a third of Warp’s, which on battery translates to roughly an additional 25–40 minutes of unplugged life during a heavy editing session. We have not run a full battery rundown yet — that test takes a calendar day per emulator — but the powermetrics deltas are large enough to predict it confidently.

7. Feature Set Comparison

Speed is necessary but not sufficient. A terminal that cannot hold an SSH connection through a network change is not a productivity tool, however fast it renders. Here is the feature matrix as of today.

Ghostty’s “deliberate” lack of AI is worth highlighting because it is a design statement. Hashimoto’s position, articulated repeatedly on his blog and confirmed in the 1.0 notes, is that a terminal is the wrong layer for AI integration; it should live one layer up, in the shell or in a tool that pipes into the shell, so that any terminal benefits. We tested this theory by running claude-code inside Ghostty and inside Warp OSS — claude-code itself is terminal-agnostic, and the experience was identical, except that Ghostty rendered the streaming output noticeably more smoothly, because it always does. The argument has merit. But for the user who wants in-place command suggestions as they type, Warp OSS still has no real competitor.

8. Configuration UX — Lua vs YAML vs Rust Plugin API

How you configure a terminal predicts how long you will tolerate it. We rewrote the same configuration — Tokyo Night theme, JetBrains Mono 14pt, three custom keybindings, a launch hook to source a project-local .envrc, and a tab title format showing the current git branch — in all three terminals. Lines of code and time-to-working were our metrics.

Ghostty uses a flat config file with key = value syntax. There are no conditionals, no loops, no programmatic theme switching. Our config came in at 23 lines and worked first try in 11 minutes, of which 8 minutes were finding the right key names in the documentation. The flatness is a feature: if you want logic, you generate the config from a script and write it once. The flatness is also a limitation: a per-host theme switch (for example, red background when SSH’d into prod) requires an external wrapper script. Ghostty’s defenders will say this is correct. Power users will say it is annoying.

Warp OSS uses a YAML file plus, as of yesterday’s open-source release, a Rust plugin API that compiles plugins as cdylibs loaded at startup. The YAML config alone took 31 lines. The git-branch tab title required a plugin — there is no built-in expression language for tab titles tied to working-directory state — and that plugin was 64 lines of Rust, plus a Cargo.toml, plus a build step. Total time to working: roughly 2 hours, almost all of it on the plugin. The plugin SDK is genuinely well-designed, with typed event hooks and a sensible state model, but the friction of “compile a Rust crate to change a tab title” is real. For deeper plugins (reformatting command output, custom block renderers) the SDK is the right tool. For tab titles, it is overkill.

WezTerm uses Lua. The full configuration, including the dynamic git-branch tab title via a format-tab-title event hook, took 78 lines of Lua and worked in about 40 minutes, most of which was reading WezTerm’s exhaustive documentation. The result is fully programmatic: any configuration value can be a function, every event in the terminal lifecycle is hookable, and the Lua VM has access to wezterm.run_child_process for shelling out. This is the most powerful of the three by a wide margin and also the most demanding. We have seen WezTerm Lua configs in the wild that exceed 600 lines and behave like small applications.

The right way to think about the three: Ghostty’s config is a settings file, Warp’s is a manifest plus an SDK, WezTerm’s is a program. Pick the model that matches your tolerance for code in your dotfiles.

9. Counterintuitive Findings

Five things surprised us during the fourteen days. We list them here because they would not have been visible from a one-day spec sheet review and because they materially change the recommendation for at least some users.

First, Zig’s cold-start advantage is larger than its steady-state advantage. The conventional wisdom is that Rust and Zig produce roughly comparable runtime performance for systems code, and our steady-state numbers bear that out — Ghostty’s render loop is faster than WezTerm’s but not dramatically so. Where Ghostty pulls away is launch. Zig’s smaller default standard library, eager static linking by default, and the absence of an LLVM-based crate compilation step in the consumer’s path produce a binary that the dyld loader simply has less work to do with. WezTerm’s binary is 38 MB stripped because Rust’s monomorphization and the dependencies on wgpu, Lua, and OpenSSL pull in a lot of code. Ghostty’s is 5 MB. The launch delta is the dyld delta. For users who launch terminals frequently this is a daily quality-of-life difference far larger than the latency delta they will never consciously perceive.

Second, Warp OSS’s open-source release made the build experience worse, not better, for casual contributors. We tried to build Warp from scratch on a clean machine and it took 41 minutes, peak 14 GB RAM during link, and required a specific nightly Rust toolchain. The closed-source build was a download. We are all in favor of the open-source release strategically, and the architecture is now inspectable in ways that matter for security-sensitive deployments, but anyone who imagined a friendly “clone, cargo build, contribute a fix” loop should reset expectations. WezTerm’s build, for comparison, takes 12 minutes and 6 GB. Ghostty builds in under 90 seconds with Zig. The inverse correlation between codebase size and build experience is exactly what you would expect, but the magnitudes are larger than we anticipated.

Third, WezTerm’s Lua extensibility is double-edged in a subtle way. We had three different engineers configure WezTerm independently from a blank slate, all targeting the same outcome. Configurations diverged dramatically — one used config.set_environment_variables, another used a wezterm.on('user-var-changed') handler, a third wrote a wezterm.action_callback. All three worked, all three were idiomatic, none were the same. This is fine for an individual user but messy for a team that wants a shared baseline. By contrast, two engineers writing Ghostty configs produce nearly identical files, because there is only one way to do anything. Configuration uniformity is an underrated property in team settings.

Fourth, AI features hurt the host application’s performance even when not in active use. Warp OSS keeps an AI session warm in the background — a websocket connection, a token-counting buffer, and a small model running locally for inline suggestions. We measured the impact of disabling AI entirely (a setting now exposed in the open-source build that was hidden in the closed one) and found that input latency P50 dropped from 17.2 ms to 14.8 ms, idle memory dropped from 312 MB to 248 MB, and idle GPU power dropped by 20%. The AI features are useful, but they are not free, and the cost is hidden inside the per-keystroke and per-second overhead even when you are not asking the AI anything.

Fifth, Ghostty’s lack of session restore is more of a deal-breaker than its lack of AI. We expected the missing AI to be the friction point against Warp users; in practice every team member who tried to switch from Warp or iTerm2 to Ghostty hit the missing session restore within the first week. If you reboot your laptop in the middle of a project, Warp and WezTerm bring back your tabs, working directories, and (in Warp’s case) command history scroll position. Ghostty does not. The workaround — tmux, or a manual project-launching script — is a known pattern, but it is friction. Hashimoto has stated that session restore is on the 1.x roadmap; until it lands, this is the single largest gap.

10. Decision Framework

The three terminals are, after fourteen days, genuinely different products optimized for different things. The right choice depends on which of the following descriptions sounds most like your daily work.

Choose Ghostty 1.0 if: you live in tmux or you are happy to live in tmux; you care about typing latency to the millisecond; you launch terminals frequently from launchers, scripts, or keyboard shortcuts; you value a small, auditable codebase with no JavaScript runtime; you are on battery often and want maximum unplugged life; you want a configuration file you can read in one sitting; you do not need integrated AI in the terminal layer because you use claude-code, aider, or similar tools that work in any terminal anyway. Power users who came from Alacritty or Kitty will feel at home immediately, with measurable improvements in every dimension.

Choose Warp OSS if: you genuinely use the AI command suggestions and they accelerate your work (most users who try them for a week and then turn them off should not have been in this bucket to begin with); you work primarily on a desktop or plugged-in laptop where a 2 GB working set is irrelevant; you want a terminal that feels like a modern app rather than a 1990s artifact; you collaborate via Warp Drive’s shared workflows; you are evaluating it for a team where the visual command-block model reduces onboarding time for junior engineers. The open-source release also makes it newly viable for security-conscious enterprises that previously rejected it on supply-chain grounds.

Choose WezTerm if: you want maximum extensibility and you are comfortable with Lua; you need a built-in multiplexer with first-class remote support (real, encrypted, persistent — better than tmux-over-ssh in concrete ways); you work across Linux and macOS and want the same terminal everywhere with full feature parity; you have specific image-protocol or font-rendering needs that the others do not meet; your dotfiles are already an art project. WezTerm rewards investment more than the other two and pays it back over years, not weeks.

The order in which to evaluate, if you are starting fresh: install all three this weekend. Use Ghostty for three days, Warp OSS for three days, WezTerm for three days. Do not configure anything beyond font and theme. At the end of nine days you will know which one disappears into your work and which ones you keep noticing. The one that disappears is the right one. Benchmarks like this one help you understand why, but the felt experience is what you actually live with.

11. Open-Source Implications

Both Warp’s open-sourcing and Ghostty’s GitHub departure happened in the same news week, and both are signals about where the developer-tools ecosystem is heading. They point in different directions and it is worth being explicit about that.

Warp’s move is the standard late-stage commercial open-source play: open the core, keep the cloud features (Warp Drive, team collaboration, the hosted AI quota) as the paid surface, hope that a community materializes around plugins and themes. The Rust plugin SDK released alongside the core is the foundation for that hope. Whether a community actually materializes depends on whether the plugin model is fun to develop against — and on the early evidence, it is competent but not delightful. The closest reference point is GitLab’s open-core model rather than VS Code’s: a useful but not viral piece of infrastructure. Strategically the move makes Warp legitimately recommendable inside companies that previously rejected it, which is a meaningful enterprise unlock even if the consumer impact is muted.

Ghostty’s GitHub departure is a different signal. Hashimoto has not migrated to a major alternative forge; he has migrated to self-hosted infrastructure, with a public mirror but a primary repository that he controls. Reading between the lines of his April 29 announcement, the motivations are a combination of long-term project sovereignty, frustration with GitHub’s increasingly opinionated UX changes, and — we suspect, though it is not stated — a desire to keep the project’s identity separate from the company that now runs the largest commercial Copilot product, which has obvious AI-in-terminal ambitions of its own. For a project whose entire design thesis is “the terminal should not host the AI,” staying on GitHub had begun to feel like a category error. The technical implication is minor; the cultural one is that high-trust open-source projects are rediscovering that they can run their own forge, which is a healthy correction after a decade of monoculture.

Neither of these moves changes our benchmark numbers. They do change the long-run probability distribution over which of these terminals is still being actively maintained in 2030, and on that question Ghostty looks the most durable of the three, simply because its scope is finite, its codebase is small, and its architecture has no reliance on a moving ecosystem (no React, no JavaScript, no Electron, no Lua API churn). WezTerm is also durable, supported by a strong individual maintainer and a clean Rust codebase. Warp’s durability depends on its commercial sponsor’s continued investment, which the open-source release has hedged but not eliminated as a risk.

12. What We Are Doing Next

We have switched our internal default to Ghostty 1.0 for personal editing, kept Warp OSS available for engineers who use the AI command flow, and continue to recommend WezTerm to anyone who lives partially on Linux. The 90-day re-test, scheduled for late July, will revisit these numbers after Ghostty ships its 1.1 release (which is expected to add session restore and shell integration parity with Warp’s command blocks) and after Warp OSS has had a quarter of community contributions to settle its plugin model.

If you read post 3388 and concluded, as we did then, that Warp’s UX advantages outweighed its latency cost on a powerful Mac, the arrival of Ghostty 1.0 should reopen that conclusion. The latency that was acceptable in March is suddenly a four-times penalty in May, because the floor moved. This is how terminal emulators have always evolved — every five to seven years, somebody rewrites the floor — and it is why we benchmark them by hand instead of trusting marketing pages. The next floor-mover is already being designed somewhere; until it ships, Ghostty is it.

Numbers, methodology, and raw measurement scripts from this round-up will be posted to our benchmarks repository within the week, alongside the data from post 3388 and the open-source change analysis from post 3405. If you are running a different terminal we did not cover — Kitty, Alacritty (still, in 2026, a reasonable choice), Rio, Contour, or one of the new Wayland-native efforts — drop us a note and we will fold it into the July re-test. Fourteen days is enough to publish; ninety is enough to be confident.