Migrating to Kimi K3.1 Pro: Fix the 400s, Mind the Max-Effort Default, and Don't Mistype Highspeed

Kimi K3.1 Pro is live in Kimi Code, on Moonshot's API as kimi-k3.1-pro, and on AIHubMix under the same ID. Moonshot gives it the same parameter constraints as Kimi K3, so code that already runs on K3 should move with a model-ID change and a fresh session. Code written for K2.x now has a deadline on Moonshot's platform: Moonshot closes the K2 series to newly registered users there on 31 October 2026 and plans to retire it by the end of December. That code is also the most likely to break, because it tends to send a temperature or switch thinking off, and neither works on K3.1 Pro. And code that never set an effort level runs at max, which costs more tokens than you may expect and, in Kimi Code, more quota than K3 did.

This post lists what breaks loudly (the 400s), what breaks quietly (the bill, the cache, the Highspeed ID), and how to set up Claude Code and Codex for K3.1 Pro through AIHubMix. K3.1 Pro's rules come from Moonshot's Kimi Code model docs and its model parameter reference, which gives both K3.1 Pro IDs "the same parameter constraints as kimi-k3". Rules labelled as K3's come from Moonshot's K3 guides and haven't been re-checked on K3.1 Pro. Error texts are quoted from the docs, from public reports, from AIHubMix's July test of K3, and from AIHubMix's K3.1 Pro checks on 24 October 2026. Those checks covered the main IDs and the coding-channel IDs coding-kimi-k3.1-pro and coding-kimi-k3.1-pro-highspeed. Each claim says where it comes from.

Which path are you on?

On Moonshot's API and on AIHubMix, the IDs are kimi-k3.1-pro and kimi-k3.1-pro-highspeed. In Kimi Code they're k3.1-pro and k3.1-pro-highspeed. A client config seen on 21 October mapped k3 and kimi-for-coding to a k3.1 model, but the Kimi Code docs now list k3 as K3 and kimi-for-coding as K2.8 Preview, so pick K3.1 Pro explicitly. Your plan matters too: in Kimi Code, K3.1 Pro needs Plus or above (Pro for the 1M context), and Highspeed needs Pro or above. On legacy plans that's Moderato and above, and Allegretto for the 1M context and for Highspeed.

The K2 dates are Moonshot's. From 31 October 2026, K2 series models are no longer available to newly registered users, and all of them are due to retire by the end of December 2026. Moonshot hasn't announced a retirement date for K3. AIHubMix still listed K2.6 and K2.7 Code on 24 October, with no retirement date.

The loud failures

Thinking switched off: HTTP 400, or no reasoning at all

What you'll see: an HTTP 400 in Kimi Code. Moonshot's Kimi Code docs say K3.1 Pro models "only support thinking mode. Requests with thinking disabled are rejected." The docs don't quote the error body. On Moonshot's API, K3.1 Pro takes K3's constraints, and K3 always reasons. Through AIHubMix there's no 400: on 24 October, thinking: {"type": "disabled"} returned 200 with no reasoning in the response, on both main IDs over Chat Completions and on kimi-k3.1-pro over Messages. There it's a quiet failure, so check responses for missing reasoning.

Where it comes from: K2.x code that turned thinking off to answer faster, for example with extra_body={"thinking": {"type": "disabled"}}, and tools that send an effort of off, none or disabled (next section).

Fix: remove the switch. To keep thinking short, send reasoning_effort: "low" instead.

A leftover "enabled" block is a different case. AIHubMix's 24 October check sent K2.x's thinking: {"type": "enabled"} to K3.1 Pro and got 200, on the main IDs and on the coding channel. Moonshot's docs call thinking "a K2.x-only request parameter", and a third-party troubleshooting guide names a leftover block as a cause of 400s after a K2.x to K3 switch, so delete it anyway.

If you keep K2.7 Code as a fallback tier until it retires, keep its thinking on. Moonshot's Claude Code guide documents 400 invalid thinking: only type=enabled is allowed for this model for K2.7 Code with thinking turned off.

