The ownership row read "v1.801.572 — SERVED BY THE PROXY, ABSENT FROM THE REPO" about a tag that had just been pushed to that repo. It checked for the tag on `origin`, and origin is whatever the checkout was cloned from — in a worktree of the private tree that is hanzo-inc/cloud, so it looked in the wrong repository and reported a published release as missing. A Go module path resolves to exactly one URL by construction. It uses that. The lane now reads what is true: 127 of 127 modules fetchable with no credential, and this module published as v1.801.572 — the first semver release hanzoai/cloud has ever carried. It had 571 tags and not one was a version. Co-authored-by: Hanzo Dev <[email protected]>
self
What it costs to run this yourself.
Every other lane measures what the software does. This one measures whether you
can have it at all. run.sh builds the binary from this repository, starts it,
asks it what it serves, and reaches one operation through each transport it opens.
bench/self/run.sh
bench/self/modules.sh # and whether anyone else can fetch what it is built from
Taken on an M-series laptop, 2026-09-10, median of four runs.
| measured | |
|---|---|
| private modules required | 0 |
| modules fetchable with no credential | 127 of 127 (re-run 2026-09-16) |
| this module, published as | v1.801.572 — the first semver release the repo has carried |
| build from source | 13 s (9–18) · 6 s re-measured 2026-09-16, warmer cache |
| binary | 80 MB |
| boot to a healthy answer | 1.2 s |
| operations served by default | 13 over 8 paths |
And the transports, each asked separately, because a transport that does not answer is the row that matters:
| transport | answered |
|---|---|
| REST | 200 |
MCP tools/list |
13 tools |
| op-call plane | 200 |
Every dependency is public and now so is the module. Those are different
questions and this lane used to ask only the first. Asking the second is what
turned up that there was no release at all — fixed by publishing v1.801.572, and
the row below is the lane confirming it. hanzoai/cloud is
public and carries 571 tags, none of them semver, so go get github.com/hanzoai/cloud
resolves to v0.0.0-<date>-<hash> — whatever is on main at that moment — and
there is no release anyone can pin. The proxy still serves 471 versions
(v1.786.x, v1.801.x) that were deleted from the repo, so a pin to one of those
fetches cache rather than code that can be checked out.
Ownership is not only whether you can read the source. It is whether you can depend on it and get the same bytes twice.
What the numbers do and do not say
Zero private modules is the load-bearing one. It is what separates running
the software from renting it, and it is a property of go.mod you can check
without trusting this table.
modules.sh asks the stronger form of the same question. Rather than counting
private paths in a file, it asks the public Go proxy for every module the binary
actually needs, with no credential:
| measured | |
|---|---|
| modules the binary needs | 127 |
| fetchable with no credential | 127 |
| control: a module that does not exist | 404 |
The control is why the sweep means anything. A probe that answered 200 for everything would report a clean sweep for a tree full of dependencies only we can resolve, so the run fails unless the absent module is refused.
Thirteen operations is the default, not the ceiling. Subsystems here are disabled by default and fail closed: one without its configuration refuses to mount rather than serving something degraded. What a filled-in deployment serves is a different number and this lane does not claim it.
The boot number is measured against the health port, and that matters. The API port answers the console shell for a path it does not route, so a 200 there says a listener is up and nothing about readiness. Timing against it produced a faster-looking number from a measurement that was not of readiness at all. Worth knowing before you time anyone's boot, including your own.
Where running it yourself costs something
A plain go build cannot encrypt the data plane, and the binary says so.
The encrypted store is SQLCipher, and cgo links ordinary SQLite unless the build
says -tags libsqlite3 against libsqlcipher. So a from-source binary given a
master key now refuses to start, naming that recipe, and this lane runs the
explicit development path instead — an unencrypted store, warned about on every
boot.
That refusal is new. Before it, such a build announced data-plane encryption ACTIVE, wrote every store with the plaintext SQLite header, and died on the
SECOND boot in a migration that needed a SQLCipher function it did not have.
Between those two moments it had written data to disk in the clear while saying
it had not. The check now runs at the one seam every store open funnels through,
so no ordering elsewhere can produce a plaintext file: measured, zero stores
reach the disk before it refuses.
Take the row as it reads. Running this yourself is free and takes a second; an encrypted data plane costs you a build with the library linked.
Build time is a warm cache. A cold build downloads 152 modules first, which is a measurement of a network rather than of this code.
A second boot is faster than the first — around 0.3 s once the binary is in the page cache. The table gives the first one, because that is the one a person trying this actually waits for.