Which open-weight model to run when the release feed goes quiet

I checked the release trackers on the seventh of July looking for something new to run, and the live llm-stats feed had the same three-word verdict it has posted for the fourth week running: “No open source releases this week.” The freshest open-weight drops are still DiffusionGemma from the tenth of June and GLM-5.2 from mid-June. Nothing landed in the last three days.

For a few minutes that felt like a slow news week. Then it felt like a gift. An infra lead I know had spent the previous month rewriting a serving config every time a new model trended, and the quiet week was the first time in a while the question could be answered calmly. Not “what is the newest open-weight model,” but “which one actually fits what we have and what we need.” That question has a durable answer.

Nobody shipped an open-weight model this week, and that is the useful part

The release drought reframes the whole exercise. If a frontier open-weight model dropped every Tuesday, chasing the feed would be rational. It does not. The spring wave (DeepSeek V4 in April, Kimi K2.6, Mistral Medium 3.5, then the mid-June pair of Kimi K2.7 and GLM-5.2 per the fazm.ai running list) has given way to weeks of nothing new to self-host.

So the model a team runs in production this quarter is almost certainly a model that already exists today. That means the decision can be made properly, once, against criteria that hold. The teams that struggle are the ones treating model selection like a news subscription. The teams that do well treat it like picking a database: a deliberate choice, revisited only when something real changes.

What “open-weight model” actually means before you pick one

Here is the distinction that trips up half the selection conversations I sit in. Almost nothing at the top of the leaderboard is open source in the full sense. As Thunder Compute put it in its July guide: “Most models called ‘open source’ are really ‘open weight’: only the model weights are publicly available, but the training data and pipeline remain proprietary.”

That is not a complaint. It is the practical reality of what a team gets. Open weights mean the file can be downloaded, inspected, fine-tuned, and served on owned hardware. They do not mean the training recipe is public, they do not mean the license is unrestricted, and they very much do not mean the model is automatically free or automatically private. Someone asking what is an open-weight model is really asking three quieter questions underneath: can I run it, can I legally use it the way I plan to, and can I afford the hardware it wants. Answer those three and the choice mostly makes itself.

License first, because Apache and MIT are free and Llama’s growth clause is not

I put license before benchmarks on purpose, because a license problem is the one that surfaces after adoption, when it is expensive to unwind.

The clean picks are the unconditional ones. DeepSeek V4 ships under MIT. Qwen 3.5 and Google’s Gemma 4 ship under Apache 2.0. Mistral moved its entire 3 line to Apache 2.0 as a deliberate contrast to Meta’s approach. Under those licenses, commercial use, fine-tuning, and self-hosting are genuinely unrestricted, and legal review is a short conversation.

The custom licenses are where obligations hide. Llama’s community license carries a monthly-active-user threshold (the well-known 700M-MAU clause) that changes what is owed as a company scales. What is free at Series A can require a separate conversation at scale. None of this is scary if it is read early. An open-weight license was never the same as “do whatever you want,” and a legal team that has read a software license before will find this a Tuesday. The teams that get burned are the ones who assumed “open” meant free of obligations and never read past the headline.

An open-weight license is a spectrum, not a status. Read it before you build on the model, not after your MAU chart turns the corner.

VRAM fit second, because the 245GB model is not the model on your one card

This is where excitement meets the memory budget. The best open-weight model in the abstract is frequently a model no single box in the building can serve.

GLM-5.2 is the current open-weight benchmark leader, and it is genuinely impressive. It is also enormous. Thunder Compute’s July guide is blunt about the floor.

That is the two-bit version, the small one, and it still needs multiple datacenter GPUs. Meanwhile the models that fit a single card are a tier down in raw benchmark score and often exactly right for the task. Quantization to INT4 cuts memory roughly 50 to 75 percent: a 70B model that wants about 140GB at full precision fits near 35GB at four-bit. GPT-oss 120B runs on one H100. The DeepSeek-R1 distills fit a single 4090. The honest sizing rule is unglamorous: match the model to the VRAM already on hand, then check the leaderboard to see how much capability that tier buys.

Why teams pick the leaderboard winner and regret it

The failure pattern is consistent enough to name. A team reads that GLM-5.2 or Kimi K2.5 tops the open-weight charts, writes it into the plan, and only discovers at deployment that serving it needs an 8x H100 node the budget never approved. Then comes the scramble: a hasty two-bit quant, a quality regression nobody measured, and a quiet retreat to the API three weeks later.

The benchmark that sold the model was run at full precision on a cluster. The thing that ships is a heavily quantized version on whatever hardware survived procurement. Those are not the same model, and the gap shows up first in exactly the capability the benchmark did not isolate: tool-calling, long-horizon reasoning, the format discipline an agent depends on.

Run 30 to 50 of your own examples before you commit

Here is the whole playbook compressed into steps an infra lead can run this week, no new release required.

1. Write the license test first

   Confirm commercial use, output ownership, and any user or revenue threshold. Apache 2.0 and MIT pass instantly. A custom license gets a fifteen-minute legal read before anything else happens.

2. Size to the hardware already on hand

   Start from the VRAM in the building, not the top of the chart. Pick the largest model that fits at a quant you have tested, leaving 15 to 20 percent headroom for the KV cache.

3. Choose the quant on purpose

   Two-bit to fit a giant model onto a smaller box is a real decision with a real quality cost. Make it deliberately and only after the next step, never as a deployment-day panic move.

4. Run 30 to 50 of your own examples at the deploy precision

   Not MMLU. The actual task: the tool calls, the extractions, the agent loops that matter to the product. Score the quantized model you will really serve, on the work it will really do.

5. Decide, then leave it alone

   Once a model passes the license, hardware, and task tests, commit and stop watching the feed. Revisit only when something concrete changes: a new release that clears the same three gates, or a shift in your own workload.

The quiet week turned out to be the honest one. When no new open-weight model is competing for attention, the decision reduces to what it always was underneath: a license a team can live with, a memory footprint a team can serve, and a task a team has actually measured. The leaderboard is a fine tiebreaker between two models that already passed those three. It was never meant to be the first question, and on a week like this one, it is a relief to be reminded of that.