Open Weight Model Flood June 2026: What Held Up Five Months Later

In June 2026 the story going around was that open weights had caught the closed frontier in a fortnight. Five months later, that story needs surgery. The open weight model flood June headline was real but mis-dated: the wave ran from April to June, not two weeks. Only a couple of the models people lumped together shipped in June at all. And the benchmark that anchored the claim has since been rebuilt, with the open-versus-closed gap now measured as wider, not narrower.

This matters because budgets and architectures were set on the first version of the story. If you routed traffic, signed a renewal or bought GPUs on the belief that open models were three points behind, you should re-check the premise. The useful lesson is not “open won” or “open lost”. It is how to read a leaderboard, price a token and read a licence.

You leave with a corrected timeline, the mechanisms behind the burst, a worked cost model with stated assumptions, a licence taxonomy, and a decision procedure you can run against your own workload.

What this covers: the verified timeline, why it happened, what the index actually said, API versus self-host economics, the licence layer, failure modes, and a checklist.

Context and Background

Through 2024 and most of 2025 the working assumption in enterprise AI was simple. The best models were closed, you rented them per token, and open weights trailed by a generation. Open models were for prototypes, privacy-sensitive niches and research. That assumption began to crack in early 2025 and, by spring 2026, looked shaky for a growing slice of tasks.

The vocabulary matters here. An open-weight model publishes its trained parameters so anyone can download and run it, usually with a licence that restricts some uses. That is different from open source in the Open Source Initiative sense, which also expects training data information and code under an approved licence. Most of what shipped in 2026 is open-weight, not open source, and several licences add commercial conditions. We return to this in the licensing section.

The players are a short list. Z.ai (the lab behind the GLM series), DeepSeek, Moonshot AI (Kimi), MiniMax, Alibaba’s Qwen team and Xiaomi’s MiMo team ship large mixture-of-experts (MoE) models, most with weights on Hugging Face. On the closed side sit OpenAI, Anthropic and Google, whose flagships still top most aggregate rankings. For background on why MoE is the enabling design, see our explainer on MoE routing, top-k gating and load balancing.

The most influential single data point was the Artificial Analysis Intelligence Index, an aggregate of many evaluations. At the time of the June launches, version 4.1 of that index put Z.ai’s GLM-5.2 at 51, the highest of any open-weight model, with MiniMax M3 and DeepSeek V4 Pro (max effort) both at 44 and Kimi K2.6 at 43, as reported by Simon Willison and Implicator. Willison called it probably the most powerful text-only open-weights model yet shipped. That is a careful sentence, and it is worth reading slowly: “text-only” and “open-weights” are both load-bearing qualifiers.

Our earlier GLM-5.2 benchmark analysis covers that single model in depth. This post is about the wider pattern, and about what a November reader can say with confidence that a June reader could not.

What the first version of this post got wrong

The original June write-up described “roughly a dozen” frontier and near-frontier open models arriving in the first two weeks of June, and placed DeepSeek V4.1 and Qwen 3.7 inside that window. Checking primary and secondary sources, that framing does not hold:

DeepSeek V4 (Pro and Flash) was released on 24 April 2026 under the MIT licence, per a Codersera comparison. The V4.1 line arrived later, in September.
Qwen 3.7 Max appeared around 19 May and is proprietary and API-only. It was never an open-weight release.
Kimi K2.6 and Xiaomi’s MiMo V2.5 Pro were already in the open-weight cohort by the end of April, per Artificial Analysis.
In June proper, the clear open-weight events were MiniMax M3 (announced 1 June, weights promised within about ten days) and GLM-5.2 (coding-plan access 13 June, MIT weights 16 June).

So the honest description is a spring wave with a June crest, not a two-week flood. That correction changes the causal story, which is why the rest of this post rebuilds it.

The Verified Timeline and Why It Happened

Short answer: the “June flood” was a roughly eight-week cluster of releases from April to June 2026, produced by four converging forces: sparse MoE efficiency, a deliberate open-weights strategy at several Chinese labs, cheap distillation of frontier behaviour, and amortised training clusters. June’s crest was GLM-5.2 on 16 June.

Figure 1: The open-weight wave as best verified, April to November 2026. Items marked in the text as vendor-reported or unconfirmed should be treated accordingly.

Figure 1 lays out the sequence. The dated anchors, with their sourcing, are below.