Effort values: off, none and unknown values return 400 in Kimi Code

What you'll see: in Kimi Code, an HTTP 400 when the effort is off, none, disabled or a value Kimi Code doesn't recognise. K3.1 Pro has three levels, low, high and max. Moonshot's Kimi Code docs map what third-party tools send onto them:

Moonshot's API documents only low, high and max for K3.1 Pro, with max as the default, and doesn't describe a mapping. On AIHubMix, low, medium, high, max and xhigh all returned 200 on all four K3.1 Pro IDs on 24 October. On kimi-k3.1-pro, off and an unknown value returned 200 too, with reasoning, and none returned 200 with no reasoning at all. On AIHubMix these fail quietly, not with a 400.

The quiet half: there is no medium level. A tool set to medium gets high, and one set to xhigh gets max, the most expensive level.

Fix: send low, high or max explicitly, and check what your tool actually puts on the wire.

"invalid temperature: only 1 is allowed for this model"

What you'll see: 400 invalid temperature: only 1 is allowed for this model. AIHubMix's 24 October check got exactly this from kimi-k3.1-pro and kimi-k3.1-pro-highspeed when it sent temperature: 0.2. The same text had been reported against Moonshot's API for K3 on 3 October 2026, and against the Kimi Code endpoint for k3 on 21 October.

Why: Moonshot's parameter reference gives K3.1 Pro K3's constraints: temperature fixed at 1.0, top_p at 0.95, n at 1 and both penalties at 0, and other values return an error. K2.6 had a fixed value too, 0.6 with thinking off, so code that still sends 0.6 is the usual suspect.

The exception that hides it: AIHubMix's coding channel accepted temperature: 0.2 in the same check. Code tested only there can still break on the main IDs or on Moonshot's API.

The trap that hides it further: many frameworks spot Kimi models by a kimi- prefix and strip temperature for them. Kimi Code's k3.1-pro and k3.1-pro-highspeed don't carry that prefix, and neither do AIHubMix's coding-channel IDs, which start with coding-. A Hermes Agent issue found exactly this on K3. The main chat path omitted temperature, but a helper call to k3 still sent one and got the 400 every time.

Fix: don't send temperature, top_p, n, presence_penalty or frequency_penalty at all. Match on the model family, not on a name prefix.

To check a route, send one request with a temperature:

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3.1-pro", "temperature": 0.2, "messages": [{"role": "user", "content": "hi"}]}'

On 24 October this returned the 400 above. Run it against every model ID your code uses: the coding channel answered the same request with 200.

stop limits

What you'll see: AIHubMix's July test of K3 returned these two messages:

• Invalid request: stop array too long. Expected an array with maximum length 5, but got an array with length 6 instead
• Invalid request: stop sequence must not be longer than 32, but got 33 instead

Why: K3 accepts at most five stop sequences, each up to 32 bytes, and the Messages API applies the same checks to stop_sequences. Moonshot gives K3.1 Pro the same parameter constraints, so expect the same limits.

Fix: trim the list. Note that 32 bytes is fewer than 32 characters in Chinese or Japanese.

Codex on Moonshot's API: "web_search.search_context_size is not supported"

What you'll see: 400 web_search.search_context_size is not supported, quoted from Moonshot's Codex guide for K3.1 Pro. Through AIHubMix's coding channel, a Responses request with that field returned 200 on 24 October, so this error comes from Moonshot's own endpoint.

Fix: remove search_context_size from your Codex config or tool definition. Codex doesn't send it by default.

The quiet failures

These don't return errors. They show up later, on the bill, in your plan's quota, or in the output quality.

Effort and sessions

