Moonshot 計劃於 2026 年 12 月底退役 Kimi K2：轉用 kimi-k3.1-pro 的變化與預設推理力度成本

TL;DR

Moonshot AI's documentation says that since 2026-10-31 the Kimi K2 series (kimi-k2.6, kimi-k2.7-code and its highspeed variant) is closed to newly registered accounts. Existing accounts keep working, and Moonshot plans to retire every K2 model by the end of December 2026. The named replacement is kimi-k3.1-pro. I did not call any API. This post is built from Moonshot's official pages, one third-party migration write-up that did run requests, a third-party pricing page, and arithmetic of my own. The main points:

1. This is a schedule, not a surprise. The official Model List shows four dated discontinuations between 2025-11-11 and 2026-08-31, spaced 78, 117 and 98 days apart. The K2 wind-down is the next step in that pattern.
2. Changing the model string is not enough. Several sampling parameters are now fixed and return an error if you send any other value, the K2-style thinking switch is gone, and a new reasoning_effort field defaults to "max".
3. The default effort is a cost decision you did not make. Thinking tokens are generated before the visible answer. In my illustrative workload they are 74 percent of the bill at 6,000 thinking tokens per call and 90 percent at 20,000.
4. Effort and cache interact. The docs warn that switching effort levels invalidates prefix-cache hits, so pick a level per session and keep it.
5. Open weights are promised, not shipped. The K3.1 Pro quickstart says full weights will be released by Nov 4. Until they exist, nobody can self-host it as a fallback.

What exactly did Moonshot announce?

The same notice appears on the pricing page and on the Model List page of the Kimi API docs:

Starting October 31, 2026, K2 series models will no longer be available to newly registered users; existing users are not affected. We plan to retire all K2 series models by the end of December 2026.

Three details matter for planning. First, the cutoff is for new registrations, so a team that already has a key will not see anything change today. Second, "end of December" is a plan, not a hard timestamp, and the docs do not give an exact hour or date. Third, the docs name one migration target, kimi-k3.1-pro, and point to its quickstart.

The current model list is short:

If you pinned kimi-k2.6 or kimi-k2.7-code, both are on the closing list.

How often does Moonshot retire models?

The Deprecated Models section of the official Model List gives exact dates. I put them in order and computed the gaps:

The gaps average about 98 days across the three intervals between the four completed discontinuations. That is a small sample from a single vendor, so I would not extrapolate a rule. The practical reading is narrower: a model id on this platform has had a service life measured in months, and the notice period for the K2 closure is about two months from the new-user cutoff to the planned end.

The useful question is how cheaply you can move when a hosted model changes, and that depends on what your code assumes about it.

What breaks when you only change the model name?

Moonshot publishes a parameter reference that compares the K3 series with kimi-k2.7-code and kimi-k2.6. The table below is a condensed copy of it.

The docs define "fixed" precisely: passing any other value returns an error, so the instruction is not to pass the parameter at all. Two consequences stand out.

A request that worked on K2.6 can now fail. If your client library or your own wrapper sets temperature=0.2 for extraction tasks, or sends thinking={"type": "disabled"} for cheap calls, a K3 request is rejected. A third-party migration guide that tested K3.1 Pro through an aggregator on 24 October reports exactly these 400s, including the message invalid temperature: only 1 is allowed for this model and a rejection of disabled thinking. It also reports limits on stop sequences (at most five entries, each at most 32 bytes). I have not reproduced those, and the author notes that the aggregator's behavior differed from Moonshot's own in at least one case, so treat them as a checklist of things to test, not as spec.

Behavior you relied on may be gone. You cannot turn thinking off on K3. If your product used non-thinking mode for latency or cost, the closest lever is reasoning_effort: "low". Also, for multi-turn conversations and tool calls, the docs say to pass the complete assistant message back as-is, including any reasoning_content. A history builder that strips that field is now a bug.

One gain: tool_choice: "required" is supported on K3, which K2.6 and K2.7 Code reject.

Here is a small request adapter that encodes the table. It is a sketch, not a drop-in library.

K3_FIXED = ("temperature", "top_p", "n", "presence_penalty", "frequency_penalty")

def to_k3(req: dict, effort: str = "high") -> dict:
    out = dict(req)
    out["model"] = "kimi-k3.1-pro"
    out.pop("thinking", None)             # K2-only switch
    for key in K3_FIXED:                  # fixed server side: do not send
        out.pop(key, None)
    if effort not in ("low", "high", "max"):
        raise ValueError("reasoning_effort must be low, high or max")
    out.setdefault("reasoning_effort", effort)
    stop = out.get("stop")
    if isinstance(stop, list):            # limits reported by a third party, verify
        assert len(stop) <= 5, "more than 5 stop sequences"
        assert all(len(s.encode("utf-8")) <= 32 for s in stop), "stop > 32 bytes"
    return out

Is reasoning effort really a cost setting?

K3 always reasons. The docs say it "always reasons with Preserved Thinking enabled" and that effort is set with reasoning_effort, default "max". The migration FAQ says to replace model and, if you want an explicit effort, add the field. Read that literally: a team that only swaps the model id runs at max.

How much does that cost? Token billing on the pricing page is "input and output tokens by usage". Reasoning APIs of this kind normally bill thinking tokens as output tokens, so the usage block of your own responses is the thing to check. Moonshot's pricing table is rendered client side, so I could not read the numbers from the docs text. Two independent third-party pages list kimi-k3.1-pro at $2.00 per million input tokens and $10.00 per million output tokens, and I use those figures below. Check the live price list before you budget.

