Kimi K3 ships open weights, and picks a browser game as its proof
Moonshot AI launched Kimi K3 on July 16 and released the weights eleven days later, on July 27. The download is 96 shards and roughly 1.56 TB on Hugging Face. Nathan Lambert called it "clearly the strongest open model ever released," and the rankings back him up: first place in the Frontend Code Arena, second on the Vals AI Index, third on the Artificial Analysis Intelligence Index behind only Claude Fable 5 and GPT-5.6 Sol Max. Among open-weight models it isn't close.
That's the story everyone wrote. The part that caught our attention is what Moonshot chose to show off with it.
The demo is a Three.js game
Alongside the launch, K3 produced a procedural 3D exploration game that runs in a browser tab: an open world with water, trees, cabins, snowy mountains, and riders on horseback, built in Three.js on the WebGPU renderer with GPU compute. Not a research clip, not a video of a game. A page you load.
The method matters more than the scene. According to the WebGPU community's writeup, the model worked with vision in the loop, iterating between the code it generated and live screenshots of the running result so it could see what it had made and fix it. That is the same loop we run inside Cinevva's Game Creator, and it is the thing that separates a model that writes plausible Three.js from a model that ships a game that actually renders. Anyone can generate a scene graph. Noticing the camera is inside the terrain is the hard part.
So the situation as of this week is that a frontier lab, launching its most capable model, reached for browser-based 3D game creation as the demonstration that would land. Two years ago the flagship demo was a chatbot answering a riddle. The bar moved to something you can walk around in.
What's actually in the model
K3 is a Mixture-of-Experts with 2.8 trillion total parameters and 104 billion active per token, a context window of 1,048,576 tokens, and text, image, and video input. Moonshot introduced two architecture changes, Kimi Delta Attention and Attention Residuals, and reports roughly a 2.5x improvement in scaling efficiency over Kimi K2. It always reasons, and where the July launch shipped with a single "max" effort level, the open release exposes low, high, and max.
On Moonshot's own numbers it beats Claude Opus 4.8 at max and GPT-5.5 at high across most of the suite, and loses to Fable 5 and GPT-5.6 Sol. Treat self-reported benchmarks as a claim rather than a verdict, but two results held up in independent testing and both are the kind that matter for building software: BrowseComp at 91.2 for agentic browsing, and SWE Marathon at 42.0 for long-horizon coding, which puts it above both Fable 5 and Sol on work that runs for hours instead of seconds.
API pricing is $3.00 per million input tokens and $15.00 output, dropping to $0.30 on cached input, the same headline rate as Claude Sonnet 5. OpenRouter is listing it slightly cheaper. One caveat worth reading before you build on it: unlike Tencent's Hunyuan Hy3, which went out under Apache 2.0 with no restrictions, K3 ships under a custom Kimi K3 License. Open weights and open source are not the same document, and if you plan to put this in a commercial product you should read the terms rather than assume.
The gap is closing faster than the release cadence suggests
Lambert's read on the broader trend is that the distance between the best closed models and the best open ones has compressed from six to nine months down to something more like three to five. Alibaba has already announced Qwen 3.8 at 2.4 trillion parameters with open weights to follow, so the escalation isn't slowing. We wrote in January 2025 that DeepSeek R1 reset the cost of intelligence. Eighteen months on, the pattern is that every reset gets absorbed and then repeated faster.
For anyone making games, the practical consequence is that the intelligence layer keeps getting cheaper and more portable at the same time the asset layer already did. A studio that wanted a model fine-tuned on its own codebase used to be choosing between an API dependency it didn't control and a weaker local model. That tradeoff is thinner every quarter.
What we're doing about it
We run a multi-provider gateway, so this is a concrete decision rather than an abstract one. K3's strengths sit exactly where our workload is: long-horizon agentic coding, tool use, and iterating against screenshots and console logs from a live game. We're benchmarking it against our current model lineup on real Game Creator sessions rather than on anyone's published table, because the metric we care about isn't an Elo score. It's how often a turn ends with a game the person can actually play, and how often the model catches its own mistake before the user has to.
We'll publish what we find, including if the answer is that it doesn't beat what we're already running. The interesting thing about this release isn't that a Chinese lab shipped a very good open model, which has stopped being surprising. It's that the demo they picked to prove it was a game in a browser tab, which is the thing we've been building for.