• The default is max, and in Kimi Code that's new. K3.1 Pro defaults to max. In Kimi Code, K3 defaulted to high, so a session that never sets an effort now thinks harder, uses more tokens and spends quota faster. On Moonshot's API, both K3 and K3.1 Pro default to max. Thinking bills as output: in AIHubMix's July one-prompt game build on K3, 73% of the 74,994 completion tokens were thinking.
• Low effort can still mean thousands of thinking tokens. In an AIHubMix spot check on 24 October, a prompt asking for a 600-word explanation made K3.1 Pro reason for 5,561 to 7,356 tokens at low before it answered, and one run hit the 8,192-token cap. K3 reasoned for 3,013 to 7,051 tokens on the same prompt, so this isn't new with K3.1 Pro, but low isn't a cheap mode on either; leave max_completion_tokens generous. That's one prompt and three runs per model on AIHubMix's main IDs, so measure on your own workload.
• Switching to K3.1 Pro inside an old session costs quality. Moonshot's Kimi Code docs advise against switching to the new models "within an existing K3 series, K2.8 Preview, or K2.7 Code Highspeed session": it degrades output quality and reduces cache hits. Start a new session.
• Changing model or effort invalidates the cache. Moonshot's Kimi Code docs say so for both, and K3's docs said switching effort "invalidates prefix-cache hits". Pick the model and the level when the session starts.

Highspeed

• A mistyped Highspeed ID buys you a slower model. In Kimi Code, a wrong Highspeed ID "silently falls back to K2.8 Preview without thinking — no speedup." Copy the ID exactly, and check which model your logs show.
• Highspeed only speeds up model output. Moonshot puts K3.1 Pro Highspeed at about 2–3× the speed of K3.1 Pro, with identical capabilities. In AIHubMix's spot check on the main IDs (effort low, three runs each), its output ran about 1.6–1.75× Pro's speed. Tool calls and scripts don't get faster at all, so in a turn dominated by reading files and running tests the gain is small, while Kimi Code plans count about twice the quota.

Protocols

• Proxies can change behaviour. Moonshot's Kimi Code docs warn: "Protocol translation through proxy tools may cause model behavior to vary." Give each tool the protocol it speaks: Messages for Claude Code, Responses for Codex. AIHubMix serves both K3.1 Pro IDs on Chat Completions and Messages. Responses is the gap: on 27 October it returned 404 The model kimi-k3.1-pro is not available on this endpoint for the main IDs, and only the coding channel answers there. In its 24 October checks the reasoning came back on each protocol tested, as reasoning_content, as a reasoning item and as thinking blocks.
• Structured output on the Messages API changed for the better. In AIHubMix's July test on K3, /v1/messages ignored a schema and returned free text. On 24 October, the same kind of request to K3.1 Pro, with a JSON schema in output_config.format and a prompt that didn't ask for JSON, returned {"city":"Paris"} on all four IDs. That's a one-field schema, so validate the output before you move JSON back to Messages. July's other Messages quirk, a stop-sequence hit returned as end_turn with stop_sequence: null, wasn't re-tested.

Long requests

• Short timeouts fail even modest requests. In the spot check, K3.1 Pro's full answers at low took 80 to 99 seconds. A non-streaming client with a 60-second timeout would have failed every run, and a retry would pay for the same thinking again. On Moonshot's API, K3.1 Pro's default output limit is 131,072 tokens, up to 1,048,576, and AIHubMix's July game build on K3 ran 2,541 seconds in one request. Stream, and set timeouts in minutes.

Carried over from K3's guides

These come from K3's guides:

• Dropping reasoning_content degrades multi-turn quality. The full assistant message, including reasoning_content and tool_calls, has to go back unchanged. Code that keeps only content still runs, but Moonshot warns of unstable output quality.
• Dynamic tools vanish if you drop their message. K3 lets you load tools mid-conversation through a system message with no content. The server doesn't keep it, so it has to be resent with every request. On AIHubMix this works over Chat Completions: on 24 October, kimi-k3.1-pro called a tool injected this way. In AIHubMix's July K3 test, the Messages API ignored an injected tool.

Billing rules that are easy to miss

The prices below are from Moonshot's official price list, per million tokens. Cache writes are billed by TTL: 5 minutes by default, or 1 hour.

K3.1 Pro is a third cheaper than K3 on every line, and Highspeed costs exactly twice as much as Pro on everything except cached input. As with K3, a 5-minute write costs the same as uncached input: Moonshot says the write cost was already part of the input price, so requests on the default TTL cost no more than before.

