Check it yourself

File identity and declared architecture. The hash pins the bytes, the part sizes pin the reassembly, and the configuration file states the shape of the network that consumes them.

• It is not a benchmark. Cassandra T1 publishes no MMLU, HumanEval or GSM8K score, and any percentage attributed to it comes from a draft we withdrew.
• The loss trajectory is a training log, not a held-out evaluation. It shows the run descended. It does not show the model is good.
• Output quality is research-stage. Short factual answers are better at epoch 5 than earlier, long-form generation is still unstable, and the repository says so in its own limitations section.
• The second checkpoint in the repository, the v2 scratch run, is newer by timestamp and worse by inspection. It is published for transparency, not as a baseline.

None. Hashes are compared as strings and sizes as integers. Two cosmetic differences are expected and neither is a failure: sha256sum prints lowercase where the repository table prints uppercase, and on a system where it opens files in binary mode it prefixes the filename with an asterisk. If one hex character differs, the file you have is not the file we released, and you should say so publicly rather than work around it.

Pointer check

Any machine with git and git-lfs. Under a minute, a few hundred kilobytes of traffic.

Full verification

2.6 GB download plus 2.6 GB of free disk for the reassembled file, so 5.3 GB in total while both exist. The download took about twenty minutes on a residential connection here, and reassembling and hashing took a few minutes after that.

Running the model

The inference scripts assume CUDA. A 1.3B model in FP16 needs roughly 3 GB of VRAM for weights and more for activations; 8 GB is comfortable. There is no CPU path in the released scripts.

Known friction

The released scripts carry path assumptions from the machine they were written on, and the repository says so. Expect to edit a path before an inference run starts.

Any one of these, demonstrated, retires the claim from this site.

• The reassembled file hashes to anything other than D70C813C513F5232A25313FA60338F862020BA942ED26D54F62511766FA5F044.
• The two parts do not sum to 2,659,500,664 bytes.
• src/model/config.py declares a different layer count, hidden size or head configuration than the table above.
• A third party loads the checkpoint and finds a parameter count that cannot be produced by the declared architecture.

Format invariants at high N with no language model and no network in the path. The coordinate is derived from a BLAKE2b hash of the breadcrumb prefix, so determinism is a property of the construction, and this run is the check that the implementation matches the construction.

• It is not a retrieval-quality result. Determinism says a locus always lands in the same place. It does not say that place is useful.
• It is specifically not evidence that the lattice coordinate carries semantic signal. Our own three-way ablation found the opposite: random coordinates and BLAKE2b coordinates gave byte-identical loss and byte-identical unforced generation, and the coordinate was retired to an audit channel. That negative result is on the XE4 page under retired mechanisms and we are not quietly leaving it out here.
• Cell utilisation in this run is 0.08% of the 262,144 cells, from 10,000 synthetic breadcrumbs drawn from a small vocabulary. That is a property of the test fixture, not a capacity measurement.
• The timing entries in the output are machine-dependent and are not part of the claim.

The five invariant tests take no tolerance. Every fraction must be exactly 1, prefix locality must be exactly 1,000 of 1,000, and the round-trip must report 23 in and 23 out. The four timing entries are expected to differ from the committed file and from each other run; the committed file records about 17 microseconds per coordinate and a recent run on a current laptop was closer to 11. Neither number is the claim. The token-savings entry at 1.18 is a byte ratio on one 1,056-byte corpus and is reported here only because it is in the output; it is not a token-reduction claim and the file says so itself.

Requirements

Node 20 or newer, npm, about 45 packages of build tooling. No GPU, no API key, no network after the install.

Runtime

npm install and the TypeScript build take roughly 20 seconds. The benchmark itself finishes in well under a second.

Verified on

Node 22.14 on Windows, clean clone at main. The five invariant tests matched the committed file exactly; timings did not, as expected.

Any one of these, demonstrated, retires the claim from this site.

