HyperCrux 0.3.0-beta.1, the First Release of the Beta Engine, Is a Pure Go Pre-Release for Linux

The Beta, the new HyperCrux engine in Go that an AI coding agent has built since 7 October 2026, has its first release. HyperCrux 0.3.0-beta.1 is out on GitHub as a pre-release, for Linux on x86-64 and ARM64. It keeps 0.x’s Go API and its command, with no SQLite and no C underneath, and 0.x stays the stable line.

The engine itself is in the progress report of 14 October, and its tests in how the Beta was tested. Moving from 0.x covers what changes for a program and its data. This post is about the release itself, and how fast it runs in the benchmarks recorded for it.

What the Release Holds

The release has two archives and a file of checksums, all on the release’s page:

Each archive holds the Beta’s hypercrux command, one static binary built with the Go toolchain alone, with its licence files and the Beta’s README. The binary has no SQLite in it, so the only third-party licence it carries is Go’s.

The release workflow built each binary on a machine of its own architecture and checked it there before anything was tagged. file had to call it statically linked, hypercrux version had to name 0.3.0-beta.1, and a smoke test had to put records with vectors, link them, read them back by key, by link, by similarity and by SQL, and send them through an export and an import. Then the workflow published the release itself, as it publishes 0.x’s, once the test and beta workflows had both passed on the commit.

Before the version went up, a last long run on GitHub’s machines tested the same code on x86-64 and ARM64, for up to five and a half hours a job: each of the six fuzz targets for 105 minutes, every crash point with 4,800 seeds, five runs of many processes at once for 63 minutes each, 1,000,000 random sequences compared with 0.x, and the 261 planted bugs, every one of them caught. All twelve jobs passed, and their record is in the long run’s results.

The Go package has the same version, since Go versions the whole module by its tags. v0.3.0-beta.1 holds the Beta’s package beside 0.x’s.

Getting It

For the command, download the archive for your machine and SHA256SUMS from the release’s page, check one against the other, and unpack it:

sha256sum -c --ignore-missing SHA256SUMS
tar -xzf hypercrux-beta_linux_amd64.tar.gz

The binary is called hypercrux, as 0.x’s is, so give it a name of its own on your PATH if 0.x’s is there already. Its version line says which engine it is:

hypercrux version

hypercrux 0.3.0-beta.1, file format 1

From Go, fetch the release by its version:

go get github.com/hypercrux/hypercrux/beta/hypercrux@v0.3.0-beta.1

Then import github.com/hypercrux/hypercrux/beta/hypercrux. The package is called hypercrux, as 0.x’s is, and needs no C compiler, so a program built on it can be one static binary as well. A plain go get github.com/hypercrux/hypercrux stays on 0.x, since Go leaves pre-releases out of a module’s latest version once the module has a release.

What It Leaves Out

The Beta runs on Linux alone. macOS comes after the Beta, and Windows needs file locking of its own. Every process that opens a database holds all of it in memory, so data bigger than memory stays out, and opening reads the whole file. The SQL is a subset of SQLite’s, without GROUP BY and HAVING, CASE, or joins other than the one to walk(), among others. SQLite’s file goes with SQLite, and so do its tools and 0.x’s Adopt.

So the release is a pre-release, and 0.x stays the stable line. GitHub’s latest release is still 0.x’s, which means the download page keeps giving 0.x’s builds for Linux, macOS and Windows, and 0.x’s fixes come as 0.2.x, below the Beta’s 0.3. A database moves between the two engines in one export, either way.

How Fast It Runs

The release’s benchmarks ran on 15 October 2026, both engines on the same two-core cloud machine in one run, three times each, and the middle result counts. They’re in the recorded results on GitHub.

In that run the Beta searched 5 to 10 times as fast as 0.x, and got and walked about 6 to 8 times as fast. A put in a batch of 1,000 took about half 0.x’s time, and a single committed put about four fifths. Opening is the price of the copy in memory: 323 ms, against under a millisecond for 0.x, which reads pages as it needs them.

That run’s machine read memory more slowly than the ones behind the earlier figures. Its search of 100,000 vectors took about twice the progress report’s 30 ms, and the Beta’s code of 8 and 14 October took as long on it the same morning, so the code isn’t the cause. The batched put varied most, at 12.9, 16.1 and 25.3 µs in its three runs.

Later releases of the Beta go up as 0.3.0-beta.2 and on, published the same way. The Beta’s README on GitHub says how to use it from the command and from Go, and the task board records how the release came about, task by task.