Skip to content

Kimi K3.1 Pro: the first model heading for open weights that stands at the frontier

Published on 26 October 2026

Caja metálica con un candado y la llave puesta junto a una balanza de platillos casi igualada, con la silueta de una persona esperando al fondo.

Moonshot has put Kimi K3.1 Pro on its API with a promise attached: full weights released before 4 November 2026. It's the first time a model that is going to be downloadable has climbed this high up the frontier table, and that shifts the conversation more than the benchmark itself does.

The story comes from Simon Willison, who tried it the same day.

What happened

The model already answers on Moonshot's API, but there's no download yet. The company commits in writing to releasing it:

"Full model weights will be released by Nov 4, 2026".

The pricing: two dollars per million input tokens and ten per million output tokens. That puts it level with GPT-6.1 Sol and at half the cost of Claude Opus 5.5. There's also a "Highspeed" variant, two to three times faster, at double the price — with one exception: when the prompt hits the input cache, those tokens cost the same in both versions.

On the numbers: Moonshot's own tests put it shoulder to shoulder with Opus 5.5 and GPT-6 Astra, winning a few and coming close on the rest. The Artificial Analysis index gives it 55. Gemini 4 Argon, GPT-6 Astra and Claude Fable 5.1 all sit at 53; the only model above it is Opus 5.5, on 58.

Willison ran it against Moonshot's endpoint using the llm openai endpoint command he added to LLM back in August, which works with any OpenAI-compatible API but keeps no log — hence having to redirect both the output and the reasoning trace to files. The model supports three reasoning levels: low, medium and max. And yes, he asked it for the SVG pelican on a bicycle, his standing test, on all three.

Why it matters

If you keep software in production with a model behind it, there are three actionable things here.

Output pricing is what bites. Ten dollars per million output tokens, half what the current leader charges, is real money once you have an agent writing code or generating long reports. Input gets cached and gets cheaper; output doesn't. If your workload spits out text, that's where the saving lives.

The cache rewards prompt order. The fact that cache hits cost the same in the fast version and the standard one has a consequence: you want the stable part of your prompt — instructions, schema, examples — always at the front and never changing between calls. Move a comma in the header and you invalidate the whole cache.

Three reasoning levels are three models. Treat them as such: measure quality, latency and cost for all three against your own cases, not against a general table. We've seen tasks where the low level gets it right just as often in a third of the time, and others where going to max is the difference between working and not.

As for "Highspeed": paying double to go two or three times faster only makes sense if latency sits on the critical path of a user staring at a screen. For batch work, overnight jobs or anything queued, it's money thrown away.

What doesn't change

The weights aren't out yet. Until 4 November this is one more Chinese API, with the same vendor dependency as any other, and an extra consideration if you plan to send client data through it: check where it's processed before signing anything.

We also don't know what licence they'll ship under. "Open weights" means nothing on its own until you've read the commercial use terms, and surprises there are routine.

A vendor's own benchmarks are marketing material, always. And the Artificial Analysis index, which is independent, is an aggregate: 55 against 58 tells you nothing about which one reads your delivery notes better. Only your own cases tell you that.

And the usual one: downloading a frontier model isn't running it. The weights are free; the GPU that moves them isn't. We wrote that when Kolibri-1 came out and it still holds.

Our take

What strikes me as news here isn't the 55. It's the date.

A promise with a specific day on it is verifiable: on 5 November we'll know whether Moonshot delivered or joined the long list of "we'll open it soon". And the pattern it's testing — charge for the API during the window where you hold an edge, open up afterwards — is the healthiest one tried so far. It aligns the incentives: you get paid for the service, not for the secret.

What I think will age badly is the number. In six weeks there'll be another model on top and nobody will remember October's 55. What doesn't age is the price effect: every time a downloadable model draws level with the closed ones, the closed ones come down. For most of the companies I work with, the value here isn't sovereignty — they're not going to build a cluster — it's that next month's bill is cheaper without touching a line of code.

What I'd do today: no migration. Build your own test bench with fifty real cases from your domain, leave it running against whatever you already use, and come back on 5 November with the licence read and the numbers in front of you. Switching models because of somebody else's table is the fastest way to spend a fortnight debugging regressions nobody asked for.

And one thing we run into every time someone wants to bring an open model in-house: the problem is never the model. It's where the documents come from, who's allowed to see them, and what happens the day the service doesn't answer. Changing supplier doesn't fix that.

Any questions, tell me and we'll look at it.

All the best, Vicente.

Source: Simon Willison

Did reading this raise a question?

Ask us. We answer even if you never become a client.