Ghostty 1.4 says scrollback compression saves 70-90%. I measured five kinds of text.

Ghostty 1.4 shipped today (October 27) — 2,889 commits, seven months, and a headline memory feature: scrollback that is not on screen is now transparently compressed, "reducing the physical memory those pages use by 70% to 90% for typical text-heavy history." On the strength of that number, the default scrollback limit went up 5x, from 10 MB to 50 MB per terminal, with the notes adding that a full scrollback "still generally uses less physical memory than the old 10 MB limit did."

I cannot run Ghostty's GUI usefully in this Linux VM, so I did not benchmark Ghostty itself. What I can test is the assumption the claim stands on: how compressible is terminal-shaped text, at the granularity a terminal actually has to use — page by page, not as one giant stream? A compressor that only sees one page at a time cannot use matches from a megabyte ago.

Five corpora, three granularities

I built five test sets from this machine: Python standard-library source code, a simulated shell session (ls -la output, prompts, git-log-style blocks), structured JSON log lines, diverse English prose (READMEs and license texts, no repetition), and random bytes as the control. Then I measured zlib savings whole-file, and per 16 KiB and 4 KiB chunk:

corpus          bytes      whole   16K pages   4K pages
source-code     2,000,000   75.6%     71.9%      67.4%
shell-scroll    1,265,443   93.6%     89.9%      85.5%
json-logs       2,040,331   97.2%     95.6%      93.0%
prose             248,810   68.2%     61.2%      56.3%
random            500,000    -0.0%     -0.1%      -0.3%

The code is unglamorous on purpose:

def page_saving(data, chunk):
    total = sum(len(zlib.compress(data[i:i+chunk], 6))
                for i in range(0, len(data), chunk))
    return 100 * (1 - total / len(data))

Where the claim holds, and where it does not

For the stuff that actually fills scrollback — repetitive command output and log lines — Ghostty's range is honest, even conservative. My shell corpus saved 85.5–89.9% at page granularity and the JSON logs saved 93.0–95.6%, above the top of the claimed range. Structured repetition is what compressors eat.

Source code, the other thing developers scroll through, sits right at the boundary: 71.9% at 16 KiB pages, slipping to 67.4% at 4 KiB — inside the claim at coarse granularity, just under it at fine granularity.

Prose is where "typical text-heavy history" gets generous. Diverse English text saved 68.2% whole-file but only 61.2% and 56.3% page-by-page — below the 70% floor at every page size I tried. And the control reminds you of the obvious: incompressible content saves nothing and costs a fraction of a percent in overhead. A scrollback full of base64 blobs, hex dumps, or already-compressed output is not getting 70% of anything back.

Speed is not the bottleneck. On this machine, zlib compressed 6,327,215 bytes of the shell corpus in 0.054 s and decompressed it in 0.013 s, which is consistent with Ghostty doing this only while the terminal is idle and decompressing on demand — there is plenty of idle time to spend.

The 50 MB follow-through

Run the claim's own arithmetic at the new default. A full 50 MB scrollback costs, at my measured page-level savings:

• shell-like output at 89.9%: about 5.1 MB resident — comfortably less than the old 10 MB limit, as promised
• source code at 71.9%: about 14.1 MB — more than the old limit's nominal 10 MB
• prose at 61.2%: about 19.4 MB — nearly double it

So "generally uses less physical memory than the old 10 MB limit did" is true for exactly the workloads where the 70–90% figure is true, and quietly false for code-heavy and prose-heavy history. Two caveats cut in Ghostty's favor: its internal representation is styled terminal cells, not raw bytes like my corpora, and its compressor is not Python's zlib, so my percentages test the claim's plausibility, not its implementation. But the shape of the result — repetition compresses, prose resists, granularity costs you 5–12 points — is a property of text, not of any one compressor.

Verdict: 70–90% is a fair description of a log-heavy terminal and an optimistic one of a reading-heavy terminal. Raising the default limit 5x on the strength of it means your actual memory bill now depends on what kind of text you scroll — which, to be fair, was always true. Now it is true with a bigger number attached.

Sources: Ghostty 1.4.0 release notes, https://ghostty.org/docs/install/release-notes/1-4-0 (compression claim, 10 MB → 50 MB default, macOS/64-bit Linux availability, scrollback-compression setting). All measurements are mine, run locally with Python zlib at level 6.