A lower rate doesn't guarantee a smaller bill. Take AIHubMix's July one-prompt game build on K3: 74,994 output tokens, with 5,000 input tokens assumed. At the same token counts, it costs about $1.14 on K3, about $0.76 on K3.1 Pro (5,000 × $2.00 + 74,994 × $10.00, per million), and about $1.52 on Highspeed. Token counts vary with the prompt (the spot check put K3.1 Pro and K3 in the same range at low), so measure before you budget.

AIHubMix passes the cache TTL through: on 24 October, a Messages request with a top-level cache_control TTL of 1h reported its write as 1-hour cache tokens, and a Chat Completions request with prompt_cache_options was accepted.

• Caching is automatic. On K3 the default TTL is 5 minutes. In AIHubMix's 24 October checks, a repeated 93-token prompt came back fully cached on the coding channel but not on the main IDs. With a 7,658-token prompt, the second call to kimi-k3.1-pro came back with 7,424 cached tokens, over both Chat Completions and Messages.
• The 1-hour TTL costs $2.00 more per million tokens to write on K3.1 Pro ($4.00 against $2.00). Each hit saves $1.80 against uncached input, so by the arithmetic in Moonshot's caching guide, it pays off from the second hit.
• The TTL is locked at first write (K3). You can't upgrade an entry from 5 minutes to an hour. It has to expire first.
• Cost dashboards need a new field (K3). Cache writes appear as prompt_tokens_details.cache_write_tokens in Chat Completions, input_tokens_details.cache_write_tokens in Responses, and cache_creation_input_tokens in Messages.
• Reasoning is output. On K3, thinking tokens bill at the output rate at every effort level. Moonshot's price list shows no separate reasoning price for K3.1 Pro.

Steps that lower the bill:

1. Set reasoning_effort per workload instead of inheriting max. Try low for lookups and classification, and high for routine coding.
2. Keep the model and the effort fixed per session, and start a new session when you change either.
3. Put the stable parts first: system prompt, tool definitions, repository context. Then the changing turn.
4. Use Highspeed where waiting on model output is the bottleneck, not for loops dominated by tool calls.
5. Watch the share of thinking in completion tokens. If it stays above half on simple tasks, lower the effort.

Agents with real permissions

The Hermes Agent issue shows how a migration bug becomes a safety bug. Its "smart approval" classifier called k3 with a temperature, and every call returned 400. In the reporter's words, the classifier "escalates (fail-open) on every call": the safety check stopped doing its job, and nothing in the main chat looked wrong.

K3.1 Pro keeps that trigger and adds one. Classifier calls are exactly the ones teams make fast and cheap by setting a low temperature or switching thinking off, and on K3.1 Pro neither works: a temperature can return a 400 on every call, and on AIHubMix a thinking-off request came back with no reasoning. If a safety check runs on K3.1 Pro, use reasoning_effort: "low" for speed, decide what an API error does, and make it fail closed.

A few more things matter for agents that act on their own:

• Forced tool calls work. K3.1 Pro supports tool_choice: "required", which K2.x rejected, so a K2.x workaround for forcing a tool call can go.
• Built-in web search isn't production-ready (K3). Moonshot's K3 guide says its web search "is being updated and is not recommended for production workflows in the near term". Treat it the same way on K3.1 Pro until Moonshot says otherwise. Through AIHubMix, a K3.1 Pro search loop didn't complete on 24 October: the model asked for $web_search, and sending the result back returned 400 Invalid request: tokenization failed.
• Image inputs need base64. K3 doesn't fetch public image URLs, and on 24 October kimi-k3.1-pro on AIHubMix rejected one with 400 Invalid request: unsupported image url, so an agent passing screenshot links gets an error. Moonshot's other option, a file ID from its own file upload, isn't served by AIHubMix: an ms:// reference returned 404. A base64 image worked. K3.1 Pro also takes video input in Kimi Code.

Coding tools: Claude Code and Codex