Date (2026)	Event	Source quality
Late April	Kimi K2.6 (1T total, 32B active) and MiMo V2.5 Pro (1T, 42B active) in the open cohort	Artificial Analysis article, April 30
24 April	DeepSeek V4 Pro (1.6T total, ~49B active) and Flash (284B, ~13B active), MIT	Secondary comparison
~19 May	Qwen 3.7 Max, proprietary API only	Secondary comparison
1 June	MiniMax M3 announced, 1M context, SWE-Bench Pro 59.0 percent vendor-reported	Launch coverage
13 and 16 June	GLM-5.2 to subscribers, then MIT weights	Simon Willison
July to October	Kimi K3, Qwen3.8, GLM-5.3, DeepSeek V4.1	Secondary roundups

The first thing to notice is that the table contradicts the “two-week” framing without contradicting the more important claim. Several near-frontier open models did land within a single quarter. The compression was real. The date range was wrong.

Force one: sparse MoE made frontier size servable

GLM-5.2 is a mixture-of-experts model with roughly 753 billion total parameters on its Hugging Face card (Artificial Analysis quotes 744 billion; treat the difference as a counting convention, not a contradiction) and about 40 billion active per token. The weights occupy about 1.51 TB, per Willison. Only about 5 percent of parameters participate in any one forward pass.

That ratio is the whole economic trick. Capability tracks, loosely, with total parameters, because experts store knowledge. Per-token compute tracks with active parameters. You still pay in memory and interconnect to hold every expert, but you do not pay in floating-point operations for the ones the router skips. DeepSeek V4 Pro follows the same pattern at larger scale: 1.6 trillion total, around 49 billion active.

The same logic applied at training time. A lab can add experts to grow capacity without a proportional rise in training compute per token. When the architecture lowers the cost of a better checkpoint for everyone, several labs reaching the frontier in the same quarter is the expected outcome, not a coincidence.

Force two: open weights as a deliberate strategy

A lab that struggles to sell a closed API into Western enterprise channels, for regulatory, trust or procurement reasons, can still win mindshare by being the default substrate developers build on. Permissive licences are the lever. DeepSeek and Z.ai shipped under MIT. That is positioning, not charity, and it explains why the wave concentrated in a handful of labs with similar incentives.

The corollary is that the strategy is conditional. When a lab’s position changes, the licence tightens. We see exactly that in the later releases covered below.

Force three: distillation and the cost of the follower

Finding a capability is expensive: data curation, reinforcement-learning recipes, reasoning traces. Reproducing observable behaviour in a smaller or cheaper model is far cheaper. This is why the gap between leader and pack tends to compress rather than widen in any given quarter. The frontier moves, but the price of chasing it falls relative to the price of setting it.

I want to be careful: the extent to which any specific open model was distilled from a specific closed one is rarely disclosed, and some of the public allegations are contested. Treat distillation here as a structural force, not an accusation about a particular lab.

Force four: amortised compute

Training clusters bought in 2024 and 2025 are sunk cost by 2026. The marginal cost of one more serious run is lower than the first run was. Combined with cheaper capability transfer, shipping a near-frontier model becomes a recurring line item for well-capitalised labs rather than a once-a-generation bet.

Figure 2: The four forces behind the 2026 open-weight wave and the downstream effects each one produces.

Figure 2 draws the causal map. The point of drawing it is to separate causes that persist (MoE economics, amortisation) from causes that are contingent (a particular lab’s strategic bet), because the persistent ones predict what happens next.

What the Index Actually Said, and What Changed

The June claim was “open weights are three points from the top”. Both halves of that sentence have aged badly, and the reason is instructive for anyone who reads leaderboards for a living.

The scale moved under the claim

Artificial Analysis published version 5 of its Intelligence Index on 27 October 2026, per Layer3 Labs’ summary. Version 5 is a weighted average of nine evaluations in four categories, with about 60 percent relying on private or held-out test sets. It adds two benchmarks, upgrades three, retains four and removes three. Artificial Analysis states that v5 scores should not be compared with v4 scores, because the evaluations changed.

That single statement undermines most comparisons floating around in secondary coverage. The same open models appear at 43 to 54 in one index version and in the low 30s in another. Kimi K2.6 is quoted at 43 on v4.1 and 54 in an April article on an earlier version. DeepSeek V4.1 Flash is quoted at 32 on v5. None of those numbers is wrong; they are on different rulers.

The headline for open weights is the one in the v5 write-up. Among models with released weights, DeepSeek V4.1 Flash and GLM-5.3 lead at 32, while a closed model (Claude Opus 5.5) tops the table at 58. The summary says the gap between open-weight models and the leader grew from 3 points in v4.3 to 12 in v5. I have not independently reproduced those figures; they come from a single secondary summary and should be checked on the live page before you quote them.

