Open weights, closed recipes: what four reports say about the models you can actually download

The open-weight argument has always rested on a promise: you get the file, so you get control. Four documents published between May and September 2026 test how much of that promise survives contact with measurement. They do not agree on much. They do agree that "open" is doing less work than the headlines assume.

The four-month number and what it hides

Mozilla published version 1.1 of its State of Open Source AI report on 15 September, using data current to 1 September, according to Tom's Hardware. The headline finding: the best open model trailed the closed leader on the Artificial Analysis Intelligence Index by three points at 60% of the price. It sat two points behind Claude Fable 5 at 30% of the price. Mozilla's fit on METR task-horizon data puts the open-closed gap at around 4.4 months, in line with Epoch AI's four-month estimate.

METR scores models by the length of task, measured in human working time, that they complete half the time. By Mozilla's fitted estimate, closed models handle tasks taking human experts 8 to 12 hours. Open models reach that roughly four months later. Open capability doubles every 3.9 months, against 5.5 for closed, by Mozilla's computation. Tom's Hardware notes a caveat Mozilla itself carries: the four-month figure and the 30% token price are measured API to API on hosted endpoints, at list price.

The hardware chart is the uncomfortable one

The same report includes a chart that sits awkwardly beside the headline. The best open model that fits on one server scores 52.6. The best that fits on one GPU scores 40. The drop from the top is 10 and 23 points respectively. That is a larger gap than four months of capability progress.

Kimi K3's native MXFP4 checkpoint runs about 1.56TB across 96 shards. Mozilla's serving configuration lists 64 or more accelerators. vLLM calls for at least eight GB300 GPUs, with multiple nodes for production traffic. The report's own phrasing is that this is open but not runnable by most who hold it. Tom's Hardware put the memory need near 1.5TB in July. There are exceptions. Thinking Machines' Inkling-Small, under the Apache 2.0 license, has an NVFP4 version that fits one B300 at a 180GB floor. That is a real datapoint, and it is one model.

Open weights are not open source, and the difference is load-bearing

The Open Source Initiative made the distinction explicit in a 19 September post. AI models have three main components: training data, weights and parameters, and the code used for data preparation and training. Open-weight releases publish the weights. They do not publish the rest.

Open-weights allow you to exercise some freedoms, but not all, and only to a certain degree. True Open Source AI allows you to exercise all four without restriction.

The four freedoms in question are use, study, modify and share without asking permission from the rights holder. The OSI puts the demand-side value of the Open Source ecosystem at $8.8 trillion. It argues that open-weight models limit modification and prevent full study. Without code and training data, you cannot inspect why a model produced an output. Mozilla's report, per Tom's Hardware, counts 16 notable open releases. None delivers the data recipe required by the Open Source Initiative's definition.

What memorization research adds to the copyright fights

A paper on arXiv, first submitted 18 May 2025 and revised through 20 July 2026, measures how much of 200 books 14 open-weight LLMs actually retain. The authors are A. Feder Cooper, Mark A. Lemley, Allison Casasola, Ahmed Ahmed, Aaron Gokaslan, Amy B. Cyphert, Christopher De Sa, Daniel E. Ho and Percy Liang.

Their framing is pointed. Plaintiffs and defendants in generative AI copyright suits make sweeping, opposing claims about memorization. Both positions, the paper says, dramatically oversimplify the relationship between memorization and copyright. Across more than 3000 experiments, the authors find that most LLMs do not memorize most books, either whole or in part. But the exceptions matter. Llama 3.1 70B entirely memorizes some books, including Harry Potter and the Sorcerer's Stone, according to the paper. Memorization there is extensive enough that the whole book can be deterministically extracted almost verbatim using its first few words as a prompt. The authors state that the results have significant implications for copyright cases, though not ones that unambiguously favor either side.

The smaller, stranger deployments

Not every open-weight release is chasing the frontier. Superwhisper published S1-mini, a 0.6B-parameter text normalizer fine-tuned from Qwen/Qwen3-0.6B, under Apache 2.0 plus a naming clause. It does one job: rewrite raw speech-to-text output as clean written text. On a held-out set of 7,519 English cases, it reaches 94.8% token accuracy. The quantized build is a 462 MiB file that runs on a laptop CPU. The model card is blunt that it is not a chat model and will not follow general instructions.

The model card also documents a Hub accounting quirk. The sidebar reports 0.8B parameters because the 155.6M-parameter embedding is counted twice. This gives 751.6M tensor elements against 596.0M unique parameters. The layout is inherited from Qwen3-0.6B, which reports 0.8B on the Hub for the same reason.

One buyer's reasoning, and its limits

A deployment write-up by James Cruce, published 22 September, describes choosing Laya, a 421M-parameter open-weight decision model with a ModernBERT-large encoder and a 1,024-token limit, over TypeSafe's hosted Jev service. Laya's publisher trained it on four synthetic workflows: agent observability, customer service, invoice processing and security incidents.

Cruce is explicit about what the comparison proves. TypeSafe lists Jev at $0.042 per million input tokens with no output-token charge and choices of up to 255 options. Laya runs on a loopback-only API on his Mac Studio with an M3 Ultra and 256 GB of unified memory. Routine decisions never leave the machine. He states plainly that privacy and control were the decisive reasons. Cost was a side effect, with no savings number to give. He did not test whether Laya beats Jev in general.

He also flags that the model card warns Laya is overconfident and needs domain-specific calibration. A typed answer can be structurally perfect and factually wrong. His conclusion is narrow: treat it as a recommender inside a program, never as a source of permission or truth.

What holds up

The four documents point in the same direction without saying the same thing. Mozilla's data says open weights are close on capability and far cheaper on hosted list price. Its own hardware chart says the models at the top are not something most people can run. The OSI says the label is being stretched past what it means. The memorization paper says the courtroom arguments on both sides are too broad for what the experiments show. Cruce's account says the decisive reason to pick open weights may be control over where the data goes, not benchmark position.

Mozilla's own chart caption reads: "the gap resets every release cycle." Its data stops at 1 September, and the live boards have moved since. Artificial Analysis has shifted to index v4.3 with a different evaluation set. The live board has Claude Fable 5.1 at 53 on its highest effort setting, with Kimi K3 at 44. vals.ai's Terminal-Bench 2.1 board, updated 11 September, is led by GPT-6 Astra at 87.27%, with Fable 5.1 at 85.02%.

One further item sits unresolved in the record. K3 carries an allegation detailed in the 8 September NSA/CISA/FBI joint advisory AA26-251A. Mozilla's report states it as "asserted, and unshown": that Moonshot extracted Claude Fable 5 data to train K3 through distillation. On 17 July, Artificial Analysis had K3 at 57 against Fable 5's 60. On 1 September, Mozilla had it two points back. Whether that narrowing came from independent training or from the alleged extraction is not something any of these four documents establishes.