• Any of the five invariant fractions comes back below 1.
• Two breadcrumbs sharing Topic, Subtopic and Concept land in different cells.
• The same breadcrumb produces different coordinates across two processes, two platforms or two Node versions.
• A locus identifier changes when only key order in the source JSON changes, which would mean the canonical form is not canonical.

That the runtime does what the specification says about position locking, and that the property is enforced in code rather than hoped for. The masked-diffusion path excludes locked indices from the set of positions the sampler may touch, so preservation is structural. The suite asserts the rate is 1.0 on that path and asserts it is below 1.0 on the API path, which is the more interesting of the two assertions.

• It is not a claim about the quality of generated text. Preservation says the locked span comes out unchanged. It says nothing about whether the tokens written around it are any good, and on this base model they often are not.
• It is not a guarantee on autoregressive APIs. There the runtime uses logit bias and retry, the guarantee level drops to best effort, and the measured rate can fall below 1.0. The suite tests that case explicitly rather than pretending it does not exist.
• The suite count is not a quality metric. It is reported here because the number is stated elsewhere on this site and a reader should get the same one.
• The counts below are the default install. Add the optional PyTorch extra and the ten tests in tests/test_ltmi_module.py run instead of skipping: nine pass and one fails. The failure is tests/test_ltmi_module.py::test_variant_factory_set, which asserts the variant registry holds exactly seven base variants when five width-sweep entries have since been added beside them. It is a stale assertion in a test, not a fault in the runtime, and it is filed. If you install the extra and see one red line, that is the line.

The preservation assertions take no tolerance: 1.0 means every locked position, and a single altered token fails the test. The suite totals will drift as the repository moves, and a count within a few tests of 253 on a later commit is a healthy suite rather than a failure. A count far below it is not. Exactly one failure is expected if you installed the optional PyTorch extra, and it is the stale registry assertion named above; any other failure is worth reporting.

Requirements

Python 3.10 to 3.12. CPU only. No GPU, no model weights and no API key for anything above.

Runtime

Install takes about a minute. The full suite finishes in under ten seconds.

Verified on

Python 3.10.11 on Windows, clean clone at main, which produced the counts printed above.

The part you cannot run

The live integration against Cassandra T1.5 needs weights that are not in this repository. It is marked live and deselected by default, which is why the deselected count is 1.

Any one of these, demonstrated, retires the claim from this site.

• A run where a locked span comes back altered on the masked-diffusion backend.
• The preservation assertion in tests/test_mdlm_base.py fails rather than passes.
• The API backend reports exactly 1.0 unconditionally, which would mean the best-effort path is not being measured honestly.
• A reader constructs a spec whose locked range overlaps a position the sampler still writes to.

Corpus-vocabulary overlap of the text a fine-tuned model generates after a locked anchor, on domains it never trained on. Three rank-16 LoRA adapters were trained on identical data for 300 steps at sequence length 192, differing only in which class of position the mask draw could touch, then scored on 15 in-domain and 48 held-out queries.

• The metric is vocabulary overlap, not accuracy and not likelihood. It measures whether the continuation stays in the right vocabulary, which on a model this weak is the only thing worth measuring, and it is not comparable to a benchmark score.
• It is a low-shot effect that closes. The sweep runs 1.97x to 2.19x at 100 training steps and falls to 1.07x by 1,000 steps on 144 examples. Presented as a permanent objective it would be a misrepresentation; it is one phase of a curriculum.
• One model, one size, one data regime. There is no evidence here that the effect survives at scale, on a different architecture, or on a different base.
• The cooking corpus is the weakest of the four domains. The effect there is positive but smaller, and the pooled figure carries it.

The corpus hashes are byte-exact and take no tolerance. The experimental figures do. A reimplementation with a different scorer and different seeds should be judged on three things rather than on digits: anchor beats random on the held-out set with a bootstrap interval that excludes 1.0; the held-out advantage exceeds the in-domain advantage; and the reverse control lands below random. A run that returns 1.4x or 1.9x with an interval excluding 1.0 has reproduced this. A run that returns 1.05x with an interval spanning 1.0 has not, and we would want to hear about it.

Requirements