For the thinking length, I have one data point I did not produce: the AIHubMix guide measured K3.1 Pro at low effort on one prompt, three runs, and saw 5,561 to 7,356 thinking tokens. That is a single prompt, not a benchmark, and it says nothing about high or max. I use 6,000 as the anchor and show what happens above it.

Assumed workload (illustrative, not measured): 1,000 calls, each with 8,000 input tokens, 500 visible output tokens, and a varying number of thinking tokens, at $2 in and $10 out per million.

The visible answer, the thing your users read, costs $5.00 per 1,000 calls in every row. What moves the bill is how long the model thinks. If an older K2.6 call in non-thinking mode produced no thinking tokens at all, the same workload moves from $21.00 per 1,000 calls (input plus visible output) to wherever your effort setting lands, which can be a multiple of that. Measure your own distribution before assuming either direction.

Two official levers reduce it. kimi-k3.1-pro and kimi-k3 support batch inference at 60 percent of the standard price, so an overnight job at the 6,000-token row drops from $81.00 to $48.60 per 1,000 calls. Context caching is automatic with a 5-minute default TTL. A third-party page lists cached input at $0.20 per million; if 6,000 of the 8,000 input tokens are a cached prefix, input falls from $16.00 to $5.20 per 1,000 calls and the 6,000-token row to $70.20. The docs also warn that switching effort levels invalidates prefix-cache hits, so a router that picks low for some turns and max for others in the same conversation throws away the cache you were counting on.

A budget guard is a few lines. Log usage for every call and alert on thinking share, not only on total spend.

IN_PRICE, OUT_PRICE = 2.00, 10.00   # USD per 1M tokens, third-party figures, verify

def cost_usd(prompt_tokens: int, completion_tokens: int) -> float:
    return (prompt_tokens * IN_PRICE + completion_tokens * OUT_PRICE) / 1e6

# completion_tokens includes thinking tokens if the provider bills them as output.
# Compare against the visible text length you actually returned:
def thinking_share(completion_tokens: int, visible_tokens: int) -> float:
    return max(0.0, 1 - visible_tokens / completion_tokens)

What should a migration test look like?

A rename is cheap to ship and expensive to debug in production. A small contract test catches most of the issues above before traffic moves. Run the same fixed set of prompts through the old and new ids and compare four things.

1. Request acceptance. Send every request shape your app produces (with stop, with tool_choice, with a system prompt only) and assert HTTP 200. This finds fixed-parameter errors in minutes.
2. Thinking length. Record completion tokens per prompt at each effort level you might use. Pick the level from this table, not from the default.
3. Answer quality on your task. A vendor chart does not replace 50 to 200 of your own labeled cases. Report a pass rate with its sample size.
4. Latency. The AIHubMix author measured the highspeed variant at 1.6 to 1.75 times faster on three runs of one prompt, against Moonshot's stated 2 to 3 times. That is one prompt, but it is a reminder to measure speed on your own prompts, especially since highspeed is listed at twice the price.

Keep the model id and the effort in configuration, never in code. If Moonshot changes the platform again, you want a one-line change and a re-run of the same test.

What about the open weights?

The K3.1 Pro quickstart says the full model weights will be released by Nov 4, and the Model List describes kimi-k3 as an open-source 3T-class model. If the weights do ship, a second route opens: third-party hosts, or your own cluster if you have the memory for a model of that size. When I read the quickstart page on 2026-11-01, it still contained template placeholders such as [xx.x%] where benchmark scores belong, so I would not treat any published K3.1 Pro score as final until the page is finished. I quote no vendor benchmark numbers here for that reason.

FAQ

Is Kimi K2 shut down now?
Not for existing users. Since 2026-10-31 K2 series models are unavailable to newly registered users, and Moonshot says it plans to retire all K2 models by the end of December 2026.

Which model replaces Kimi K2.6 and K2.7 Code?
The docs name kimi-k3.1-pro as the migration target, with kimi-k3 as the previous generation and kimi-k3.1-pro-highspeed as the faster variant.

Do I need to change my code to move from K2.6 to K3?
Yes. Per the parameter reference, replace the model id, remove the K2 thinking configuration, stop sending temperature, top_p, n and the penalty parameters, and pass full assistant messages back including reasoning_content. Set reasoning_effort explicitly.

What is the default reasoning effort on K3?
"max", with "low" and "high" as the other accepted values. Switching levels mid-conversation invalidates prefix-cache hits.

How much does Kimi K3.1 Pro cost?
Third-party pages list $2.00 per million input tokens and $10.00 per million output tokens, with the highspeed variant at twice that. Moonshot's docs state batch inference is billed at 60 percent of the standard price. Confirm on the live price list.

Can I turn thinking off on K3?
No. The thinking parameter is not supported on the K3 series, and a third-party test reports that a disabled setting is rejected. Use reasoning_effort: "low" for faster, cheaper calls.

Further reading

• Shorter outputs, same price: what DeepSeek V4.1-Flash-1017 changes in an agent's bill
• Is open-weight really 90% as good at 10% of the cost? Checking IBM's claim against list prices

Sources

• Kimi API docs: Model List and deprecated models
• Kimi API docs: Model Parameter Reference
• Kimi API docs: Model Inference Pricing
• Kimi API docs: Kimi K3.1 Pro quickstart
• AIHubMix: Kimi K3.1 Pro migration guide, five 400s and one 404
• innFactory: Moonshot Kimi K3.1 Pro pricing, licence, GDPR

Official pages were read on 2026-11-01. Prices are third-party figures and the cost tables are my arithmetic on an assumed workload, not measurements of the model running.