Why would the gap widen when the evaluations got harder and more private? Two plausible mechanisms, both labelled as my interpretation rather than reported fact. Public benchmarks are easy to train toward, so a model with strong recipes can look better on public sets than on held-out ones. And agentic, long-horizon tasks reward the heavy post-training and tool-use data that the best closed labs invest in. An aggregate that shifts weight toward private tasks will expose both effects.

The correct reading of “frontier-adjacent”

None of this means the June claim was empty. GLM-5.2 really did score 51 on v4.1, ahead of every other open model, and it really did post strong vendor-reported coding numbers: SWE-bench Pro 62.1 and Terminal-Bench 2.1 at 81.0, both Z.ai-reported, and an Artificial Analysis GDPval-AA v2 score of 1,524 against 1,514 for GPT-5.5 at its highest setting (as relayed by Implicator). Willison also reported it ranked second on the Code Arena WebDev leaderboard behind one closed model.

But the same sources show where it lagged. On SWE-Marathon, a long-horizon task suite, Z.ai’s own table gave GLM-5.2 13.0 against 26.0 for Claude Opus 4.8. On FrontierSWE the numbers were close: 74.4 versus 75.1. The pattern is consistent across the data: open weights are near parity on bounded tasks and fall behind as horizon length grows. That pattern is the real finding, and it is one a single aggregate hides.

Token appetite is part of the price

Here is a detail most summaries buried. GLM-5.2 used about 43,000 output tokens per Intelligence Index task, of which roughly 37,000 were reasoning tokens, against 26,000 for its predecessor and 37,000 for DeepSeek V4 Pro at max effort. Implicator reports the cost to run an index task was about $0.46 for GLM-5.2 against about $0.05 for DeepSeek V4 Pro at its maximum setting, a roughly nine-fold gap on the same benchmark.

Do the arithmetic yourself with list prices. GLM-5.2 charges $4.40 per million output tokens; 43,000 tokens is $0.19 of output cost per task. DeepSeek V4 Pro lists $0.87 per million output tokens; 37,000 tokens is about $0.03. Output tokens alone explain a six-fold difference, before input and caching, which the reported nine-fold gap includes. The lesson is that price per token is not price per task. A cheaper-looking model that thinks twice as long can cost more, and a model that thinks longer is slower to return an answer.

Figure 3: A decision flow for routing a workload between a closed API, a third-party hosted open-weight API and self-hosting. The deciding variables are volume, utilisation and data-boundary requirements.

The Cost Collapse: Per-Token Prices, Per-Task Costs and the Self-Host Crossover

The cost side of the flood is the part that has held up best. Frontier-class capability at one-fifth to one-seventh of the closed price per token is a durable change, even if the capability gap is wider than advertised.

List prices, as reported

From OpenRouter listings quoted by Willison in June, most of the nine providers hosting GLM-5.2 charged about $1.40 per million input tokens and $4.40 per million output. For comparison, the same note lists GPT-5.5 at $5 input and $30 output, and Claude Opus 4.5 to 4.8 at $5 input and $25 output. By division, GLM-5.2 is about 3.6 times cheaper on input and between 5.7 and 6.8 times cheaper on output. The “one-sixth” figure in the original post is the output-token ratio, and it flatters the open model for workloads dominated by long prompts.

MiniMax M3 launched at a $0.60 input and $2.40 output list price with a first-week half-price discount. A later summary from Digital Applied says the $0.30 and $1.20 tier became permanent for prompts up to 512K tokens, with $0.60 and $2.40 beyond that. DeepSeek V4 Pro listed at $0.435 input and $0.87 output. Treat all of these as moving targets: promotional prices, regional endpoint differences and cache discounts change monthly.

A worked self-host crossover (illustrative)

The following model uses assumptions I state explicitly. They are not measured prices.

Assumption A: an eight-GPU node suitable for a large MoE costs $30 per hour all-in, including power and amortised hardware or rental. That is $21,600 for a 720-hour month.
Assumption B: the alternative is a hosted API at Artificial Analysis’s blended GLM-5.2 rate of $0.90 per million tokens, which uses a 7:2:1 cache-hit, input, output mix.
Break-even tokens per month: 21,600 divided by $0.90 per million is 24,000 million, or 24 billion tokens.
That is about 800 million tokens per day, or roughly 9,300 tokens per second sustained around the clock.