One CUDA GPU. A 1.3B model in FP16 with rank-16 LoRA on four projections fits comfortably in 12 GB and was developed on consumer hardware.

Runtime

Measured rather than estimated, on the card the study ran on. Training all three arms takes 5.5 minutes, at 147, 75 and 101 seconds. Generating and scoring all four arms over 504 generations takes 11 minutes. The bootstrap is seconds on a processor. End to end that is about 20 minutes, plus the 2.6 GB download. An earlier version of this page said an hour, which was a guess and was wrong by roughly a factor of three.

The slow part

Writing the two missing arms and the scorer, which is still the cost today because that code is not public yet. Budget a working day, and match the paper's decoding settings exactly: 12 unmasking steps, temperature 0.8, top-p 0.9, repetition penalty 1.3 and a fixed generation seed. This entry changes the day the arms ship, and the 20 minute figure above is what the run itself costs once they have.

Not verified here

We did not re-run the study to publish this page. The corpus hashes, the artifact availability and the released trainer were checked. The training run itself was not repeated.

Any one of these, demonstrated, retires the claim from this site.

• Anchor-token masking does not beat random-position masking on a held-out domain at the same training budget.
• The held-out advantage is smaller than the in-domain advantage, which would make the effect a fit result rather than a generalisation result.
• The reverse-asymmetric control matches or beats random, which would mean the direction of the asymmetry is not what carries the effect.
• A Q and K only ablation matches the V and O ablation, which would move the mechanism away from the value and output projections and undercut section 6 of the paper.
• The advantage fails to decay with training steps, which would contradict our own sweep and suggest the measurement is picking up something else.

Peak resident set size of one process answering the same query two ways over the same file, at three store sizes, with the returned identifiers compared between the two paths. The point of the measurement is the shape of the curve rather than the height of it: streaming is flat and loading is linear.

• It is not an approximate-nearest-neighbour result. Both paths do a brute-force scan over every vector. Nothing here says anything about query latency at scale, and past roughly a million records an index is the right answer, not this.
• It is not a claim that the two paths cost the same. Streaming trades memory for read bandwidth. It reads the whole file on every query, which is exactly the tradeoff you would want stated before adopting it.
• 146 MB and 2,338 MB are one machine, one embedding dimension and one payload. Both numbers move with the interpreter, the numpy build, the embedding model held in the same process and whether record text is resident.
• It is not a statement about the public sophia-memory package. See the gap note below, which matters more than the headline.

Judge the shape, not the digits. The streaming column must stay flat within a few megabytes across a tenfold increase in store size. The load-all column must grow roughly linearly and land near the arithmetic size of the file, which at a million 384-dimensional float32 vectors is 1,536,000,000 bytes or about 1,465 MB. The identity column must be True at every size; if the two paths ever disagree on which records come back, the streaming implementation is wrong and the memory saving is worthless. Absolute resident figures vary by tens of megabytes with the interpreter version, the numpy build and the operating system, and none of that is the claim.

Requirements

Python 3.9 or newer, numpy, psutil, and about 2.1 GB of free disk for the three temporary files. No GPU.

Runtime

Roughly two to four minutes, almost all of it generating and writing the synthetic vectors rather than querying them.

Verified on

Python 3.10 on Windows, which produced the output above.

One thing worth knowing

A numpy memmap implementation does not hold resident memory flat on Windows, because mapped file pages count in the process working set. We measured it climbing to 1,495 MB at a million vectors, effectively matching the load-all path. Explicit chunked reads, as written above, do hold flat. If you implement this with memmap and see growth, that is the reason and not a refutation.

Any one of these, demonstrated, retires the claim from this site.

• Resident memory on the streaming path grows with the store size rather than staying flat.
• The two paths return different top-k sets on the same data and the same query.
• The load-all path does not grow roughly with the size of the file, which would mean the comparison is not measuring what it claims to.
• Someone demonstrates that the streaming path's read cost makes it unusable at the sizes we quote it for, which would not falsify the memory claim but would make it the wrong thing to have measured.