Open Kernels You Can't Actually Run

Last week this blog argued that "open weights" had split into two things sharing a word: models anyone can run, and models nobody can — Kimi K3 being free to download and needing roughly eighteen H100s to hold in memory. Openness bounded by physics rather than by law.

Cursor just shipped the same shape one layer down the stack. Mixture-of-Kittens (MoK) is the mixture-of-experts training megakernel behind Composer, their agentic coding model, released under Apache 2.0 — the most permissive rung on the openness ladder, no revenue threshold, no acceptable-use policy, no vetting. It also requires NVIDIA Blackwell SM100 or SM103 silicon, which in practice means a GB200 or GB300 NVL72 rack.

Seventy-two Blackwell GPUs, in one rack, as the entry ticket. The licence excludes nobody; the hardware excludes almost everybody.

What it actually does

The problem MoK solves is specific and, if you train MoE models, painfully familiar: the mixture-of-experts layer had become the bottleneck in scaling Composer, consuming more than half of end-to-end training time depending on workload and configuration. Not the attention, not the optimizer — the expert routing and the all-to-all communication it implies.

MoK's answer is to stop treating communication and computation as separate stages. It fuses all MoE communication and computation into a single kernel, overlapping compute and inter-GPU networking at configurable granularity, and fully eliminating CPU–GPU synchronization. One kernel, one launch, no host round-trips in the middle of the layer.

Against the fastest public baselines, Cursor reports:

End-to-end, they put it at 1.41× throughput over their own prior stack — which is the more honest number, since kernel microbenchmarks always flatter and the previous stack was itself already optimized (Cursor published custom MXFP8 kernels worth 1.5× before this). It's in production, powering Composer training across tens of thousands of GPUs, by Stuart Sul, Nash Brown, Henry Wildermuth, William Lin and Federico Cassano.

The name is a nod to the "kittens" lineage of GPU kernel work; the repository doesn't claim a technical dependency, so read it as homage rather than architecture.

The determinism is the underrated part

Buried in the description is a word doing more work than the speedups: fully deterministic.

Determinism usually costs you performance. The fast way to reduce across GPUs is to let results land in whatever order they arrive, and floating-point addition isn't associative, so the same run twice gives you slightly different numbers. Most training stacks accept that. Cursor's claim is determinism and 2.37× — which is the genuinely hard combination, not either one alone.

Why it matters beyond debugging: a training run you cannot reproduce is a training run nobody can audit. This blog has spent the last week on verifiability — Chain-of-Evidence forcing every claim in a generated paper to trace to a source, Lean certificates making a proof machine-checkable, eval harnesses that turned out not to contain what they claimed. Deterministic kernels are the same instinct applied to the training run itself: they don't make a result correct, but they make "we ran this and got that" a falsifiable statement rather than an anecdote.

To be precise about the scope, since it's easy to overclaim: determinism here means same inputs, same hardware, same result across runs. It does not mean anyone else can reproduce Cursor's training — you'd still need their data, their configuration, and the rack. It's a necessary condition for reproducibility, not a sufficient one.

What Cursor is actually protecting

The strategic read is the interesting one, because Cursor occupies an odd position in the stack.

This blog argued a week ago that the coding harness is the layer deliberately engineered toward zero switching cost — Cursor being the canonical example, having made model choice a dropdown rather than an identity. If your product's whole pitch is that the model underneath is swappable, you've built a business on a commoditized layer.

Cursor's answer has been to go down the stack: train Composer, own a model. And now to give away the infrastructure below that model, free and unconditionally. Which tells you exactly what they think the moat isn't. Not the kernels — those are a recruiting asset and a credibility asset, and open-sourcing them costs nothing strategically because the only people who can use them already have their own kernel teams. Not obviously the model either, given how fast that tier commoditizes.

It's the same calculation Mistral made with Shieldstral and Liquid made with LFM2.5: give away the layer that isn't defensible, at the maximum permissiveness the layer can bear, and keep the product. The pattern across all three is that 2026's open-source releases are increasingly precisely targeted at the non-moat.

The part that generalizes

Set MoK next to the models this blog has catalogued and a cleaner statement of the openness problem emerges. There are now at least three independent gates on any "open" release:

• Legal — what the licence permits. Apache 2.0 here; $10M revenue ceiling on LFM2.5; research-only for AMD's Instella-MoE.
• Physical — what hardware it demands. A laptop for LFM2.5; eighteen H100s for Kimi K3; an NVL72 rack for MoK.
• Practical — whether you have the surrounding competence to use it. Kernels are the extreme case: even with the rack, this is not a drop-in.

MoK is maximally open on the first gate and close to maximally closed on the second and third. Kimi K3 is nearly the same. Meanwhile LFM2.5-2.6B is restricted on the first gate and wide open on the other two — and is, for almost everyone reading, the more usable release.

Which suggests the ladder needs reading in two dimensions rather than one. "How open is this?" keeps getting answered with a licence when the licence is frequently the least binding constraint in the stack.

What to expect next

• Expect more frontier-lab kernel releases, and expect them all to be Apache 2.0. Kernels are the safest thing a lab can open-source: enormous credibility, near-zero competitive cost, and an audience pre-filtered by capital expenditure.
• Determinism becomes a selling point rather than a footnote. Once one production stack demonstrates you don't have to trade it for speed, "our training is reproducible" stops being an excuse-shaped absence.
• The NVL72 requirement dates this release fast. A kernel written from first principles for one rack generation is a bet that the rack generation lasts. The interesting question is whether MoK gets ported to whatever follows Blackwell, or whether it becomes a beautifully-engineered artifact of one hardware moment.

References: Cursor — Mixture-of-Kittens announcement · cursor/mixture-of-kittens on GitHub (Apache 2.0) · Cursor — 1.5× faster MoE training with custom MXFP8 kernels · MarkTechPost coverage · related coverage: Open Weights You Can't Actually Run · How Open Is "Open"? · The Price War Nobody Is Actually Fighting · LFM2.5-2.6B