Every comparison, exact figures.

Featured campaign

Input

Real service telemetry, one JSONL capture from 2026-06-03: 342,409,609 bytes, 681,648 records, SHA-256 prefix 9775bf5d. The capture is private and is not published.

ZJX build

1.28.0 LOCKWIRE, the executable shipped in the released Linux package; source revision 30307f19, executable SHA-256 prefix 10ee0d9e

Objective

compact; the fast objective wrote 4,412,984 bytes on the same input

Measured

2026-09-06

Metric

Complete archive bytes, format overhead included. MB is decimal (1,000,000 bytes).

Comparators

14 configurations of ten tools at strong settings, the world baseline set the ZJX laboratory uses; 14/14 completed. Several tools appear with more than one setting.

Verification

zjx test passed; restored file matched the source SHA-256; every comparator archive was decompressed and matched too. Verification compared restored bytes with the source; it did not compare filesystem metadata.

Result

ZJX compact 4,412,984 bytes against 7,125,674 bytes for zpaq -m5: 38.1% smaller than the strongest comparator and 98.7% smaller than the raw input.

One dataset, one capture, one build. This is the product's strongest published size comparison because telemetry is what ZJX is built for. It is not a universal compression-ratio claim and does not predict another workload. ZJX 1.29.0 leaves the compact and fast objectives unchanged; REDLINE gate P6 confirmed byte-identical compact and fast archives against 1.28.0 on the qualification corpora, so these bytes stand for the current line while staying attributed to the build that produced them.

All configurations

The strongest comparator is the smallest completed and verified non-ZJX archive. Percentages are 100 × (1 − ZJX bytes ÷ comparator bytes); a negative result would read as larger, an equal result as same size.

Every row on one scale

A linear axis from zero to the largest archive, 57.00 MB. No row is rescaled, truncated, or omitted.

1. ZJX 1.28.0 compact4,412,984
2. ZJX 1.28.0 fast4,412,984
3. zpaq -m57,125,674
4. zstd --ultra -22 --long=31 (tar)7,280,110
5. brotli -q 11 (tar)7,345,538
6. xz -9e (tar)7,612,052
7. zstd -19 --long=31 (tar)7,800,328
8. zstd -19 (tar)8,149,050
9. 7-Zip LZMA2 -mx=9, single thread9,392,518
10. 7-Zip LZMA2 -mx=99,666,962
11. RAR5 -m59,842,920
12. 7-Zip PPMd -mx=912,612,270
13. bzip2 -9 (tar)34,456,468
14. gzip -9 (tar)40,176,031
15. zip -9 (deflate)40,176,334
16. lz4 -12 (tar)56,999,958

Derivation

Exact bytes are the stored facts; percentages and megabytes are derived at build time and in the browser from the same module, so every surface rounds the same way.

signed_reduction_percent = 100 × (1 − Z / C)   with comparator bytes C > 0
raw_reduction_percent    = 100 × (1 − Z / R)   with raw input bytes R > 0
MB = bytes / 1,000,000

Featured values: Z = 4,412,984, C = 7,125,674, R = 342,409,609. Result: 38.1% against the comparator, 98.7% against raw input. Nothing is calculated from rounded megabyte strings.

Timing is indicative only

Wall time and peak memory in the size campaign were observed in single sequential runs on the ZJX laboratory host under an exclusive quiesced lease, with no other workload running. They are recorded in the source note as observations without repetition statistics, not as release performance evidence; ZJX performance qualification is a separate campaign under its own measurement law. Use them to judge order of magnitude, nothing finer. The only speed figures this site claims are the qualified REDLINE results in the next section, on their own cohorts and comparators.

REDLINE verified-creation campaigns, kept apart

Verified creation: archive creation plus an independent integrity check, 12 paired rounds per campaign, class-weighted geometric mean of per-round ratios, 95% bootstrap intervals. Subject: ZJX 1.29.0 at its default invocation: --objective ultrafast, four workers, then an independent test. Comparators: tar | zstd -1 (default, single admitted thread), verified by zstd -t, and tar | zstd -1 -T4 (four threads, the matched thread budget). Host: Quiesced laboratory host under an exclusive lease, 8 logical CPUs; the measured executable is the one shipped in the released package. A ratio is comparator time over ZJX time, so a value above 1 means ZJX was faster; every loss is printed as a loss. The two campaigns measured different cohorts and their figures are never combined into one statistic.

Development cohort (RG017): worker sweep and thread budgets

Sealed development cohort: silesia, enwik8, and a synthetic deduplication case; 12 paired rounds, 468 of 468 cells usable. Development cohort, not held out; the recipe was calibrated on these corpora. Archive bytes were identical at every worker count and byte-identical to both earlier release candidates. The default invocation costs about 1.19x the CPU of default tar | zstd -1 and admits about 65 MiB at the default 4 MiB units and four workers (about 71 MB at four workers against about 12 MB at one).

