Viral 14T Anthropic model leak on Hugging Face is just seeded random noise

A file that claims to be the most valuable secret in AI turned out to be something anyone can rebuild with a hash function and a random number generator. Over the weekend a Hugging Face repository called burner22/numbat spread across X and reached the Hacker News front page as a leaked, mid training checkpoint of Anthropic's next "Mythos class" model. It promised about 14 trillion parameters, 114 layers, 1,224 experts and 7.72 TB of weights in 772 shards.

Within hours, people in the repository's own discussion tab showed that the weights were never trained at all. The numbers can be regenerated, bit for bit, from random noise seeded with the name of each tensor. We reran that check on Monday from a plain Python script, without running a single line of the repository's code, and got the same result: every value we tested matched exactly.

This story matters less because a fake was uploaded (fakes get uploaded every day) and more because of how fast and how cleanly it was disproved, and what that tells anyone who downloads model weights from the internet.

What the repository claimed

The model card reads like a confident insider post. It says numbat is "Anthropic's next Mythos-class training run" and that the files are a checkpoint "pulled mid-pretraining" at step 1,830,000 of a run of about 1.96 million steps. The architecture is described as a hybrid of Gated DeltaNet and Multi-head Latent Attention layers, with a mixture of experts block that routes each token to 48 of 1,224 experts plus one shared expert, and a multi token prediction head for drafting.

The weights are stored in NVFP4, a 4 bit format. The card explains this with a story: the eval team supposedly quantizes every async checkpoint so evals can run on "~85" Trainium2 chips instead of the full training cluster. A `ckpt_metadata.json` file reports an MMLU score of 88.5%, and a training log tail of about 400 steps shows plausible loss, learning rate and utilization numbers. There is even a reference implementation in `modeling_numbat.py` that claims to load every tensor with `strict=True`.

The argument for authenticity rests on two points. First, the codename is real. When the Claude Code source leaked through an npm source map on March 31, it contained the comment "Remove this section when we launch numbat." Second, the card stresses that "every tensor in every shard is internally consistent": scale blocks decode correctly, file sizes add up, and the index matches the shards.

Neither point says anything about whether the numbers came out of a training run. The codename only proves that the uploader read about the March leak. Internal consistency only proves that the files were generated carefully. As the analysis site sysnote points out, the account burner22 was created on October 16, has no other models, and finished uploading on October 24. Hugging Face's own metadata reports the model size as 6.8T parameters, not 14T, which a commenter flagged early on. Anthropic has not commented.

The audit that broke it

The decisive post came from a Hugging Face user named FloxUnder in discussion #13, titled "43 complete tensors exactly match name-seeded NumPy RNG output". The recipe is short enough to fit in a tweet:

1. Take the tensor's name, for example `model.layers.0.input_layernorm.weight`, and hash it with SHA256. 2. Read the first eight bytes of the digest as an unsigned big endian integer. 3. Use that integer as the seed for NumPy's PCG64 random generator. 4. Draw standard normal values in the tensor's shape. 5. For normalization weights, apply `exp(0.06 * z)`. For convolution kernels, multiply by one sixth. 6. Round to bfloat16 and compare with the bytes on the server.

FloxUnder reported that 43 complete tensors, 730,368 BF16 values in total, matched exactly. To rule out fitting the recipe to data after the fact, they also wrote down predictions for 21 tensors they had not yet read, 423,168 values, and every predicted value matched the bytes downloaded afterwards. The audit used HTTP range requests to fetch only small pieces of the first shard, about 90 KB, and ran none of the repository's Python.

FloxUnder was careful about the limits. The matches cannot logically exclude a training setup that kept these specific parameters frozen, and they say nothing about origin. That left one obvious objection: maybe the small tensors are synthetic filler, but the huge 4 bit expert matrices that make up almost all of the 7.72 TB are real.

That objection did not last long. In discussion #19, a user extended the same seeding scheme to the NVFP4 matrices. Using the same SHA256 seed, the weights follow a slightly more elaborate formula built from three random draws, then pass through standard NVFP4 quantization. Checking only the signs across 5,503 tensors from 770 of the 772 shards gave 162,246,496 matches out of 162,246,496. When they rebuilt ten full tensors from layers 2 to 108, 465,566,255 of 465,567,744 4 bit codes came out identical. They also noted that the output head is simply 0.891 times the embedding table, even though the config claims the two are untied. By their estimate, the embedding table is the only part with any real language structure, and it is roughly 0.04% of the bytes.

A third audit, discussion #31, reports that 377 of 377 norm tensors and 258 of 258 convolution kernels reproduce bit exactly, and that 192 million FP4 sign bits match.

We reran the check ourselves