Claude Code uses the Anthropic Messages API and Codex uses the Responses API. AIHubMix serves kimi-k3.1-pro on Messages; on Responses it still returned 404 for that ID on 27 October, so the Codex section below points at coding-kimi-k3.1-pro. Moonshot's own Codex guide also connects Codex to K3.1 Pro over Responses. Install and base configuration are covered in AIHubMix's evergreen guides. Below is only what changes for K3.1 Pro.

Any effort value a tool sends beyond the three is mapped as in the effort table above.

Claude Code

Follow the Claude Code settings.json guide. Then set every model tier, not just the main one:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://aihubmix.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-your-aihubmix-key",
    "ANTHROPIC_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3.1-pro",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3.1-pro"
  }
}

Known issues, from Moonshot's Kimi Code docs, its Claude Code guide (written for K3) and AIHubMix's tests:

• Start a new session. Don't switch a running K3 session to K3.1 Pro. Open a new one, so the cache and the output quality start clean.
• Unset tiers fail silently. Claude Code uses different tiers for the main chat, summaries and sub-agents. Moonshot warns that configuring only some of them makes the rest "fail silently". You can point the Haiku tier at a cheaper model for background work.
• Stale settings win. Old values in the env block of ~/.claude/settings.json override variables exported in your shell.
• 1M context. Moonshot's K3 guide uses kimi-k3[1m] so Claude Code treats the window as 1M. kimi-k3.1-pro[1m] works the same way through AIHubMix: Claude Code drops the suffix before sending, and AIHubMix answered the resulting request, 1M-context header included, on 24 October. Only Claude Code understands the suffix. Sent as a model ID from any other client, kimi-k3.1-pro[1m] returns a 400.
• Effort. K3.1 Pro already defaults to max, the level Moonshot's K3 guide recommended with CLAUDE_CODE_EFFORT_LEVEL=max. For routine work, high spends fewer tokens. Whatever level Claude Code sends is mapped as in the effort table, and AIHubMix accepted all five tested values.
• Highspeed tiers. If you point a tier at kimi-k3.1-pro-highspeed, copy the ID exactly. On Kimi Code, a typo falls back silently; on AIHubMix, a mistyped ID returns a 400.

Codex

Codex only speaks the Responses API, so wire_api = "responses" is required. The Codex config.toml guide covers the rest. Because kimi-k3.1-pro still returns 404 on /v1/responses (checked 27 October), point Codex at the coding-channel ID, which AIHubMix labels an evaluation preview rather than a production route:

model = "coding-kimi-k3.1-pro"
model_provider = "aihubmix"
model_context_window = 1048576
model_reasoning_effort = "high"

[model_providers.aihubmix]
name = "AIHubMix"
base_url = "https://aihubmix.com/v1"
env_key = "AIHUBMIX_API_KEY"
wire_api = "responses"

• Declare the context window. Without model_context_window, Codex falls back to default metadata for a model it doesn't know. Moonshot's Codex guide calls the resulting Model metadata for coding-kimi-k3.1-pro not found warning expected and harmless.
• Effort. Codex's own levels include medium and xhigh. Per the Kimi Code mapping they run as high and max, and AIHubMix accepted both on 24 October. Set low, high or max so you know which level you pay for.
• No search_context_size. If your config sets it, remove it (see the loud failures).
• Restart after edits. Codex reads config.toml only at startup. If CC Switch manages your Codex config, it may overwrite your edits.

A 15-minute smoke test

Run this once per tool, in a small repository with a test suite:

1. Start a fresh session on K3.1 Pro. Don't continue one that ran on K3 or another model.
2. Ask: "Add a unit test for one function in this repo, run the tests, and fix anything that fails."
3. Success looks like this: the model reads files and runs the tests (tool calls work). It continues after seeing the results, which shows reasoning and tool results are being passed back. It ends with green tests, and there's no 400 anywhere in the session.
4. In your AIHubMix usage log, check that the model ID is the one you set, and that later requests show cached input tokens for the stable prefix. If they never do, something in your prefix changes every turn.
5. Note the turn time and completion tokens. They're your baseline for choosing an effort level, and for judging whether Highspeed is worth it.

