Kimi K3 goes free today. You still can't run it.

Moonshot AI took their new model, handed it the source code for a piece of its own architecture, and gave it one instruction: make this faster on H200 hardware without changing what it outputs. Then they left. Twenty hours later, with no human input, it came back with a 1.6x speedup. On a second run it took one component from 283 milliseconds to 114. That is a 2.48x improvement, written by the model, on the mechanism that makes the model work. At least, that is the story according to Moonshot; nobody outside the company has reproduced that run yet.

It is a genuinely remarkable story. It is also the only part of the story most people are telling you. The weights went public today, and there are three things about this release that Moonshot's own benchmark charts leave out. I spent a weekend testing the model so you can see all of it, not just the launch deck.

What Kimi K3 actually is

On July 16th, Moonshot AI, the Beijing lab founded by Yang Zhilin and backed by Alibaba, shipped Kimi K3: 2.8 trillion total parameters with about 50 billion active per token, a one million token context window, natively multimodal. It is the largest open-weight model anyone has ever released, by a wide margin.

Two architecture pieces do the heavy lifting, both published as open research before the model shipped. Kimi Delta Attention delivers up to 6.3x faster decoding at million-token context, and Attention Residuals give roughly 25% better training efficiency, according to Moonshot's papers.

And they built it under three years of U.S. export controls on advanced chips. Bank of America's read on the release: architectural innovation can still deliver step-change gains even with constrained compute. That part is not hype.

First, the credit it earns: the coding is real

Rather than read you a benchmark table, I gave K3 the hardest prompt I could think of that you can verify with your own eyes: three physics scenes, one self-contained HTML file each, no libraries, and the physics had to be computed rather than animated. A train derailing off a failing bridge, a mid-air car collision over a canyon, a monster truck crushing a row of parked cars.

It built all three in one shot. In the derailment scene the carriage momentum carries through the couplings after the bridge fails; that is not a canned animation loop. It commented the physics math so I could check it, which I did. The mid-air collision transfers momentum correctly, and the monster truck's suspension compresses under load.

I also gave it a second build: an interactive 3D skeleton-dial mechanical watch in Three.js, single HTML file, with a disassemble button that explodes the case, crystal, dial, and gear train into layers while the balance wheel keeps ticking. The material work is the part that usually breaks, polished steel against glass against matte leather, and you can judge the result yourself in the video.

Honest reaction: this is frontier-tier. Tom's Hardware reported K3 topping the Frontend Code Arena benchmark, above Claude Fable 5, and having watched it work, I believe it. The coding claims hold up. On the record.

Because what comes next is not in the press release.

Reversal 1: the cheap Chinese model era is over

You have heard "five times cheaper than the frontier." Here is the actual price on OpenRouter: 3 dollars per million input tokens, 15 out. That is Claude Sonnet pricing. It is also 3 to 4 times more expensive than Moonshot's own predecessor, K2.6, which sits at $0.95 in and $4 out.

So where does "cheaper" come from? Per completed task. Moonshot's claim is that K3 uses about 21% fewer tokens for the same job, which turns a $1.30 task into a $0.25 one. That is the honest version of the math, and it comes with a catch.

K3 has exactly one reasoning mode: max. There is no "just answer quickly." Simon Willison asked it for an SVG of a pelican riding a bicycle and got 13,241 reasoning tokens back. Twenty-five cents. For a drawing. I reproduced the same class of behavior in my own API runs: trivial tasks think for thousands of tokens about nothing, and reasoning tokens bill as output tokens.

The practical takeaway: do not make it your default model. Save it for work that earns that reasoning budget.

Reversal 2: the chart they didn't publish

Moonshot published a chart showing factual accuracy up from 33 to 46 percent. Real improvement, no argument.

Independent testing by Artificial Analysis found a second chart: hallucination rate up from 39 to 51 percent. The model got better at answering and worse at knowing when it is wrong. That chart did not make the deck.

To be fair, Claude Fable 5 scores worse on the same test, at 54.9%. The story is not the number. The story is which chart got published. For code, a compiler catches the lies. For research and facts, treat K3 with more suspicion than the benchmarks suggest.

Reversal 3: the 1.4 terabyte problem

"China gave it away for free." Okay. Let's download it.

The weights are 1.4 terabytes at 4-bit quantization. That is the compressed version. And all 2.8 trillion parameters have to stay in memory, or you are under one token per second. Running it takes roughly eighteen 80GB GPUs, or one Blackwell node. Not a workstation. Not your machine. Not mine.