Audits on a discussion board are only as good as their reproducibility, so we ran the recipe on Monday, November 2. Our script read the 16,344 byte JSON header of the first shard, which lists all 142 tensors in that file with their shapes and byte offsets. It then pulled every BF16 normalization and convolution tensor in that shard with HTTP range requests and compared them with the values predicted from the SHA256 seeds. We did not download the full shard and we did not execute the repository's modeling code.

The result: 18 tensors, 369,408 values, and all 369,408 matched exactly. As a control we ran the same comparison with a fixed wrong seed (12345). That matched 2,202 values, about 0.6%, which is what you expect from chance collisions when many values sit close to 1.0 in bfloat16. The gap between 100% and 0.6% is the whole story. A trained network cannot come out of a random generator whose only input is the tensor's name.

What trained weights actually look like

You do not even need the seed trick to get suspicious. Sysnote compared the RMSNorm weights of numbat with those of two real open models, Qwen3 8B and DeepSeek V3. In trained transformers these vectors start near 1.0 but drift far away during training, differ strongly from layer to layer and develop a few extreme outlier channels. One useful number for this is kurtosis: a plain bell curve has a kurtosis of 3, while heavy outliers push it much higher.

The real models show kurtosis values between about 21 and 157. Numbat sits at about 3 in every layer sampled, from the first to the last, with a mean of 1.0 and a standard deviation of 0.06. That is neither what a model looks like at initialization, where norm weights are usually exactly 1.0, nor what it looks like after training. It is what `exp(0.06 * randn())` looks like. A checkpoint supposedly 93% of the way through pretraining would not have flat, identical normalization layers at every depth.

Was it dangerous to download?

The Hacker News link to the repository was later removed "for malware concerns", which is a reasonable reflex. The README says the model loads through `AutoModelForCausalLM.from_pretrained(..., trust_remote_code=True)`, and that flag tells the transformers library to execute Python files from the repository on your machine. That is how many real custom architectures ship, and it is also the easiest way to hide a payload in something people are eager to try.

Sysnote read `modeling_numbat.py` and `configuration_numbat.py` without running them and found that they import only `torch`, `math`, `typing` and `transformers`, with no network, subprocess or file system calls. Security researcher Eric Parker reached the same conclusion. That describes the files as they were when they were checked; a later commit could change them. In practice, the bigger barrier was size: running the model would need on the order of 8 TB of accelerator memory, which limits the audience for any trap. Still, Hugging Face counted 7,108 downloads in the last month, so plenty of people pulled at least some of it.

Why this is more than a prank

The numbat upload is a small event with a useful lesson. Model weights are now a target for leaks, fakes and supply chain attacks, and the community just showed a cheap, repeatable way to test a claimed leak without trusting it.

Here is what it means in practice:

• For developers. Treat any "leaked" model like untrusted code. Read the safetensors header with a range request, inspect the modeling files as text, and never set `trust_remote_code=True` on a repository you cannot vouch for. Safetensors itself cannot execute code, but the Python that comes with a repo can.
• For researchers and journalists. Size, a plausible architecture and a real codename are presentation, not evidence. The test that settled this case took about 90 KB of downloads and a few seconds of compute. Ask for that kind of check before amplifying a leak.
• For platforms. Hugging Face hosts millions of repositories. Statistical checks on norm layers, or even a simple "does this tensor look like seeded noise" scan, could flag fabricated checkpoints before they trend.
• For AI labs. The real numbat codename made the fake more convincing. Every internal name that leaks becomes raw material for the next hoax, so the cost of source leaks keeps rising after the leak itself.

There is also a quieter point. Several of the audits, including FloxUnder's, describe themselves as AI assisted. The same tools that make it easier to fabricate a convincing 7.72 TB package also make it easier to take one apart in an afternoon. In this case the defenders won by hours.

What we still do not know

We do not know who uploaded numbat or why. Some commenters read it as an engagement stunt, others as an elaborate joke, and a few still argue that real weights could hide inside. The bit exact matches across 770 of 772 shards make that last theory very hard to defend. Two shards were not covered by the sign check, and the embedding table seems to contain some real structure, possibly borrowed from an existing tokenizer and model. Neither changes the conclusion that the repository is not a trained frontier checkpoint.

Anthropic has not said anything about the repository. On the same day, a separate rumor about a "Mythos 5.5" label in the HTML of Anthropic's own Mythos page made the rounds; that one is unrelated to the files on Hugging Face.

Sources

• Hugging Face repository: burner22/numbat
• Audit by FloxUnder: 43 complete tensors exactly match name-seeded NumPy RNG output (discussion #13)
• Sign bit check across 770 shards: discussion #19
• Norm layer comparison with Qwen3 8B and DeepSeek V3: sysnote
• Independent rerun: CellCog
• Our own check: 18 tensors from shard 1, revision 6b7f8fc, run on November 2, 2026