Below that volume, or at low utilisation, the API wins because you never pay for idle accelerators. Above it, the node wins, provided it can really sustain that throughput. Whether an eight-GPU node does depends on batch size, context length and the serving stack, and I have no measured number I would defend. Run a load test on your own prompts before committing. Add the engineering cost of an on-call rotation for inference, which this arithmetic omits.

For the serving layer itself, our guide to tensor, expert and data parallelism for MoE serving explains why expert parallelism changes the hardware shape, and the offline batch inference piece covers the case where throughput, not latency, is the goal.

Memory arithmetic for the weights

Storage is where MoE bites. At 16-bit precision 753 billion parameters occupy about 1.5 TB, matching the 1.51 TB figure. Halving precision to 8-bit gives about 750 GB, and 4-bit about 380 GB. Those are weights only, from straightforward multiplication; KV cache for a one-million-token context adds substantially more and varies by attention design. Z.ai says an indexer-sharing scheme (IndexShare) cuts per-token compute by 2.9 times at 1M context, a vendor claim I have not verified.

The practical consequence: a “self-hostable” frontier model usually means a multi-GPU node at minimum, and for the largest releases a multi-node deployment. Moonshot’s guidance for Kimi K3 reportedly calls for 64 or more accelerators, per the same roundup that reports its size. That is self-hostable for a cloud or a large enterprise, not for a laptop or a single workstation.

The third regime: hosted open weights

Between “call a closed API” and “buy GPUs” sits a third option that the flood made real: third-party inference providers serving the same open weights. Fireworks, Baseten and DeepInfra were named as hosts for GLM-5.2 in the days after release. Competition between hosts pushes prices toward marginal cost, and switching hosts is cheap because the model is the same. You keep API ergonomics and gain portability.

For many teams this is the sweet spot. It captures most of the price advantage, leaves the operational burden with someone else, and removes single-vendor lock-in on the model itself. The trade is data residency: your prompts transit a third party, which may be an unacceptable condition for regulated data. A gateway that routes between providers helps; see our comparison of LLM gateways for routing, fallback and budgets.

Where the Moat Went: Licences, Later Waves and Strategy

If raw quality gap shrinks on bounded tasks, defensibility moves. If the gap grows on long-horizon tasks, it moves back. Five months of evidence shows both happening at once, which is why a single-sentence strategy (“open will win” or “closed will win”) is unreliable.

The licence layer got stricter, not looser

“Open weight” is not one legal status. The June cohort was mostly permissive: GLM-5.2 and DeepSeek V4 under MIT. The later cohort is more varied, as summarised by Slash Digital’s survey, whose licence descriptions I have not checked against the original texts:

Model	Reported licence shape	Practical meaning
DeepSeek V4.1 Flash (Sept)	MIT	No usage conditions beyond attribution and notice
Qwen3.8 27B (Aug)	Apache 2.0	Permissive, with an explicit patent grant
Qwen3.8 flagship (Aug)	Custom, display rule and separate licence above a revenue threshold	Read before building a hosted product
Kimi K3 (July)	Custom, name-display conditions above user or revenue thresholds	Fine for most internal use, restrictive for large resellers
Qwen 3.7 Max	Proprietary, API only	Not open weight at all

The pattern is that the largest flagships carry custom licences with commercial thresholds, while smaller models stay permissive. That is rational for the labs: the big models are where resale revenue sits. For a buyer, the consequence is that “it’s on Hugging Face” no longer implies “I can embed it in a product I sell”. Have counsel read the actual licence file, and record the commit hash of the weights you adopted. Our piece on AI model supply chain security and provenance covers the documentation trail.

Weights can be held back

Two episodes show that “open” is a decision made per release, not a property of a lab. Z.ai released GLM-5.3 on 14 August as a post-training upgrade to the GLM-5.2 base, but said weights would follow after safety evaluation and hardening, expected about two weeks later, per DataNorth. The Layer3 summary of the v5 index lists GLM-5.3 among models with released weights, so the delay appears to have been resolved; I did not locate the primary release note, so treat the exact weight-release date as unconfirmed.

Moonshot released Kimi K3.1 Pro by API on 23 October and promised weights for 4 November. As of the survey I read, no weights or licence were published, and Artificial Analysis lists it among models without released weights at v5 launch. I could not confirm whether the 4 November date held.

