Kimi K2 to K3.1 Pro Migration: The Beginner's Guide (Fix the 400s, Mind the Deadline)
CodexFuse Team · 2026-11-03T13:02:49.064Z · 14 min read min read
If your app still calls a Kimi K2 model, this is your migration window. Moonshot AI closed the K2 series to new sign-ups on October 31, 2026 and will retire it by the end of December 2026, so learning how to migrate kimi k2 to k3.1 pro is no longer optional for anyone with K2 in production. This guide walks through the deadline, the new model IDs, the parameter changes that turn working requests into HTTP 400s, and the cost check you should run before you switch. If you have never used Kimi at all, start with our Kimi beginner guide first and come back here when you are ready to wire up the new model.
What Is the Kimi K2 Shutdown, Exactly?
Moonshot AI is retiring every Kimi K2-series API model by the end of December 2026, and it closed the series to new sign-ups on October 31, 2026. Existing users keep their K2 access through December, but newly registered accounts can no longer call K2 models at all — the official migration path is Kimi K3.1 Pro.
The notice lives on Moonshot's own platform pricing and model-list pages. Trustlist.uk, which read the pages on October 25, 2026, quotes the exact wording: "starting October 31, 2026, K2 series models will no longer be available to newly registered users; existing users are not affected." The K2 IDs covered by the notice are kimi-k2.6, kimi-k2.7-code, and kimi-k2.7-code-highspeed. Note the phrasing: Moonshot says "by the end of December 2026" and has not named an exact day, so treat any specific date you see online as an inference, not an official deadline. If you searched "kimi k2 retired december 2026", that official "by the end of December 2026" wording is the one to trust.
This is not the first K2 cut. The original K2 preview models (kimi-k2-0711-preview, kimi-k2-0905-preview, kimi-k2-turbo-preview and two thinking variants) were discontinued on May 25, 2026, and kimi-k2.5 plus the whole moonshot-v1 family retired on August 31, 2026 — those already fail, and their documented replacement is kimi-k3.1-pro. The pattern is consistent: Moonshot keeps roughly one generation alive, then points everyone at the current one. Because the retirement is deadline-driven, search interest spikes through November and December as teams discover their K2 calls failing.
What Do You Actually Need to Change?
The kimi k3.1 pro migration is five changes, and nothing else. Swap the model ID, delete the sampling and thinking parameters K3.1 Pro does not accept, pick a thinking effort level, re-run your budget math, and retest every path that touches the model.
- Change the model ID to kimi-k3.1-pro — or kimi-k3.1-pro-highspeed if you need the faster variant and can pay for it. There is no plain "K3.1" model, so do not guess at shorter names.
- Remove temperature, top_p, and the presence and frequency penalties from your requests. K3.1 Pro fixes them (temperature 1.0, top_p 0.95, penalties 0) and rejects any other value with a 400 error.
- Delete the thinking parameter — it is a K2.x-only request parameter. If you want anything other than the most expensive thinking default, set the new top-level reasoning_effort to "low" or "high".
- Re-run your budget math. K3.1 Pro lists at $2 input and $10 output per million tokens against K2.6's $0.95 and $4.00 — and thinking tokens bill as output tokens.
- Retest everything: tool-calling loops, image uploads, stop sequences, and web-search features, because several K2-era parameters are gone.
Why Am I Getting 400 Errors on K3.1 Pro?
The most common cause is a temperature value left over from K2. K3.1 Pro fixes temperature at 1.0, top_p at 0.95, n at 1, and both penalties at 0 — send anything else and Moonshot returns a 400 error. AIHubMix's live check on October 24, 2026 confirmed it: sending temperature 0.2 produced the exact error "400 invalid temperature: only 1 is allowed for this model". K2.6 code is the usual suspect because K2.6's own fixed temperature in non-thinking mode was 0.6, so plenty of production codebases hard-code temperature 0.6 or lower for "deterministic" output. The fix is to delete the parameters entirely — Moonshot's docs say to leave them out of requests, not to set them to the fixed values.
Three other 400s trip up migrators. First, sending thinking: {"type": "disabled"} in extra_body is rejected on K3.1 Pro, which only supports thinking mode — Moonshot's docs are explicit that requests with thinking disabled are rejected. Second, a leftover thinking: {"type": "enabled"} may still return 200 in spot checks, but the docs call thinking a K2.x-only parameter, so delete it anyway; it is dead weight. Third, web_search.search_context_size returns "400 web_search.search_context_size is not supported" — that K2-era search parameter is gone. And if you use stop sequences, know the cap carried over from the K3 series: at most 5 stop sequences, each no longer than 32 bytes, or you get "stop array too long. Expected an array with maximum length 5..." or "stop sequence must not be longer than 32, but got 33 instead".
If you arrived here searching "fix kimi k3.1 pro 400 error", the table below maps each error text to its cause and its fix.
| 400 error text | Cause | Fix |
|---|---|---|
| invalid temperature: only 1 is allowed for this model | Leftover temperature (or top_p, penalties, n) from K2 code | Delete all sampling parameters from the request |
| Requests with thinking disabled are rejected | thinking: {"type": "disabled"} in extra_body | Delete the thinking parameter; set reasoning_effort instead |
| web_search.search_context_size is not supported | K2-era search parameter | Remove it; use the current search tooling |
| stop array too long / stop sequence must not be longer than 32 | More than 5 stop sequences, or one over 32 bytes | Trim to 5 sequences of 32 bytes or fewer |
What Is Always-On Thinking, and Why Is the Default "Max"?
K3.1 Pro is a thinking model that cannot stop thinking: there is no off switch, and the new top-level reasoning_effort parameter defaults to "max", the most expensive setting, even when you send nothing at all. The valid values are "low", "high", and "max" — that is the whole menu. There is no medium, no off, and no none: Kimi Code returns a 400 for off, none, disabled, and unknown values, and a tool set to "medium" silently maps to high while "xhigh" silently maps to max.
The important catch is that low effort is still thinking. AIHubMix's spot check ran a 600-word prompt at low effort and still generated 5,561 to 7,356 thinking tokens. Those tokens bill as output tokens, so effort choice is a direct cost lever: AIHubMix's July test of Kimi K3 found 73% of all completion tokens were thinking tokens. Set reasoning_effort explicitly on every request, or you are silently paying for max. One vendor-docs inconsistency to know about: Moonshot's API docs list the default as max, while kingy.ai's November 2, 2026 coverage reports that Kimi Code's docs now default to high — check the docs for whichever surface you actually use.
Thinking also changes how you write agent loops. The reasoning streams back as reasoning_content, and Moonshot's "Preserved Thinking always on" behavior means you must pass the complete assistant message back whole — reasoning content plus tool calls, returned as-is — in multi-turn and tool-calling loops. Truncating or reordering it breaks the chain. This is the same discipline agent frameworks already teach: if you run agents on K3.1 Pro, our Claude Code beginner guide covers the harness style Moonshot itself used for the model's benchmark runs, and Aider beginner guide shows how agent loops pass model output back in — the exact mechanics Preserved Thinking requires.
What Are the New Model IDs?
The API IDs are kimi-k3.1-pro and kimi-k3.1-pro-highspeed — hyphens everywhere, lowercase, no spaces, no underscores. There is no plain "K3.1" model, so do not shorten the name and hope the API guesses. Kimi Code, Moonshot's coding CLI and subscription product, uses shorter IDs — k3.1-pro and k3.1-pro-highspeed — which is a common source of copy-paste mistakes when moving a prompt from the CLI into API code.
The highspeed spelling deserves its own warning. A mistyped Highspeed ID in Kimi Code can silently fall back to K2.8 Preview without thinking — no speedup, no error, just a worse model answering quietly (AIHubMix, citing Moonshot's docs; this behavior is scoped to Kimi Code). If your "highspeed" responses feel slow and thoughtless, check the ID character by character before you blame the network. Two more ID-adjacent rules from Moonshot's Kimi Code docs: do not switch models or effort levels in the middle of an existing session, because that invalidates the prefix cache, and remember that the K2 IDs under the retirement notice are kimi-k2.6, kimi-k2.7-code, and kimi-k2.7-code-highspeed — search your codebase for all three spellings, not just "k2".
Kimi K2 vs K3.1 Pro: What Changed?
If you are comparing "kimi k2 vs k3.1 pro changes", the table below is the whole migration in one glance.
| What | Kimi K2 | Kimi K3.1 Pro |
|---|---|---|
| Context window | 262,144 tokens | 1,048,576 tokens, flat pricing across the window |
| Thinking | Optional on K2.6; always-on on K2.7 Code | Always-on with effort levels low, high, max (default max) |
| Temperature | Fixed per mode on K2.6 (1.0 thinking, 0.6 non-thinking) | Fixed 1.0; anything else is a 400 |
| Thinking parameter | extra_body object (K2.x) | Deleted; replaced by top-level reasoning_effort |
| tool_choice="required" | Not supported on K2.6 | Supported |
| Images | Public URLs worked on K2 | Base64 data URLs or ms:// file IDs only; video via the files API |
| List price | $0.95 input / $4.00 output per 1M | $2.00 input / $10.00 output per 1M |
| max_completion_tokens | Standard limits | Defaults to 131,072, up to 1,048,576 — keep it generous, thinking eats the budget |
What Does the Migration Cost?
More than K2 — the migration raises the rate card. K3.1 Pro lists at $2.00 input and $10.00 output per million tokens against K2.6's $0.95 input and $4.00 output, which is 2.1 times on input and 2.5 times on output. The one line that gets dramatically cheaper is cached input: $0.20 per million on K3.1 Pro. These figures come from AIHubMix's October 24, 2026 read of Moonshot's official price list, independently corroborated by OpenRouter and NEAR AI listings, and prices exclude taxes — re-check Moonshot's pricing page before you budget, because they move.
| Per 1M tokens | K2.6 | K3.1 Pro | K3.1 Pro Highspeed | K3 (for reference) |
|---|---|---|---|---|
| Input | $0.95 | $2.00 (2.1× K2.6) | $4.00 (2× Pro) | $3.00 |
| Cached input | $0.16 | $0.20 | $0.20 | $0.30 |
| Output | $4.00 | $10.00 (2.5× K2.6) | $20.00 (2× Pro) | $15.00 |
| Cache write | — | $2.00 (5-min TTL) / $4.00 (1-hour TTL) | $4.00 / $8.00 | — |
Three cost levers matter more than the headline rates. First, cache aggressively: K3.1 Pro is cheaper only against K3 ($3/$15 — K3.1 Pro is exactly a third cheaper on every line), so if you are on K2 today your bill goes up unless cached input carries it. Second, run batch inference where you can — Moonshot prices batch at 60% of the standard rate for K3.1 Pro and K3. Third, remember that thinking tokens bill as output, and K3.1 Pro's max-effort default means your first migrated bill can surprise you before you set reasoning_effort. One more note for teams weighing alternatives: K3 remains available and nothing forces you off it (capitalandcompute.net), so compare your own K3 bill before assuming K3.1 Pro is the mandatory next step.
What Are the Image, Tool, and Stop-Limit Gotchas?
Public image URLs do not work on K3.1 Pro — send base64 data URLs or ms:// file IDs from the files API, and put video through the files API too. Dynamic Tool Loading is supported on K3.1 Pro and K3 only; on K2.6 it errors with "tokenization failed", so if your agent framework uses it, the migration is mandatory, not optional. Two account-level details from the quickstart guides: API access unlocks after a top-up of at least $1, and Moonshot offers Zero Data Retention for API customers.
Five Beginner Mistakes to Avoid
Most migration failures are one of five copy-paste errors, and every one of them is avoidable in a single pass over your code.
| Mistake | What happens | The fix |
|---|---|---|
| Leaving temperature 0.6 or 0.2 in the request | 400: only 1 is allowed for this model | Delete temperature, top_p, and both penalties |
| Sending thinking: {"type": "disabled"} | 400: thinking-disabled requests are rejected | Delete the thinking parameter; set reasoning_effort |
| Typing "high_speed" or "HighSpeed" | No speedup; in Kimi Code a silent fallback to K2.8 Preview | Use the exact ID kimi-k3.1-pro-highspeed |
| Switching models mid-session | Prefix cache invalidated, slower and costlier calls | Restart the session when you change models or effort |
| Assuming the open weights equal the API model | Moonshot promised full weights by November 4, but they were not on Hugging Face as of November 3 — and "cyber-related data" was removed from training, so the weights may not behave exactly like the API on security tasks | Treat weights as a separate evaluation track, not a drop-in |
Sources
Every fact in this guide comes from a page fetched for this article on November 3, 2026. Vendor claims are Moonshot's own; prices were verified at write time and should be re-checked before you budget.
- AIHubMix — "Migrating to Kimi K3.1 Pro: Fix the 400s, Mind the Max-Effort Default, and Don't Mistype Highspeed" (aihubmix.com/blog/migrating-to-kimi-k3-1-pro-fix-the-400s-mind-the-max-effort-default-and-dont-mistype-highspeed) — 400-error live checks, effort defaults, highspeed spelling, fixed sampling
- AIHubMix — "Kimi K3.1 Pro vs K3: What Changed, What It Costs, and Who Should Switch" (aihubmix.com/blog/kimi-k3-1-pro-vs-k3-what-changed-what-it-costs-and-who-should-switch) — pricing table, K3 comparison, thinking-token share
- Trustlist.uk — "Kimi API: K2 Models Closed to New Users 31 October, Retired End of December 2026" (trustlist.uk/news/kimi-api-k2-models-closed-to-new-users-31-october-retired-end-of-december-2026) — Moonshot notice text, K2 IDs, earlier retirements
- ki-ai.chat — "Kimi K2.7 Code: API, Pricing, Limits and Migration" (ki-ai.chat/models/kimi-k2-7-code/) — K2.6/K2.7 pricing, fixed sampling values, DTL error
- ki-ai.chat — "Kimi K3.1 Pro: Pricing, Features and How to Use It" (ki-ai.chat/models/kimi-k3-1-pro/) — migration checklist, model reference
- Kriosity.in — "Kimi K3.1 Pro API: Open Weights and K2 Retirement" (kriosity.in/blog/kimi-k3-1-pro-api-open-weights-k2-retirement) — quickstart details, image uploads, $1 top-up, Zero Data Retention, open-weights promise
- Moonshot platform docs — platform.kimi.ai/docs (pricing, thinking models, chat API reference) — reasoning_effort enum and defaults, fixed parameters, Preserved Thinking
- Apex Logic — "Kimi K3.1 Pro API: Pricing, Open Weights Date and Python Code" (apex-logic.net/news/kimi-k3-1-pro-api-open-weights-2026) — API reference, K2 cutoff section
- Mer.vin — "Kimi K3.1 Pro and Highspeed: API, Pricing and Benchmarks" (mer.vin/news/kimi-k3-1-pro-and-highspeed-api-pricing-and-benchmarks/) — launch coverage, highspeed benchmarks
- Kingy.ai — Kimi K3.1 Pro coverage, November 2, 2026 (kingy.ai) — pricing corroboration, Kimi Code effort default
- OpenRouter — Kimi K3.1 Pro model page (openrouter.ai) — price corroboration $2/$10/$0.20
- NEAR AI — Kimi K3.1 Pro listing — price corroboration
Frequently Asked Questions
When exactly does Kimi K2 shut down?
Moonshot says "by the end of December 2026" and has not named an exact day. New sign-ups lost K2 access on October 31, 2026, and existing users keep access through December. Treat any specific calendar date you see online as an inference and migrate before the year closes.
Will my existing Kimi API key stop working?
Your key keeps working — it is the model behind it that changes. After you top up at least $1 to unlock API access, the same key calls kimi-k3.1-pro. K2 calls will fail once the retirement lands, so update the model ID before then.
How do I fix "invalid temperature: only 1 is allowed for this model"?
Delete temperature, top_p, and the presence and frequency penalties from your request entirely. K3.1 Pro fixes them at 1.0, 0.95, and 0, and any other value is rejected with a 400.
Is Kimi K3.1 Pro cheaper than Kimi K2?
No — input lists at 2.1 times and output at 2.5 times K2.6's rates. K3.1 Pro is cheaper only against Kimi K3, which lists at $3 input and $15 output. Cache input at $0.20 per million and set reasoning_effort explicitly to keep the bill down.
Can I download the K3.1 Pro weights instead of using the API?
Moonshot has promised the full open weights by November 4, but they were not published on Hugging Face as of November 3. Even when they land, Moonshot says "cyber-related data" was removed from both training stages, so the weights may not behave exactly like the API model on security tasks — evaluate them as a separate track.
