Kimi K3.1 Pro Is Cheap and Close to Claude Opus 5.5. Its Open Weights Aren't Out Yet

Every time a new model comes out with a headline saying it is catching up to Claude Opus 5.5, the first question I have is a simple one: what can I actually use today, and what is still only a promise?

This week Moonshot AI released Kimi K3.1 Pro, and according to The Decoder's October 23 report it sits fourth on the Artificial Analysis Intelligence Index, where the only three models above it are Claude Opus 5.5, Claude Sonnet 5.5 and Muse Wonder Full. It has a 1 million token context window, and on the standard API it costs $2 for every million input tokens and $10 for every million output tokens, which works out a third cheaper per token than Kimi K3.

But the word open is where it gets tricky. Moonshot's recent Kimi models came with open weights, and Moonshot says the full K3.1 Pro weights will be out by November 4, but as of today they are not. So for now K3.1 Pro is basically a hosted model like any other, where your prompts and your code go to Moonshot's servers and you pay for every token.

I think it is worth testing, because the price is low and the coding numbers look good. But a benchmark table that puts it right next to Opus 5.5 doesn't make the two equal, and I wouldn't treat them that way.

What you can actually use today

Moonshot shipped two models, K3.1 Pro and K3.1 Pro Highspeed, and Moonshot's announcement says the Highspeed version is two to three times faster. You can reach them in a few places: Kimi.ai and the Kimi mobile apps, the Kimi Work desktop app, Kimi Code (where you switch models with the /model command), and the Kimi API, where they are called kimi-k3.1-pro and kimi-k3.1-pro-highspeed.

If you are on a business or enterprise account, you won't see it straight away, because it is off by default and an admin has to switch it on.

Under the hood it is the same size as K3, because K3.1 Pro is basically K3 with a lot more post-training on top. It has 2.8 trillion parameters in total, but only 104 billion of them do any work for a given token.

What does that mean in practice? Think of a huge hospital with thousands of doctors, where each patient only gets seen by the few specialists who matter for their problem. So each answer needs far less compute than the full size of the model suggests. But the whole hospital still has to be built and kept running somewhere, and that comes back when we get to the weights.

It also takes both text and images as input, and with 1 million tokens of context you can hand it a large chunk of a codebase or a long stack of documents in one go, instead of splitting it up and feeding it in parts.

Open weights are still a promise until November 4

So what does open weights actually mean here? The weights are basically the numbers a model learns while it is being trained, so having the weights means having the model itself. With them you can run it on your own machines, fine-tune it on your own data, or choose any hosting provider you like, and Moonshot doesn't have to be in the middle.

Without the weights, all you get is the apps and the API, so every prompt and every file goes to Moonshot's servers. Moonshot does say it offers Zero Data Retention to API customers, and that helps. But some teams have rules about where their code can go, and those rules usually care about who runs the server, so a retention setting might not be enough for them.

Should you believe the November 4 date? I think there is some reason to. Kimi K3 followed the same pattern earlier this year, where it launched in Moonshot's apps and API on July 16 and then the full weights came out on July 27, eleven days later, just as Moonshot had said they would.

So Moonshot has kept this kind of promise before. Still, until the files are actually there, a date is only a date, and I wouldn't make any plan that depends on self-hosting K3.1 Pro before then.

Even with the weights, this won't run on your laptop

And even after the weights come out, open won't mean you can download the model and run it on your laptop. When the K3 weights shipped, the download was about 1.56 TB and running the model took roughly 1.4 TB of memory, and that was before counting the long context. For real production use, that means a cluster of machines with 64 or more accelerators. K3.1 Pro has the same parameter count, so I would expect it to need something close to that.

So for most developers, the weights will mostly mean that more hosting providers can offer the model and that bigger companies can run it inside their own data centers. I think that is still useful, because when more providers offer a model you usually get more choice, both in price and in where your data ends up.

Then there is the license, which is the other thing to check. K3 came with its own Kimi K3 License, while K2 had used a Modified MIT license. The K3 license lets you self-host and fine-tune, but it adds conditions once you get big.

For example, if your group made more than $20 million in revenue in any 12-month period, you need a separate deal before you can resell raw K3 inference. And if your product has more than 100 million monthly active users or $20 million in monthly revenue, it has to show "Kimi K3" in its interface. We don't know yet which license K3.1 Pro is going to ship with, so that is one more thing to read on November 4.

Cheaper per token, but about the same per task

The Decoder lists the standard price at $2 per million input tokens, $10 per million output tokens and $0.20 per million cached input tokens. Highspeed costs twice as much, $4 and $20, and the cached price stays the same. K3 was $3 and $15, so per token the new model is 33% cheaper.

