ZJX 1.29 REDLINE: A Third Objective, Measured Twice
ZJX 1.29.0 REDLINE is released. It adds a third creation objective, ultrafast, beside compact and fast, and runs it with four workers by default. The Linux x86-64 package was published on September 8, 2026 as the qualified release candidate, promoted unchanged. Release record and package checksums.
Compact and fast are the objectives ZJX had before. Compact produces the smallest complete archive; fast takes less creation time while staying size-first. Both are unchanged in 1.29: on the qualification corpora their archives are byte-identical to what 1.28.0 writes. Ultrafast is the new one. It exists for the job where the archive has to be written and verified now.
What ultrafast does
Ultrafast is built for the shortest wall time. Creation runs through a deterministic parallel packer and testing through a streaming parallel verifier; both use four workers by default and accept one to eight. The worker count never changes the archive: one, two, four, and eight workers produce identical bytes on every qualified corpus, and every result records the workers requested and the workers used.
Ultrafast keeps the full integrity contract. The contents, the manifest and the archive all carry digests, metadata is exact under the same profile as the other objectives, and the archive is staged and published with one atomic rename. A 1.28.0 reader tests, inspects, and restores every qualified ultrafast archive. The 1.29 support contract states the rest: ultrafast requires the exact metadata profile, a request above eight workers is refused with the real limit rather than clamped, and the four-worker default admits about 65 MiB for creation and about 48 MiB for testing before any work starts.
Measured twice, reported twice
The qualified speed figures come from two campaigns on a quiesced laboratory host, and they are reported separately because they measured different cohorts. The metric is verified creation: create the archive, then verify it independently, in paired rounds against default tar | zstd -1, with 95% bootstrap intervals over the rounds. A ratio is the comparator's time over ZJX's time, so a value above one means ZJX finished first.
On the sealed development cohort of silesia, enwik8, and a synthetic deduplication case, the 1.29.0 default invocation measured 1.247x the verified-creation speed of default tar | zstd -1 (95% interval 1.223 to 1.267; Bonferroni-adjusted lower bound 1.221 over the three preregistered primary comparisons).
On a held-out cohort that no ZJX or comparator measurement had touched before the freeze, the same default measured 1.1959x default tar | zstd -1 (95% interval 1.1867 to 1.2043). The two numbers are not averaged, pooled, or reconciled. Each stands for its own cohort. Both campaigns in full.
The holdout, in the open
The held-out cohort was built to remove the author's hand from the selection. An eligibility rule was written and digested before anything was enumerated: six workload classes, real data that already existed for ordinary operational reasons, between 64 MiB and 1 GiB per case, disjoint from every sealed corpus. Within each class the candidates were ordered by a hash seeded with the package digest and the first was taken. No compressor ran on any candidate during enumeration, selection, or snapshot. The result was six cases totalling about 1.86 GB: a production service telemetry capture from a later day than the sealed one, an event-stream tick log, an application log, an agent session trace, a database snapshot, and a repository working tree of 24,997 files. They were frozen with a manifest, shipped to the laboratory host, digest-verified there, and measured exactly once against the unchanged package, alongside the four sealed members: 360 of 360 cells usable, every held-out case restored exactly before the timed rounds.
The preregistered held-out gate on that cohort passed. Case by case, ZJX led default tar | zstd -1 by up to 1.972x on silesia, 1.820x on the held-out structured-records case, 1.785x on enwik8, and 1.402x on the held-out application log. Per-case results.
What REDLINE delivers
Against released 1.28.0 fast, ultrafast measured a creation ratio of 335x and a verified-creation ratio of 253x on the four-member cohort at the diagnostic tier. Four workers is the sweet spot: an explicit --workers 4 measured 1.261x default tar | zstd -1 and two workers 1.062x, on the development cohort. Compact and fast keep the smallest archives for long-term storage.
The published package is the qualified bytes. The package and executables report the version literal 1.29.0-rc3, because they are byte for byte the third release candidate that every gate measured, promoted unchanged.
Requalified before release
The release candidate was frozen, packaged once on the laboratory host, and requalified in full: every product gate, both campaigns, and a second independent read-only review.
What stays the same
Everything 1.28.0 promised, 1.29.0 promises unchanged: the workflow, the fidelity contract, the compatibility table, the package layout with its rootless installer, checksums, build provenance, and offline restore guide. The package alone, in an empty path, created, tested, and restored every qualified corpus. The one build change is that 1.29.0 targets a portable baseline x86-64 processor and selects the hardware digest implementation at run time. Linux x86-64 with glibc is the supported platform. Availability, checksums, and package access.
The engineering lineage continues from 1.28 LOCKWIRE, which completed the workflow this release leaves intact. Choose compact when size matters, fast when balance matters, ultrafast when wall time matters. A scoped, paid evaluation measures all three against your own retention lane and your current method. Explore ZJX and discuss an evaluation. This Chronicle is free to read; commercial evaluation and business use follow separately agreed written terms.