Samples from alleged Anthropic Numbat leak match seeded random values

A new public audit of Numbat, a repository claiming to contain a leaked Anthropic checkpoint, reported on November 2 that parts of its weights exactly match random values generated from their own names. AI Ping independently reproduced the published recipe for two arrays and found byte-for-byte matches with the stored data.

The finding gives people assessing the multi-terabyte upload concrete samples to examine. The repository was created on October 23. Its anonymous uploader describes a roughly 14-trillion-parameter, 7.72 TB checkpoint taken during pretraining. The claimed Anthropic origin remains unauthenticated. In the model card’s provenance FAQ, the uploader declines to provide information beyond the repository itself.

In the November 2 follow-up, user ressl reported extending the check to 289 normalization arrays and 258 convolution arrays. These larger counts are the author’s reported findings.

The earlier name-seeded check was posted by Hugging Face user FloxUnder on November 1. The author reported reproducing 43 complete arrays containing 730,368 values.

The recipe starts with an array’s name. A hash of that name supplies a seed for a pseudo-random number generator; repeating the process produces the same sequence. The post supplies the transformations for two weight families and the rounding step needed to compare stored values.

Two arrays, 36,864 matching values

AI Ping implemented the recipe separately and checked the specified repository revision at 10:32 UTC on November 2. All 12,288 values in an input-normalization array matched, as did all 24,576 values in a convolution array. Both were read from the first shard, one of the files into which the checkpoint is divided.

HTTP Range requests retrieved the relevant portions of that file. The reads totaled 90,080 bytes, including the header describing the file’s contents. The two weight arrays occupied 24,576 and 49,152 bytes respectively. Each selected array was compared in full, with every stored byte included in the equality check. The values used the two-byte BF16 format. Computed values were rounded to that format before comparison, using NumPy 2.5.4 and its PCG64 generator. The calculated and retrieved arrays also had matching hashes.

The first eight bytes specified the header length. Reading the next 16,344 bytes located the arrays and their sizes, consistent with the documented Safetensors format. The check accepted only partial-content responses with the requested byte ranges, verifying each response’s length before comparing the data. Each read was capped at 256 KiB. A response identifying a different range would stop the check, preventing bytes from another location from entering the comparison.

The check read data without executing the repository’s model code. Its scope was two arrays in one shard. It establishes that those stored values can be regenerated using the published calculation; it does not test whole-model performance or reconstruct a training history.

FloxUnder’s earlier post also noted the possibility of a training setup that deliberately kept the checked parameters frozen.

Checking file sizes and internal references addresses packaging. The Safetensors specification explicitly says tensor values are not checked. Reproducing values addresses the contents of selected arrays. A description naming a company and a model size supplies a separate provenance claim. The sample check connects actual stored bytes to a repeatable calculation, while leaving the upload’s origin unresolved.

The follow-up asks the uploader to provide any training configuration that kept those parameters fixed and explain the generation process and checkpoint-to-shard mapping.