Blog

Kimi K3's $20 Million Fine Print: Reading Open-Weight Licences Before You Build a Product On Them

August 2026 · 6 min read · AI Strategy

A licence document with one clause highlighted, under a magnifying glass with a terracotta lens
← Back to all posts

Moonshot AI's Kimi K3, the 2.8-trillion-parameter model that topped open-weight benchmarks when its weights published on 27 July 2026, ships under what the lab calls an MIT-like licence. It is not plain MIT. It carries a commercial gate: once a business or product built on Kimi K3 crosses 20 million US dollars in model-as-a-service revenue, different licence terms apply.

For most Australian small and mid-sized businesses that threshold is academic, and the licence is functionally free. For any business building a product to sell rather than using AI internally, it is exactly the kind of clause that wants reading before you have six months of engineering built around the model, not after.

Three licence patterns now common in open weights

  • Plain permissive, MIT or Apache 2.0, with no revenue or user threshold at all. This is open source in the traditional sense and the terms do not change as you grow.

  • Revenue-gated permissive, free until you hit a stated dollar threshold, after which a separate commercial agreement is required. Kimi K3 sits here.

  • User-gated permissive, free until you cross a stated monthly-active-user count, as Meta applies to Llama 4. Same idea, different trigger.

DeepSeek and Z.ai ship comparably sized models, in the 700 billion to 1.65 trillion parameter range, under plain MIT with no gate whatsoever. So the gate is a choice each lab makes, not an inevitability of publishing weights, and Kimi K3's version sits partway between fully open and the more restrictive thresholds elsewhere in the field.

What to check before building a product on any open model

If a business is building a product on top of a model rather than running it internally, the licence review is not a legal formality. It is a dependency check on the commercial model. The specific things worth confirming:

  • Whether a revenue or usage threshold exists at all, and precisely what event triggers it.

  • Whose revenue is being measured. The client's total revenue, the product's revenue, or model-as-a-service revenue specifically? The definitions vary between labs and the difference can be an order of magnitude.

  • What the fallback commercial terms actually cost once you are past the gate, and whether they are published or negotiated. Unpublished is a risk in itself.

  • Whether the licence can change for future model versions, and what happens to the version you already shipped on.

  • Whether the terms restrict any use case you might grow into, which catches people who started internal and later productised.

We scope this as a fixed-fee $2,800 licence and architecture review before a client commits engineering time to an open-weight foundation. That is cheaper than finding out at $19 million in revenue that your licence terms are about to change, at the exact moment your attention is worth the most elsewhere.

Where Claude sits in this conversation

Claude's commercial terms do not carry a hidden revenue cliff that changes the deal once you succeed. For a Sydney or Melbourne founder building a product, that is not a small thing. Your licence terms should get simpler as you grow, not force a renegotiation at the point where you can least afford the distraction.

That is a real advantage and worth stating plainly, but it is not the whole picture. A managed API carries its own dependency: pricing changes, deprecation schedules and rate limits are all things a vendor controls and you do not. The honest comparison is not gate versus no gate. It is which set of dependencies you would rather manage, and which one you can actually plan around.

What not to take from this

None of this is an argument against open-weight models. Plenty of Australian businesses run them well, and for internal workloads with no productisation path the licence question genuinely does not matter much. The distinction that matters is internal use versus building a product you sell, and a surprising number of teams cross that line gradually without anyone re-reading the terms.

It is also not an argument that the biggest model wins. Kimi K3's benchmark position is real, but for most product work a smaller model with simpler terms and a lower serving cost is the better foundation. The licence is one input among several, and it is simply the one most often skipped because it sits with legal rather than engineering, and neither team thinks it is theirs.

If your team is building on an open-weight model and nobody outside the engineering team has read the licence, that is worth fixing while it is still cheap. Automata AI reviews the licence and the architecture together, because the two decisions are the same decision, book a session and we will do it before it becomes expensive.

Ready to move from AI pilot to production?

We help mid-market Australian businesses deploy AI automations that actually reach production and deliver measurable ROI.