Negative results kept: eight workers is slower than four and slower than the default comparator; the four-worker default trails the comparator at two, four, and all threads. ZJX 1.29 is not the fastest archiver or compressor and is not generally superior to zstd. tar | zstd -1 with four or all threads is about 1.22x faster than the ZJX default on the development cohort and faster on 7 of 10 held-out cases. No leadership claim is made.

Held-out cohort (RG018): every case, both lanes

Four sealed members plus six privately held-out cases (about 1.86 GB, six workload classes) selected by a rule frozen before any measurement; ten classes, 12 paired rounds, 360 of 360 cells usable, run once. The six held-out cases were selected by a written eligibility rule and a deterministic hash before any compressor touched them, frozen with a manifest, and measured once against the unchanged package; 6 of 6 held-out cases restored exactly before the timed rounds. They are described here by workload class and size only. The gate lane compares the ZJX default with tar | zstd -1 -T4 (four threads, the matched thread budget); the reported lane compares it with tar | zstd -1 (default, single admitted thread), verified by zstd -t. The last column is ZJX archive bytes over the comparator's.

The verdict is the preregistered one, and the rules forbid changing the class structure after seeing the numbers in either direction. The PASS rests on the declared structure in which the two telemetry captures count as two classes; with them counted as one the ten-case reading is 0.7913. ZJX was slower than the four-thread comparator on 7 of 10 cases and faster on the three large-record cases. This is disclosed as engineering transparency, not as a marketing figure; no benchmark leadership is claimed.

Public release record · REDLINE source note · Release Chronicle, including what REDLINE did not achieve · The 1.29 support contract

How to read a measurement

Start with the version, dataset, settings, and comparison target. Then ask which operation was measured, whether every comparator completed, and exactly what was verified. Complete archive size includes format overhead; comparing it with raw input answers a different question from comparing it with another compressed archive, and the second question is the one that prices a migration.

• Creation time: elapsed time to make an archive. Less time is not the same percentage as increased speed. Qualified timings come from a dedicated controlled host.
• Memory: peak RSS is observed process memory. Configured limits and reserved memory are separate quantities.
• Restoration: archive integrity testing, exact source comparison, and metadata comparison must be named separately.
• Money: multiply the size advantage by eligible retained bytes and the storage rate you actually pay, then subtract compute, temporary space, migration, licensing, and restoration cost. The savings page does the first step only.

Missing measurements are Not reported, never zero. Relative improvements cannot establish absolute seconds, a total storage bill, or an independent audit.

Historical records, kept apart

These earlier results stay separate from the featured campaign because their exact ZJX version and settings are not reported in the public source note, or because they compare with raw input rather than a competitor archive. They are not current-release evidence.

Previous campaign on the same input

ZJX 1.27 CIPHERGLASS (2026-09-05, development host) wrote 4,412,968 bytes for the compact objective against the same 7,125,674-byte strongest comparator. The 1.28.0 archive is exactly 16 bytes larger: the manifest-integrity footer LOCKWIRE adds to every archive. Previous campaign source note

Pre-NIGHTMARKET size records (incomplete version attribution)

Exact ZJX version and compression settings are not reported for these rows; they stay historical. Historical source note, updated 2026-08-22

Raw-input example: Silesia v1, ZJX 1.21 STREAMWALL

Twelve files from a public benchmark collection, compared with the uncompressed input rather than a competitor archive. The 2026-08-30 record reports integrity testing and exact extraction under a 1 GiB host ceiling, 768 MiB ZJX memory ceiling, and 64 GiB temporary-disk ceiling. The exact compression profile is not named in the public note.

The reduction is 100 × (1 − 52,997,299 / 211,938,580) = 74.994%, rounded to 75.0%. The historical ZJX 1.2 reference failed without producing an archive, so its memory figure compares a completed run with an incomplete one. Original source note, archive digest, and conditions

Release-to-release measurements

NIGHTMARKET (Fast versus Compact on four corpora) and RELICWIRE (1.26 versus 1.25.1 creation time on two corpora) are release-to-release results, not competitor comparisons. They are summarized with their scope on the releases page. The REDLINE predecessor gate (ultrafast against released 1.28.0 fast: a creation ratio of 335x and a verified-creation ratio of 253x on the four-member cohort at the diagnostic tier, with ultrafast archives were 27% to 1,000% larger than fast's on those corpora) is a within-product comparison of two objectives with different goals and is not repeated on the homepage.

Sources

• Telemetry comparator campaign source note, 2026-09-06: commands for every comparator, tool versions and executable digests, hashes, per-run observations
• Previous telemetry comparator campaign source note (ZJX 1.27 CIPHERGLASS), 2026-09-05
• ZJX 1.29.0 REDLINE public release record and source note: the qualified verified-creation figures, the held-out disclosure, and what is not claimed
• Benchmark ledger on greyforge.tech, including failed and invalid experiments
• Research index: every public source note and release record

ZJX command recipes are not published; the evaluation report reproduces them for the customer. Commercial evaluation