A comparison card reading Kimi K3.1 Pro vs Kimi K3.1, subtitled 'One is a model. The other is a series name.', with tags for kimi-k3.1-pro and kimi-k3.1-pro-highspeed and a note that no plain kimi-k3.1 endpoint exists.
Guides & Insights

Kimi K3.1 Pro vs Kimi K3.1: One Is a Model, the Other Is a Series Name

Author

Magnus Corvin

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

If you are trying to choose between Kimi K3.1 Pro and Kimi K3.1, the first useful fact is that only one of them exists as something you can call. Moonshot AI's rate card for the K3 series has three rows: kimi-k3.1-pro, kimi-k3.1-pro-highspeed and kimi-k3. There is no plain kimi-k3.1 row, no model card for it, and no endpoint that answers to that name. "K3.1" is the family the October 24, 2026 release belongs to. "Pro" is the model inside it.

That sounds like a naming quibble until you are the person who put "kimi-k3.1" in a config file. Then it is a 404, a failed eval run, or an invoice line somebody has to explain. The confusion is not the reader's fault: Moonshot used the bare name in its own pre-launch video, and third-party coverage has been sloppy about the distinction since the teaser dropped on October 23. So this comparison is really two questions in one — what the name means, and which of the two callable K3.1 endpoints you should actually pick.

Where the bare "K3.1" name came from

Moonshot seeded the ambiguity itself. Its 24-second teaser showed a Kimi Code terminal reading "Model: Kimi K3.1", not "Kimi K3.1 Pro". Around the same time, an SGLang commit reported in the Chinese tech press added "Kimi-K3.1 support for the K3 chat encoder" and referenced a Hugging Face repository named moonshotai/Kimi-K3.1. The version number also appears in Kimi Work's desktop app as version 3.1.0. Three different things — a model label, a repository name, and a product version — all collapsed into the same string in public view.

The launch post resolved part of it. Moonshot describes Kimi K3.1 Pro as the first model in its new K3.1 series, and the API documentation lists exactly two identifiers. The repository name is the one piece still unresolved, and it will probably be settled when the weights ship by November 4, 2026. If the release is published as Kimi-K3.1, then "K3.1" will be the open-weight artifact and "K3.1 Pro" the hosted API product built from it. That is a coherent split, but it is not a second model you can call today.

So the answer to "what is the difference between Kimi K3.1 Pro and Kimi K3.1" is: at the endpoint level, none, because one of the two has no endpoint. At the family level, Pro is the implementation. If a future non-Pro K3.1 appears, it will need its own row on the rate card before it needs a comparison article.

The Kimi API Platform pricing table listing only three K3 rows — kimi-k3.1-pro at $2.00/$10.00, kimi-k3.1-pro-highspeed at $4.00/$20.00 and kimi-k3 at $3.00/$15.00 per 1M tokens — with no plain kimi-k3.1 row.

The comparison that does exist: Pro versus Pro Highspeed

Once you accept that "K3.1" is a label rather than a competitor, the real fork in the lineup becomes visible. Moonshot shipped two callable variants on the same day, and they are the same model at two operating points.

• Price — Kimi K3.1 Pro is $2.00 per million input tokens and $10.00 per million output; Kimi K3.1 Pro Highspeed is $4.00 and $20.00. Cache-hit input is $0.20 on both.

• Cache writes — $2.00 at five-minute TTL and $4.00 at one-hour TTL on Pro; $4.00 and $8.00 on Highspeed.

• Speed — Moonshot says Highspeed produces output two to three times faster. It is the same weights and the same quality target, served for latency rather than throughput economics.

• Quota — in Kimi Code, the Highspeed tier consumes roughly twice the quota for the same work, which is the subscription-side mirror of the doubled token price.

• Context and capability — both carry the 1,048,576-token window, native image and video input, tool calling, structured output and always-on reasoning with low, high and max effort levels. There is no capability tiering between them.

• Best fit — Highspeed for interactive coding and agent loops where a human is waiting; standard Pro for batch generation, long document work and anything where the output is consumed by another process.