Migration checklist

• Use K3.1 Pro's ID: kimi-k3.1-pro on Moonshot's API and AIHubMix, for Codex too, and k3.1-pro in Kimi Code.
• Move K2.x code before Moonshot retires the K2 series at the end of December 2026; new Moonshot accounts lose K2 access from 31 October.
• Start a new session for K3.1 Pro instead of switching an old one.
• Remove temperature, top_p, n and both penalties from every call path, including helper calls.
• Remove every thinking-off switch, including effort values off, none and disabled, and delete leftover K2.x thinking blocks.
• Send effort as low, high or max; medium runs as high, and xhigh as max.
• Keep the model and the effort fixed within a session.
• Copy the Highspeed ID exactly, and check the model in your usage log.
• Keep stop lists to five entries of 32 bytes or less.
• Pass back the full assistant message, including reasoning_content and tool_calls, and resend dynamic tool messages.
• Stream long requests and set timeouts in minutes.
• Validate structured output before moving JSON back to the Messages API.
• Update cost tracking for the separate cache-write field.
• Make safety checks fail closed on API errors.
• Run the smoke test in each coding tool.

FAQ

Why does K3.1 Pro return HTTP 400?
The usual causes are a temperature other than 1, thinking switched off, or an effort of off, none, disabled or an unknown value. The first comes from K3's fixed sampling rules, which K3.1 Pro keeps; the others are documented in Moonshot's Kimi Code docs. On AIHubMix's main IDs, only the temperature returned a 400 on 24 October; the others returned 200, and thinking off or none came back with no reasoning.

Can I turn thinking off?
No. K3.1 Pro only runs in thinking mode. Set reasoning_effort to low to keep thinking short.

Is temperature still rejected?
Yes on Moonshot's API and on AIHubMix's main IDs, which returned "invalid temperature: only 1 is allowed for this model" on 24 October 2026. AIHubMix's coding channel accepted a temperature of 0.2 in the same check. Leave temperature out on every route.

When do the K2 models go away?
From 31 October 2026, newly registered Moonshot users can't use K2 series models, and Moonshot plans to retire all of them by the end of December 2026. AIHubMix still listed K2.6 and K2.7 Code on 24 October, with no retirement date.

Why is my Kimi Code quota running out faster?
K3.1 Pro defaults to max effort, where K3 defaulted to high in Kimi Code, and Highspeed counts about twice the quota of the regular model. Set a lower effort for routine work and keep it fixed within a session.

Why isn't Highspeed faster?
Either the ID is mistyped, which in Kimi Code silently falls back to K2.8 Preview without thinking, or tool calls dominate the turn. Highspeed only speeds up model output.

Which AIHubMix endpoint should Codex use?
The Responses API at aihubmix.com/v1, with wire_api set to responses and the model set to coding-kimi-k3.1-pro: the main IDs still return 404 there, and only the coding channel answers. Under the main IDs, AIHubMix serves K3.1 Pro on Chat Completions and Messages.

Keep reading: the Kimi K3.1 Pro series

• Before you migrate, check whether the upgrade is worth it at all, from what changed to what one real task costs: Kimi K3.1 Pro vs K3: What Changed, What It Costs, and Who Should Switch
• If the migration has you weighing alternatives, here is K3.1 Pro against Qwen 4 and Claude Fable 5.5, with what one front-end build costs on each: Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5: Front-End Quality, Cost per Task, and the Hype Checked
• If the Highspeed quota and price have you wondering whether the fast variant pays off, the speed-versus-price question gets its own post: Kimi K3.1 Pro vs K3.1 Pro Highspeed: Is 2–3× the Speed Worth 2× the Price?

Sources

• Kimi Code: Model configuration
• Moonshot AI: Model parameter reference
• AIHubMix: Kimi K3.1 Pro model page
• AIHubMix: Kimi K3 hands-on guide
• Hermes Agent issue #142365: Kimi Code endpoint profile drift