Anthropic Mythos Leak on Hugging Face: Is burner22/numbat Real? Fact-Check of the 14T-Parameter, 7.72 TB NVFP4 Checkpoint
The hottest AI story of the weekend is a Hugging Face repository called burner22/numbat that claims to hold a mid-pretraining checkpoint of Anthropic’s next “Mythos-class” model: 14 trillion parameters, 114 layers, 1,224 experts and 7.72 TB of weights. If it were real, it would be one of the most astonishing closed-model weight leaks ever. Our verdict comes first: for this alleged Anthropic Mythos leak there is no evidence of origin, and several public, checkable pieces of evidence point to data generated from tensor names, so we treat it as fake. We did not download any weights and did not run any code. Every number below comes from Hugging Face’s pages and API, a few small text files in the repo, and other people’s published audits, and each is attributed. If you read our earlier fact-checks of viral modified models (the OBLITERATUS build and the GSQ-RCO build), this one follows the same method: check the numbers first, then the provenance.
Key takeaways (updated 2026-11-02, Beijing time)
- The repo is real, public and still up: 772 weight shards, with Hugging Face recording 7,720,640,941,879 bytes of storage, matching the claimed 7.72 TB.
14T and the “6.85T” on the HF page do not contradict each other: HF counts bytes of packed 4-bit weights, which converts to about 13.68T values. The numbers are self-consistent, but consistency does not prove authenticity because a careful fake can match too.
A community member reports that 43 complete tensors can be regenerated bit for bit from a NumPy random generator seeded by the tensor name; another reports the same for the large NVFP4 matrices (about 99.6% of the bytes). We did not reproduce either, and the first author notes it does not prove origin by itself.
The repo contradicts itself: it calls the checkpoint “mid-pretraining” while its metadata puts it at step 1.83M of about 1.96M (about 93%), and it says NVFP4 evals ran on Trainium2 while AWS’s documentation lists no FP4 type.
We found no Anthropic statement about this repo. The only relevant official statements are that the Claude Code source leak did not include model weights and that Mythos Preview is not planned for general availability.
The Short Answer: Seven Claims Checked Against the Evidence for the Anthropic Mythos Leak
The table below sets the repo’s main claims next to what we actually read. The verdict column reflects our reading of the evidence, not anyone’s motives.