The decision rule is therefore about waiting, not intelligence. If a two-to-three-times speedup removes a human idle loop, the doubled price is easy to justify. If it only shortens a batch job that runs overnight, you are paying twice for latency you were not going to feel.

What the API actually accepts

The identifier question matters because the API is strict in ways that are easy to miss. Kimi K3.1 Pro always reasons — there is no switch to turn thinking off — and reasoning_effort takes low, high or max, defaulting to max. Sampling is fixed at temperature 1.0 and top_p 0.95, with penalties at zero; passing other values returns an error rather than being silently clamped. Max completion tokens default to 131,072 and can be raised to 1,048,576.

Two operational consequences follow. First, an eval harness that tunes temperature will fail against this model, not produce a slightly different score. Second, changing reasoning effort mid-conversation invalidates prefix-cache hits, so the cost of exploring effort levels is higher than the token price suggests. Both constraints apply identically to the Highspeed variant.

Access is also gated in a way that catches teams off guard: the API requires a minimum account top-up, and the new-user voucher does not apply. Enterprise administrators have to enable the model, because access is off by default at launch. None of this is unusual for a flagship release, but it is the kind of detail that turns a fifteen-minute integration into a support ticket.

A two-column scoreboard comparing Kimi K3.1 Pro at $2.00/$10.00 with K3.1 Pro Highspeed at $4.00/$20.00 across cache-hit price, speed, context, capability and Kimi Code quota, footnoted that only the Pro and Highspeed IDs exist.

Why the name will keep causing trouble

Model families usually earn a clean naming convention after the fact. The K3.1 series has started in the opposite order: a teaser used the family name as a model name, a code repository used it as an artifact name, and the API used it as a namespace. Readers searching for "Kimi K3.1" will keep landing on pages that either treat it as a model or argue it does not exist. Both are incomplete. It exists as a family, and the Pro is the member.

The practical test is simple, and it generalizes beyond this launch. A model is real when three things line up: a rate-card row with a price, a documented model identifier, and a model card or weight repository. Kimi K3.1 Pro has the first two now and the third promised by November 4. The bare Kimi K3.1 has a repository name and a teaser label, which is not the same thing. When the weights land, check whether the repository is the Pro artifact published under a shorter name or a genuinely different checkpoint. That distinction will matter to anyone planning to self-host.

There is a second reason to be careful with names: they propagate. A model string copied from a forum post into a router config, a cost dashboard or a compliance inventory can outlive the confusion that created it. If a name does not resolve to a documented identifier, the correct move is to fail the deploy, not to guess at the nearest match.

Routing around a name that does not resolve

This is the kind of problem OrcaRouter is built for, though not in the way the marketing usually frames it. One API across 200-plus models is convenient; explicit, resolvable model identifiers are the part that keeps production honest. Our catalogue lists what is actually callable, and today that includes kimi/kimi-k3 at Moonshot's list price with 0% markup. Kimi K3.1 Pro is not in the catalogue at the time of writing, and we would rather say that than let a search result imply otherwise.

Where the routing layer earns its place is in the transition. A routing DSL lets you express a primary model and a fallback in one place, and automatic failover means a provider-side outage or a deprecated identifier does not take the application down with it. When the K3.1 series does land on the catalogue, the change is one string in that policy — not a new SDK, a new key, or a second billing relationship. That is a smaller claim than "we have every model", and it is the one that survives an audit.

OrcaRouter's Kimi K3 model page showing the kimi/kimi-k3 identifier, 1M-token context, $3.00 input and $15.00 output pricing, and a seven-day traffic figure of 1,141.7M tokens.

What to do on October 24

If you want Kimi K3.1 Pro, call kimi-k3.1-pro. If you want it faster and are willing to pay double for latency, call kimi-k3.1-pro-highspeed. If you have kimi-k3.1 in a config, replace it — there is no such model, and the nearest real thing is the Pro identifier.

The one open question is what the November 4 weight release will be called. Until that repository is public, "Kimi K3.1" remains a family name with a teaser attached, and the comparison between it and Kimi K3.1 Pro is a comparison between a label and a product. That is a less satisfying answer than a spec sheet, but it is the accurate one, and it is cheaper to act on now than to discover in production later.