MiniMax M3 is the cleaner cautionary tale for the June cohort. It was announced on 1 June with weights promised within about ten days, but sources I could reach did not confirm the release, its licence or its parameter count. One guide asserts 428 billion total and 23 billion active parameters; MiniMax had not disclosed these at launch, so I treat that figure as unverified. A model announced as “open” is not an open model until the weights are downloadable under a licence you have read.

Strategy: what to do with a moving gap

The original post borrowed a PostgreSQL-versus-Oracle analogy. The analogy is half right. Commodity engines did migrate value to the layers above them. But databases did not have a measured, widening gap on the hardest workloads. A better analogy for November 2026 is a market splitting into tiers: a commodity tier where open models are good enough and cheap, and a frontier tier where closed labs retain a measurable lead on long-horizon agentic work.

That split implies a portfolio, not a bet. Send high-volume, bounded, well-evaluated tasks to open models. Reserve closed frontier models for the hard tail where a few points of capability change outcomes. Keep an evaluated open fallback for every closed dependency so that a repricing or deprecation is an inconvenience, not an outage. Model continuity is an underrated benefit: a checkpoint you hold cannot be silently re-tuned or withdrawn, which matters for audited workloads.

Where does durable advantage sit? In product and workflow integration, in distribution, in proprietary data no open checkpoint encodes, and in evaluation harnesses that tell you when a model regresses. The last one is the cheapest to build and the most neglected. For a framework view, see our evaluation harness architecture guide.

Walk-through: Evaluating an Open-Weight Model for Your Workload

Leaderboards are the wrong unit of decision. The procedure below turns the lessons above into something you can run in a week.

Figure 4: Shadow evaluation. Production prompts go to the incumbent, a copy goes to the open-weight candidate, and a grader compares per-task quality, tokens and cost.

Step 1: build a frozen, private eval set

Sample 200 to 500 real prompts from production logs, strip sensitive data, and write graded expectations or rubric checks. Keep them private. A public set will flatter any model that has seen it, which is the contamination problem that pushed the index maintainers toward private questions in the first place.

Stratify by horizon. Include short single-step tasks and long multi-step agent runs. The June data suggests the open-versus-closed gap sits in the second group, and an average over both would hide it.

Step 2: measure cost per completed task

Record input tokens, output tokens, reasoning tokens, retries, wall-clock time and pass rate. Divide total spend by passes, not by calls. A model that fails 30 percent of the time and retries is more expensive than its list price suggests. Reasoning-heavy models need a cap on thinking budget, or latency and spend will drift.

Step 3: run shadow traffic

Mirror a slice of live requests to the candidate without returning its output to users. Grade with a mix of automated checks and a stronger judge model, then audit a sample by hand. Look for the regressions that matter: formatting breaks, tool-call schema errors, refusals on legitimate requests, and a higher hallucination rate. The April Artificial Analysis note, for example, flagged DeepSeek V4 Pro with a notably higher hallucination profile than its open peers on the AA-Omniscience measure. That is exactly the kind of property an aggregate score hides.

Step 4: decide per route, not per company

Create routes: classification, extraction, drafting, code review, agent loops. Assign each to the cheapest model that clears its quality bar with margin. Revisit quarterly, because this field changes within a quarter, as the last five months proved.

A minimal routing sketch

The snippet below shows the shape of a per-route policy in a gateway. It is configuration illustration, not tied to a specific product.

routes:
  extract-invoice-fields:
    primary: hosted-open/glm-5.2
    fallback: closed/frontier-small
    max_output_tokens: 2000
    min_eval_pass: 0.96
  agent-code-fix:
    primary: closed/frontier-large
    fallback: hosted-open/glm-5.3
    max_output_tokens: 32000
    min_eval_pass: 0.85
policy:
  record_weights_commit: true
  block_if_licence_changed: true

The two policy flags encode lessons from above: pin which weights you ran, and fail closed if a licence changes between versions.

Trade-offs, Gotchas, and What Goes Wrong

The honest failure modes are less glamorous than the benchmarks.

Index drift. Any claim of the form “model X scores N” is only meaningful with the index version. The same models read 43 to 54 or low 30s depending on version. Quote the version or do not quote the number.

Vendor-reported benchmarks. Many of the strongest figures in this story, including SWE-bench Pro, Terminal-Bench and CyberGym results, are reported by the model authors using their own harnesses. They are directional. Independent results exist for some, such as Artificial Analysis GDPval-AA and Arena rankings, and are preferable.

Token hunger. Reasoning-heavy open models can consume two to four times the output tokens of leaner peers, erasing a per-token price advantage. Always compare cost per completed task.

