Kimi K2 retires in December: what breaks when you move an agent to K3.1 Pro

Moonshot will retire every Kimi K2 model by the end of December 2026, and the replacement it recommends will break an agent loop tuned for K2. If K2 runs anywhere in your production path, you have about eight weeks to find every call site that sends temperature 0.6, stores only the text of a reply or times out at 30 seconds. Since October 31, new API accounts cannot call K2 at all; existing accounts keep kimi-k2.7-code, kimi-k2.7-code-highspeed and kimi-k2.6 for now, and Moonshot's model list gives no exact day. The target, kimi-k3.1-pro, released on October 23, looks like a model ID swap. In practice it thinks on every call, rejects sampling parameters K2 accepted, costs more per token and is much slower to its first answer token.

The API surface: what now returns 400

The K3.1 Pro quickstart fixes temperature at 1.0, top_p at 0.95, n at 1 and both penalties at 0, and tells you to omit them. K2.6 ran at temperature 0.6 with thinking off, so any wrapper that still hardcodes 0.6 gets an error. AIHubMix's migration write-up hit exactly that: "invalid temperature: only 1 is allowed for this model". Search every call site, not only the main agent. Summarisers, title generators and eval judges are where stale parameters hide.

Thinking cannot be switched off. The quickstart FAQ answers the question with "You can't". The only knob is reasoning_effort with low, high or max, and the default is max. If your K2 path disabled thinking to keep latency down, low is the nearest setting, and it is not the same thing.

The multi-turn contract is stricter. Moonshot says to return the complete assistant message unchanged in conversations and tool loops, not only its content. That means reasoning_content and tool_calls have to survive your message store, and plenty of homegrown agent frameworks persist only the text. They will break on the second turn. Tools declared through a system message with a tools array are not kept by the server, so you resend them on every request. Images must be base64 or uploaded file IDs, because public image URLs are rejected. AIHubMix also reports a 400 for more than five stop sequences and notes that tool_choice "required", which K2.x refused, now works.

Price and latency

The trap is what that table leaves out. Cache writes are now billed as their own line, $2.00 per 1M tokens for the 5 minute tier and $4.00 for the 1 hour tier, and they arrive in a separate usage field. A dashboard that reads only input and output will show K3.1 Pro cheaper than your invoice. The K3.1 Pro prices are Moonshot's, quoted by AIHubMix and matched by Artificial Analysis. The K2.6 figures come from a price tracker listing Moonshot as provider, so put your last K2 invoice next to them before you compute the jump.

The per-token price is the smaller problem. With thinking always on, every call emits reasoning tokens billed as output. AIHubMix measured between 5,561 and 7,356 reasoning tokens on a spot check at low effort. Artificial Analysis measured 130 seconds to the first answer token and 32 output tokens per second in its runs, against a median of about 13 seconds across the models it tracks. An agent that made forty quick K2 tool calls per task will not feel the same.

Plan this as a new model with a new latency budget and a new bill, not as a version bump.

Agent behavior: what I would re-test

Picture the first K3.1 Pro run through a harness built for K2. The 30 second client timeout tuned for K2 fires long before the 130 seconds Artificial Analysis measured to the first answer token, so the task fails before the model says anything. Raise it and the parser breaks next: Moonshot says to parse only message.content against a strict json_schema, never reasoning_content. Then the step count drops, because a model that reasons longer per turn often makes fewer tool calls, which changes your timeout and retry logic. Then output volume: Artificial Analysis counted 110M output tokens across its index run against a median of 73M. So run your own eval set first, at the effort level you intend to pay for. Moonshot calls K3.1 Pro its most capable flagship and Artificial Analysis scores it 46 on its Intelligence Index, but neither tells you how it behaves in your loop.

If speed matters more than price, kimi-k3.1-pro-highspeed is listed at two to three times the speed for double the price. If you route Claude Code or Codex through a compatible endpoint, AIHubMix warns that Moonshot expects every model tier to be set, or the unset ones fail silently. I wrote about the general pattern in model migration reality: the outage you get is rarely the missing model, it is the parameter nobody remembered.

A dated plan

Moonshot gives no exact retirement day and no per-model order, so I would put December 1 in the calendar as the real deadline and work back from it. This week, search every repository for kimi-k2 and log the parameters each call site sends; the summariser or eval judge nobody owns is usually the one still passing temperature 0.6. By mid November, strip the fixed sampling parameters, persist full assistant messages and add the cache-write field to cost tracking. Through the end of November, shadow production traffic to K3.1 Pro at low and high effort and compare cost per completed task, not cost per token. Switch in the first week of December with a second provider configured as fallback, because when K2 disappears there will be no grace period to find the helper that still sends 0.6.