Kimi K2 closes in December: what moving to K3.1 Pro changes, and what the default reasoning effort costs

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: 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. 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". 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. Effort and cache interact. The docs warn that switching effort levels invalidates prefix-cache hits, so pick a level per session and keep it. 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: Model id What the docs say Context kimi-k3.1-pro First model of the K3.1 series, 3T-class, native vision 1M tokens kimi-k3.1-pro-highspeed Same model, about 2-3x the speed 1M tokens kimi-k3 Previous flagship, 2.8 trillion parameters 1M tokens kimi-k2.7-code (+ highspeed) Dedicated coding model, closing 256K tokens kimi-k2.6 Vision and text, thinking and non-thinking, closing 256K tokens 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: Date What was discontinued Days since previous 2025-11-11 kimi-thinking-preview n/a 2026-01-28 kimi-latest 78 2026-05-25 The older kimi-k2 ids (kimi-k2-0905-preview, kimi-k2-0711-preview, kimi-k2-turbo-preview, kimi-k2-thinking, kimi-k2-thinking-turbo) 117 2026-08-31 kimi-k2.5 and the whole moonshot-v1 family 98 2026-10-31 kimi-k2.6 and kimi-k2.7-code closed to new users 61 end of Dec 2026 (planned) All remaining K2 models 61 if Dec 31 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. Parameter K3 series kimi-k2.7-code kimi-k2.6 temperature Fixed at 1.0 Fixed at 1.0 1.0 thinking, 0.6 non-thinking top_p Fixed at 0.95 Fixed at 0.95 Fixed at 0.95 n Fixed at 1 Fixed at 1 Fixed at 1 presence_penalty, frequency_penalty Fixed at 0 Fixed at 0 Fixed at 0 thinking Not supported Only {"type":"enabled","keep":"all"} enabled, disabled, or keep all reasoning_effort low, high, max (default max) Not supported Not supported tool_choice auto, none, required required not supported required not supported 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)