Self-host underutilisation. Idle accelerators are the silent killer of the self-host case. Spiky traffic, a single tenant and a need for low latency at low volume all push toward an API.

Operational burden. You inherit patching, security review, driver and kernel upgrades, and incident response for the serving stack. New attention variants may need specific versions of serving frameworks; one deployment guide for MiniMax M3 tells readers to confirm that vLLM or SGLang release notes include support for its sparse-attention design before installing. Check before you plan a rollout around a release-day model.

Geopolitical and compliance exposure. Most of the strongest open weights come from Chinese labs. Some organisations, particularly in government, defence and certain regulated sectors, have policies restricting their use regardless of licence. This is a policy question, not a technical one, and it can invalidate the whole open-weight plan for a given buyer. Check it first, not last.

Safety and provenance. Downloading a large checkpoint and running custom inference code is a supply-chain action. Verify hashes, prefer safetensors over pickled formats, and review any custom code a model repository requires.

Frozen model risk. Pinning a version protects reproducibility but means you own its known flaws indefinitely. Decide who monitors for newly discovered jailbreaks.

Practical Recommendations

Treat the flood as a change in your option set, not as a conclusion. You now have credible open candidates for the commodity tier of your workload, and a measurable, possibly growing, gap on the hardest tail. Act accordingly.

Start with data you control. If you do not already have a private eval set, build one before you evaluate anything else; every other decision depends on it. Then price by completed task, not by token. Choose hosting by volume and data boundary: hosted open weights for most teams, self-hosting only when utilisation is high and steady or the data cannot leave your boundary, closed APIs for the hard tail.

Treat licences and provenance as engineering inputs. Record which weights, from which commit, under which licence text, you deployed. Keep a fallback for every route so that a repricing, a withdrawn weight release or a licence change is survivable.

Build a private, stratified eval set of 200 to 500 prompts, including long-horizon cases.
Always cite the index version when quoting a leaderboard score.
Compare cost per completed task, including reasoning tokens and retries.
Model the self-host break-even with your own throughput measurement.
Read the actual licence file and pin the weights commit hash.
Confirm weights are downloadable before planning around an announced release.
Check regulatory and procurement policy on model origin before building.
Review the routing table quarterly.

Frequently Asked Questions

What was the June 2026 open-weight model flood?

It refers to a cluster of near-frontier open-weight releases around mid-2026, led by GLM-5.2 on 16 June under an MIT licence and MiniMax M3 announced on 1 June. Checking dates shows the wave actually began in April with DeepSeek V4, Kimi K2.6 and MiMo V2.5 Pro, so it was a roughly eight-week spring cluster rather than a two-week burst. Qwen 3.7 Max, often included, was proprietary.

Did open-weight models actually match closed models?

On bounded tasks, nearly. On the Artificial Analysis v4.1 index GLM-5.2 scored 51, the best open score, and it was close to closed models on some coding tasks. On long-horizon work it lagged, for example 13.0 versus 26.0 on SWE-Marathon in Z.ai’s own table. After the index was rebuilt in October as v5, the reported open-versus-closed gap widened from 3 to 12 points.

Is it cheaper to self-host an open-weight model than to use an API?

Only above a break-even volume and with high utilisation. In an illustrative model with a $30 per hour eight-GPU node against a $0.90 per million token API, break-even is about 24 billion tokens a month. Below that, hosted APIs usually win. Hosted open weights from third-party providers often capture most of the saving without the operations burden.

Are open-weight models free to use commercially?

Not always. DeepSeek V4 and GLM-5.2 were released under MIT, which is permissive. Several later flagship models reportedly use custom licences with display or revenue-threshold conditions, and some models promoted as open are API-only. Always read the actual licence file for the exact weights you plan to use, and consult counsel before embedding a model in a product you sell.

Why do the same models have different Intelligence Index scores?

Because the index changed. Artificial Analysis published version 5 on 27 October 2026 with new and removed evaluations and about 60 percent private test data, and states that v5 scores should not be compared with v4. A model at 51 on v4.1 and a model at 32 on v5 are not necessarily weaker or stronger; they sit on different scales. Always quote the version.

Which open-weight model should I pick?

None by default. Pick per workload using a private evaluation set and cost per completed task. GLM-5.2 and its successor GLM-5.3 suit agentic coding, DeepSeek V4 variants suit cost-sensitive volume, and Qwen3.8 27B suits smaller deployments under Apache 2.0, based on vendor and secondary reports. Your own evaluation overrides any of these generalisations.