Downloadable is not the same as runnable. They gave it away, to AWS.

Do the weights still matter? Enormously. Nobody can switch this model off, and in two years, when hardware catches up, it still runs. It just is not what people picture when they hear "free."

The verdict: four rules

If you write code for a living, run five of your own tasks, K3 versus whatever you use now, and measure cost per completed job. That is the only number that matters.

1. Not your default model. One reasoning gear, and it is expensive.
2. Curate the context. 200K tokens of the right code beats 900K of everything.
3. Measurable goals only. Give it "reduce p95 latency by 30%," not "improve this code," or it drifts.
4. Reasoning tokens are output tokens. Check your bill's math before blaming the model.

The question worth watching

The question was never whether a Chinese lab could match the frontier. That is answered: yes, under export controls. The question is what happens to the price of closed models now that an open one exists. It is inconvenient and it needs a data centre, but it exists, and it does not expire.

One more thing worth sitting with: China is discussing export controls of its own. So K3 is either the first of many, or the last one. Nobody knows yet.

The prompts I used

As promised in the video. Copy them as-is, or swap in your own scenarios.

The physics stress test

This is the prompt behind the derailment, canyon, and monster truck scenes. The "computed, not animated" line is what makes it hard to fake, and the comment requirement is what lets you verify the math afterwards.

Build three self-contained HTML5 canvas scenes with real physics.
No external libraries. Everything in one file per scene.

Scene 1: A train derailing off a broken bridge into water.
Include: carriage momentum, bridge structural failure,
water displacement on impact.

Scene 2: Two cars jumping off ramps and colliding mid-air
over a canyon. Include: correct trajectory arcs,
collision momentum transfer, debris.

Scene 3: A monster truck crushing a row of parked cars.
Include: suspension compression, sheet metal deformation,
weight distribution.

Requirements for all three:
- Physics must be computed, not animated
- 60fps target
- Include a reset button
- Comment the physics math so I can verify it

Build all three. Don't ask clarifying questions.

The 3D mechanical watch

The prompt behind the skeleton watch build. The material property requirements are deliberate: glossiness, metalness, and glass transmission are brutal on a model that is faking its 3D understanding.

Build an interactive 3D mechanical watch in the browser.
Single HTML file. Three.js.

The object: a skeleton-dial mechanical wristwatch with a polished
steel case, sapphire-tinted crystal, brushed-metal bezel, leather
strap, and a visible movement: mainspring barrel, gear train
(at least 5 gears of different sizes), balance wheel that
oscillates, and jewel bearings in ruby red.

Must include:
- Correct material properties: polished steel (high metalness,
  low roughness), brushed metal (anisotropic-looking finish),
  glass crystal with transmission/reflection, matte leather
- Three-point lighting with real shadows
- Orbit controls
- A "disassemble" button that explodes the watch into layers:
  crystal lifts away, dial separates, movement splits into its
  individual gears, case and strap drift apart, each part
  moving smoothly to its exploded position, and reassembling
  on second click
- The balance wheel keeps ticking at ~4Hz even when exploded

Quality bar: this should look like a product render,
not a WebGL demo. If a detail would be visible in real
life, model it.

Build the whole thing. Show me the file.

The cost reality check

Run these through the API, not the chat UI, because the chat UI hides the token accounting you need. Log reasoning_tokens and output_tokens from the usage object for each call.

Generate an SVG of a pelican riding a bicycle.

This reproduces Simon Willison's test. Then the trivial-task case:

Convert this JSON to a TypeScript interface:
[paste any 10-line JSON blob]

Watch it think for thousands of tokens about nothing. Finally, run one real task from your own work on K3 and on whatever model you use today, and compare cost per completed job, not cost per token. That last comparison is the whole argument in one number.

The measurable-objective template

This is the shape behind rule 3. Point it at a real repo and give it an outcome you can measure:

Read this entire codebase before writing anything.

Objective: [a MEASURABLE outcome, e.g. "reduce p95 API
response time by 30%" or "eliminate all N+1 queries in
the data layer"]

Rules:
- Profile first. Show me where the time actually goes
  before you change anything.
- Do not change public interfaces or numerical behavior.
- Run the existing test suite after each change.
- If a change makes things worse, revert it and tell me why.
- Work until the objective is hit or you can prove it's
  not achievable without breaking the rules.

Report at the end: what you changed, what it bought,
what you tried that didn't work.

If you swap the objective for a vague "improve this code," you will see the drift problem from rule 3 demonstrate itself.