To put that in a real case, say a coding agent reads 500,000 tokens of your project and writes 50,000 tokens of changes. At the standard price that run costs $1 for the input and $0.50 for the output, and less than that if a big part of the input is cached.

But that per-token price doesn't tell you what a whole task costs. The same report has Artificial Analysis figures showing that one task on its Intelligence Index costs $1.98 with K3.1 Pro, which is almost exactly the $2.00 it cost with K3. The Decoder says the reason is that the new model writes about 14% more output tokens.

So it is a bit like petrol getting cheaper per litre while your car starts using more litres for the same trip, and in the end what you pay for is the trip. That is why I think the number worth comparing is what a finished task costs on your own work, and the per-token price on the pricing page is only where you start.

How close it really is to Claude Opus 5.5

The headline comparison comes from Moonshot's own benchmark table, which was run with reasoning effort set to max. On Terminal-Bench 4.0, which tests coding agents working in a terminal, K3.1 Pro scores 65.7, Opus 5.5 scores 66.4 and GPT-6 Astra scores 58.2. On SWE Marathon v1.1, K3.1 Pro is actually ahead, with 51.7 against 46.3 for Opus 5.5.

But Opus 5.5 still wins other tests in the same table. For example, on BenchCAD with tools it scores 96.2 against 92.7, and on ExploitBench the gap is much bigger, 91.0 against 74.7.

The more independent number is the Artificial Analysis Intelligence Index. There K3.1 Pro scores 55, which is 11 points more than K3, and Opus 5.5 scores 58. So on that index it is close, only three points back, but it is still behind and not ahead.

Moonshot also reports that on its internal hallucination stress test, the share of false claims went down from 23.4% with K3 to 8.3% with K3.1 Pro. But Moonshot itself says this is a stress test, so it is not the error rate you should expect in daily use.

Why can't you just take the table at face value? Because a benchmark is a fixed set of tasks run with fixed settings, and your work is a different set. For example, your project could be an old Django app that depends on internal libraries no model has ever seen, with a test suite that takes ten minutes to run and a bunch of rules that only your team knows.

A model that is three points behind on an index could still be better at that kind of work, or it could be a lot worse, and you only find out which by trying it on your own tasks.

How I would test it before switching

Personally, I wouldn't move a whole team to a new model because of a launch table. I would pick a small set of real tasks, maybe five to ten, where you already know what a good result looks like, for example a bug your team has already fixed or a feature that already has tests. Then I would run those same tasks with K3.1 Pro, through Kimi Code or the API, and with whatever model you use today.

After that, put the results side by side and look at a few things: whether the model finished the task, how much you had to fix after it was done, how long the run took, and what the whole run cost. The cost one matters because of the output tokens from earlier, since a model that is cheaper per token but writes a lot more can end up costing about the same for each task.

Highspeed is a separate decision. It costs twice as much per token, so I think it only makes sense where speed actually matters, for example when you are sitting in your editor waiting on an agent to finish. For long jobs that run in the background, the standard version is probably fine.

When I would switch, and when I would wait

So should you switch? I think it depends on the kind of work you do. If you run a lot of high-volume work where the cost adds up, like agents going through many small tasks or reading very long documents, then the lower price and the 1 million token context make K3.1 Pro a strong candidate, as long as it does well on your own test.

The best case for switching right now goes something like this: it is only three points behind Opus 5.5 on the index and it is a lot cheaper per token, so why wait? For a lot of tasks, that might be true. But the index is an average over many tasks, the cost per task on that same index hardly moved from K3, and your tasks are not the index, so I would still want my own numbers before moving everything over.

If your team has rules about where code can be sent, I would wait for November 4. Then check that the weights are really out, read the license, and only after that look at self-hosting or at a provider you already trust.

And if you do security testing, keep in mind that Moonshot removed cyberattack-related material from training before the open release. On Moonshot's own in-house exploit test, the version trained without those cuts solved 90.5% of tasks while the released K3.1 Pro solved 81%, and Opus 5.5 is well ahead on ExploitBench in Moonshot's table too. So for that kind of work, the model was made weaker on purpose.

Close on the benchmarks, still waiting on the open part

Going back to the headline, is Kimi K3.1 Pro closing in on Claude Opus 5.5? On Moonshot's coding numbers and on the Artificial Analysis index, I would say yes, it is close. But being close on a benchmark and being as good on your own work are two different things, and the open part, which is a big reason people pay attention to Kimi models at all, is still just a date on the calendar.

So for now I would treat it as a cheap hosted model that deserves an afternoon of real testing on your own tasks. Then on November 4, check two things: whether the weights are actually out, and what license came with them.