Open weights went frontier-class this summer — read the licence before you plan on it

On 27 July 2026, Moonshot AI published the full weights of Kimi K3: 2.8 trillion parameters, 104 billion of them active, a 1,048,576-token context window, free to download. It is the largest open-weight model ever released publicly.

It was not an isolated event. Within the following month Alibaba opened the weights of Qwen3.8-27B — the first time a Max-class Qwen generation has been made self-hostable at all. Zhipu open-sourced GLM-5.3 roughly two weeks after its API release, then shipped GLM-5.3-Flash as an open-weight model outright. IBM released the Granite 4.2 family — 3B, 8B and 30B — under Apache 2.0.

For anyone who has spent two years being told that serious capability only comes from an API, the summer of 2026 is the moment that stopped being true. Which makes it exactly the moment to read the licences carefully, because "open" is now doing a great deal of load-bearing work in press releases where it does not belong.

"Open weights" is not "open source"

Kimi K3 is released under the bespoke Kimi K3 License. You can download it, run it, and self-host it. It is not OSI open source, and the difference is not academic — bespoke model licences routinely carry field-of-use restrictions, redistribution limits, branding requirements or scale thresholds that only become visible when your deployment succeeds.

Compare that with IBM's Granite 4.2, which is genuinely Apache 2.0. No usage ceiling, no field-of-use carve-out, no clause that activates when you cross a revenue line. Between those two poles sit most of this summer's releases: downloadable, capable, and governed by a document your legal team has never seen before.

Three questions settle it, and all three should be answered before an architecture depends on the answer:

1. Can we redistribute it? Shipping a model inside a product you sell is a different act from running it internally, and many model licences treat it that way.
2. Are there usage or scale conditions? Some licences change at a headcount, revenue or user threshold — the point at which you can least afford to move.
3. Who indemnifies us? With an API vendor there is usually someone. With weights you downloaded, there is usually nobody.

What self-hosting actually buys you

Set the licensing aside and the case for running your own weights is stronger this summer than it has ever been. Four things you get that an API cannot offer:

Data residency that is a fact rather than a contract term. For regulated buyers — health, legal, defence, public sector — "the data never left our network" is categorically different from "the vendor agreed not to train on it".

Price certainty. DeepSeek's move to peak/off-peak pricing in August is a reminder that API economics are the vendor's to change. A model on your own hardware has a cost curve you control.

Immunity from deprecation. API models get retired on the provider's schedule. Weights on your disk do not. If you have built a validated, audited workflow around specific model behaviour, that stability may be worth more than the next capability increment.

Auditability. You can inspect, freeze and reproduce exactly what ran.

And four things it costs you, which vendors of open models are less voluble about: inference operations become your problem; you own the evaluation harness that tells you the model still works after every change; security review of downloaded weights is a real exercise; and the total cost of ownership at low utilisation is frequently worse than the API you were trying to escape. A GPU idling overnight bills you regardless.

The small-model story is the one to watch

The Kimi K3 headline is 2.8 trillion parameters. The more useful number this summer is 47.67 — Granite 4.2 8B's score on SWE-bench Verified.

An 8-billion-parameter model under Apache 2.0, scoring in the high forties on real GitHub issue resolution, with a 512K context and native tool calling, fits where a 30B does not: on modest hardware, inside a regulated boundary, at a cost that survives contact with a finance review. IBM's family also carries a thinking switch — one checkpoint that either reasons step by step or answers directly — so a team does not deploy and pay for two models to cover both paths.

Most organisations do not need a frontier model. They need a competent model they can put somewhere specific, and the economics of that just improved considerably more than the economics of the frontier did.

A footnote that is not a footnote

Zhipu's GLM-5.3-Flash was revealed in late August as the model that had been circulating under the code name "Ox Alpha". The claim attached to it: the system ran entirely on a cluster of 100,000 domestically produced Chinese chips.

Treat that as a supply-chain data point rather than a benchmark. For a buyer building a multi-year AI dependency, the question of whether frontier-adjacent capability can be produced outside the Nvidia supply chain is a genuine input into concentration risk — and this summer produced the first strong evidence that it can.

How to decide

The honest answer for most teams is a split, not a choice.

Use an API for the frontier tier, where the capability gap is real and the price just fell. Self-host a small open model for the high-volume, well-scoped, regulation-adjacent work where data residency and unit cost dominate — and where a 47 on SWE-bench Verified is, in fact, enough.

Then do the thing almost nobody does: write down what would make you switch, and which licence clause would stop you. The models will keep arriving at this pace. The decision you want to have made in advance is the one about exits.

---

Sources

• Kimi K3 weights release — Quartz, 27 July 2026 · Interconnects
• Qwen3.8-27B open weights — emergent.sh · MarkTechPost
• GLM-5.3 and open-sourcing timeline — ChinaTechNews
• GLM-5.3-Flash and the domestic-chip cluster — South China Morning Post
• IBM Granite 4.2 (Apache 2.0, SWE-bench Verified) — MarkTechPost, 25 August 2026
• DeepSeek peak/off-peak pricing — Unite.AI