| Claim | What we read | Source and status |
|---|---|---|
| 14T parameters | About 13.68T 4-bit values plus 16.85B BF16 parameters | HF safetensors metadata, our own conversion |
| 7.72 TB in 772 shards | 772 model-*.safetensors files; 7.72064 trillion bytes of storage | HF API, checked |
| From Anthropic | No provenance; the FAQ says only “Is this real? Yes.” | README, uploader’s own words |
| Mid-pretraining checkpoint | Metadata: step 1,830,000 of a roughly 1.96M-step run; lr phase “decay” | ckpt_metadata.json and README, self-reported |
| MMLU 88.49% | Bundled eval result, 0-shot, n=14,042 | Self-reported, not reproduced by anyone |
| Weights come from training | Community audits say some tensors can be recomputed from their names | Discussions #13 and #19, not reproduced by us |
| The codename numbat appeared in the Claude Code leak | Several sources quote the comment; we did not open the leaked source | README; sysnote and others |
What Is Actually in the numbat Repository?
On the morning of 2026-11-02 we read the repository through Hugging Face’s public API and downloaded only a handful of tiny text files: the README, config.json, ckpt_metadata.json, hf_quant_config.json, the two Python files and about 66 KB of training-log tail. We touched none of the weight shards. What we found: the repo is public, not gated and not disabled; it was created at 01:37 UTC on 2026-10-23, and its last commit was at 19:09 UTC on 2026-10-24, titled “Upload model-00645-of-00772.safetensors with huggingface_hub”, which looks like a batch upload; the page shows about 5,846 downloads (a page figure that does not mean anyone ran the model) and 204 likes; besides the 772 shards there are 12 small files, including the README, the config, a roughly 151 MB index file, the tokenizer, two custom Python files and the training-log tail. The uploader account, burner22, has only this one model, and sysnote reports the account was created on 16 October.
The README claims roughly 14T parameters, 114 layers, a hybrid of Gated DeltaNet (GDN) and multi-head latent attention (MLA), a mixture of experts with 1,224 routed experts (48 active per token plus one shared expert), NVFP4 quantization, the internal codename numbat, “Anthropic’s next Mythos-class training run”, pulled mid-pretraining. It then offers a “Why believe this?” list: the codename appeared in the Claude Code leak, the architecture “matches what would be expected” of a next-generation run, every tensor is “internally consistent”, and file sizes and index entries are deterministic. None of those four is evidence of origin. The codename is public, the architecture is a combination of published papers, and consistency and determinism are exactly what generated data looks like.
Do the Numbers Add Up? Checking 14T Against 7.72 TB
This is the most misread point. Two opposite arguments circulate: “HF shows 6.85T, which does not match 14T, so it is fake” and “the size matches, so it is real”. Neither is rigorous.
HF’s safetensors metadata lists three kinds of data: 16.85 billion BF16 values, about 139 thousand F32 values and about 6.83 trillion U8 values, for a total of 6,849,377,242,584, which is the 6.8T on the page. But NVFP4 packs two 4-bit values into one byte (U8), so 6.83 trillion bytes hold about 13.67 trillion 4-bit weights; add the BF16 part and the total is about 13.68T, close to “about 14T”. The 6.85T on the page is therefore an artifact of counting stored bytes and is not evidence that the numbers do not match.
The size works out too. NVFP4 shares one 8-bit scale per 16 weights, so each weight costs about 4.5 bits (0.5625 bytes). 14T times 0.5625 is about 7.88 TB. With 13.67T 4-bit weights, the packed codes are about 6.83 TB, the scales about 0.85 TB, and the BF16 part about 34 GB, for about 7.72 TB, which matches the 7.72064 TB HF records. We also estimated the parameter count from config.json: 107 MoE layers, 1,224 experts each, three 12,288 by 2,816 matrices per expert, which gives about 13.6T for the routed experts alone, in line with the claim. So the numbers are fully self-consistent. That shows whoever built the files did careful arithmetic; it does not show the data came out of a training run.
| Check | Estimate | Versus the repo |
|---|---|---|
| Number of 4-bit weights | 6.83T U8 bytes x 2 | About 13.67T |
| Size including scales | 13.67T x 0.5625 bytes + BF16 part | About 7.72 TB, matches |
| Routed expert parameters | 107 x 1,224 x 3 x 12,288 x 2,816 | About 13.6T, matches |
| Active parameters per token | Our rough estimate from the config | About 0.6T (discussion #14 says about 550B) |
Why the Weights Look Generated, Not Trained
This is the most important evidence in the whole story, and the one where we must word things carefully.

The author of discussion #13 ran a reproducible audit. Using only small HTTP range requests and executing none of the repo’s Python, they found that 43 complete tensors (28 normalization weights with 238,848 values and 15 convolution kernels with 491,520 values, 730,368 BF16 values in all) can be regenerated from their names alone: take the first 8 bytes of the SHA-256 of the name as a seed, feed it to NumPy’s PCG64 generator, and the output matches bit for bit. They say they recorded predictions for 21 tensors before reading them and all matched afterwards. The same author states the limits: this cannot logically exclude a training setup that deliberately froze these parameters, and it does not authenticate the claimed origin.
The author of discussion #19 goes further and claims the big NVFP4 matrices are produced the same way: draw random numbers with the same seeding scheme, apply a simple scaling formula, run standard NVFP4 quantization; together with their block scales these make up about 99.6% of the checkpoint. They report checking the signs of 5,503 tensors from 770 shards, about 162 million values, all matching, and rebuilding 10 tensors in which only about 1,500 of roughly 465.6 million 4-bit codes differed. They also say lm_head is about 0.891 times the embedding matrix even though the config says the two are untied. Separately, the third-party site sysnote sampled normalization weights with range requests: at every depth the mean was about 1.0 and the standard deviation about 0.06 with no outliers, which reads like 1 plus 0.06 times random noise, whereas a network trained to 93% of pretraining would normally drift visibly from initialization and grow outlier channels.
Our position: these are public, checkable, clearly described claims that independently point the same way, and nobody has posted a rebuttal. But we have not reproduced them, so throughout this article they are written as “X reports”. If you are a researcher, the most valuable thing you can do is to follow the method in #13 and sample a few tensors with range requests yourself, rather than downloading the whole thing.
Where the Repo Contradicts Itself
Beyond weight statistics, several contradictions in the repo’s own text need no reproduction at all. We checked each one.
First, “mid-pretraining”. The README says the checkpoint was “pulled mid-pretraining”, and the FAQ puts it at step 1,830,000 of a run of about 1.96M steps, around 93.4%. Every line of the training-log tail is tagged lr_phase=decay, with a learning rate near 7.19e-5 falling slowly. Step 93% in a learning-rate decay phase looks more like the late stage of a run than the middle.
Second, NVFP4 evals on Trainium2. The FAQ explains that the eval team quantizes every async checkpoint to NVFP4 so evals run on a slice of Trainium2 chips, “still about 85 of them”. We checked the AWS Neuron documentation: a Trainium2 chip has 96 GiB of HBM, and the documented data types are FP32, TF32, BF16, FP16 and the FP8 family, with no FP4. A community commenter noted that NVFP4 is an NVIDIA format. The memory arithmetic does work: 85 chips times 96 GiB is about 8.76 TB, enough for 7.72 TB. But that only shows the sizes are plausible; it does not solve the data-type problem.
Third, evals and logs. ckpt_metadata.json carries MMLU 0.8849 (n=14,042), ARC-Challenge 0.7201 and HellaSwag (normalized) 0.8896, all self-reported with no independent reproduction. In the 400 steps of the log tail we counted the gaps between consecutive steps: of 399 intervals, 261 were 7 seconds, 93 were 6 seconds and 45 were 8 seconds, at roughly 11 to 13 million tokens per second. Some commenters find such a tidy pattern suspicious; we consider it weak evidence, because timestamps are only second-resolution and a 6 to 8 second wobble around 7 seconds is normal. At about 84 million tokens per step, step 1.83M implies roughly 150T tokens in total. We cannot judge whether that is realistic for any lab, only that it is an extraordinary unverified number.
The numbat Codename and Anthropic’s Official Position

The most persuasive item in the repo is the codename. Several sources report that on 31 March 2026 Claude Code leaked via an npm source map, and that one comment in it reads “Remove this section when we launch numbat.” Anthropic told the press it was “a release packaging issue caused by human error, not a security breach” with no customer data or credentials exposed, and Fortune reported that the leak did not expose the model’s weights. BleepingComputer reports that Anthropic then began issuing DMCA notices against mirrors of the leaked source. A codename in a public comment proves only that the uploader read the news; anyone can name a repo after it.
On Mythos itself, when announcing Project Glasswing on 7 April 2026 Anthropic said: “We do not plan to make Claude Mythos Preview generally available”, and offered it only to a limited set of partner organizations. We found no public Anthropic statement about burner22/numbat, neither confirming nor denying. One more caution: a Hacker News commenter asked whether it is realistic for the repo to survive a week without a takedown; that is reader reasoning, not evidence. As of our reading on the morning of 2026-11-02 the repo was still public, and the discussion tab contains user-submitted “illegal or restricted content” report threads, but those are user actions and we cannot know what Hugging Face decides.
What the Community and Press Are Saying
| Source | What it says | Our status |
|---|---|---|
| HF discussion tab (23 threads) | #13 tensor regeneration; #19 same for NVFP4; #11 code review finds loader flaws; #14 active size makes serving unrealistic | Read, not reproduced |
| Hacker News | Thread is flagged; comments mostly say “not real” | Read |
| sysnote | Sampled norm weights, concluded “does not look trained” | Read, not reproduced |
| X | The few posts we read call it a fake leak | Small sample, not representative |
| Anthropic | No statement about this repo found | Searched |
What We Still Cannot Rule Out
Honestly, three things remain open. First, we did not read all 7.72 TB; the audits mostly cover normalization, convolution and part of the matrices, and if someone finds trained structure in the expert weights, the conclusion would need revising. Second, “fake” is our judgment from the current public evidence; we do not know who the uploader is or why they did it. Third, even a fake does not mean Anthropic has no such model, and it does not mean a real weight leak will never happen.
What This Means for Ordinary Readers
The practical advice is simple: do not download it, and above all do not load it with trust_remote_code=True. The repo’s own Python files execute at load time. We read modeling_numbat.py (543 lines) and configuration_numbat.py and saw only imports of torch, transformers and the standard-library math and typing modules, with no network, subprocess or file-write calls, but that is a spot check rather than an audit, and the repo can change after we looked. Even if everything is harmless, 7.72 TB is of no use to any personal computer. For what hardware a model at this scale needs, how to spot fake “leaked” repos, and the copyright and trade-secret risks, see the companion piece: what a 14T-parameter MoE needs, and how to spot fake leaked models. For the privacy side of running models yourself, see local LLMs and privacy, and for reading eval numbers critically, how to read LLM benchmarks.
What We Did and Did Not Do
We read the repo’s public API and a few small text files, read the config and custom code, counted the training-log tail, checked the AWS Neuron, Anthropic and Fortune public pages, and read public content from the HF discussion tab, Hacker News, sysnote and X. We did not download any weight shard, run any code, reproduce any audit, or contact Anthropic or the uploader. “Checked” here means “consistent with the public pages”, not “verified by us by hand”.
FAQ
Did Anthropic’s Mythos weights really leak to Hugging Face?
Nothing we found supports that. The repo and files are real, but nothing ties the data to Anthropic, and community audits report several signs of generated data. We lean towards fake, but we did not reproduce the audits ourselves.
Why does HF show 6.8T while the repo says 14T?
NVFP4 packs two 4-bit weights into one byte and HF counts bytes. Converted, it is about 13.68T, so the difference alone says nothing about authenticity.
The sizes and config all add up. Doesn’t that make it real?
No. Consistency only shows the maker was careful. A well-made fake can match every number, and generating data from tensor names is exactly how to do that.
Is numbat really an Anthropic codename?
Several sources quote a comment in the leaked Claude Code source to that effect, and we did not open the leaked source to verify. Even if true, it shows only that the uploader read the news.
Is the repo safe to download and try?
We do not recommend it. The two Python files we read showed no malicious calls, but loading it requires trust_remote_code=True, which runs the repo’s code, and the data is useless on personal hardware. The companion article lists safer checks.
Is it legal to download or share “leaked” weights?
If real, they could raise trade-secret and copyright issues that vary by jurisdiction. This is general information, not legal advice; consult a lawyer if you need it. We provide no download links.
Talk With Us
Have a question about a viral “leaked” or “modified” model, or want to share your own audit method? Join the community or email admin@microaione.com with the link and your question.
References: HF discussion #13 (tensor regeneration audit), Hacker News thread, sysnote analysis, Anthropic: Project Glasswing, Fortune on the Claude Code source leak, AWS Neuron: Trainium2 architecture. Data read on 2026-11-02, Beijing time.
Further reading: Fact-checking leaked and cracked model claims
