Result first. Kimi K3.1 Pro is live on Moonshot's API and on AIHubMix as kimi-k3.1-pro, and in Kimi Code as k3.1-pro. Moonshot gives it K3's parameter constraints, so code that runs on K3 moves with a model-ID change and a new session. On Moonshot's platform, code written for K2.x has until the end of December 2026, when Moonshot plans to retire the K2 series there (its newly registered users lose access from 31 October). That code hits three problems:
-
Sampling parameters return 400. A
temperatureother than 1 gets400 invalid temperature: only 1 is allowed for this model. AIHubMix's main IDs returned exactly that on 24 October, and Moonshot's API fixes top_p, n and both penalties too. AIHubMix's coding channel accepted the same request, so a test there proves nothing about the main route. -
Thinking can't be turned off. Per Moonshot's Kimi Code docs, disabled thinking returns 400, and so do the effort values
off,noneanddisabled, or any value the mapping doesn't know. On AIHubMix's main IDs none of these returned a 400: disabled thinking andnonecame back 200 with no reasoning at all.mediumsilently runs ashigh, andxhighasmax. -
No effort set means
max. In Kimi Code, K3 defaulted tohigh. Evenlowisn't small: in an AIHubMix spot check on the main IDs, K3.1 Pro reasoned for 5,561 to 7,356 tokens atlow, and K3 for 3,013 to 7,051.
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 marked as K3's come from Moonshot's K3 guides and AIHubMix's July test of K3. Each error text says where it comes from.
What AIHubMix ran on 24 October
One request per cell, with a short prompt and a test key, on AIHubMix's main IDs and on its coding channel, between 01:03 and 02:03 CST:
| Request | kimi-k3.1-pro, -highspeed | coding-kimi-k3.1-pro, -highspeed |
|---|---|---|
| Chat Completions | 200, reasoning_content | 200, reasoning_content |
| Messages | 200, thinking + text | 200, thinking + text |
| Effort low, medium, high, max, xhigh | 200 for all five | 200 for all five |
| temperature 0.2 | 400 | 200 |
| Leftover thinking: enabled | 200 | 200 |
| Messages with a JSON schema | {"city":"Paris"} | {"city":"Paris"} |
| 93-token prompt sent again | No cached tokens | Fully cached |
| 7,658-token prompt sent again | 7,424 tokens cached | Not tested |
| thinking: disabled | 200, no reasoning | Not tested |
| Effort off or an unknown value | 200, with reasoning | Not tested |
| Effort none | 200, no reasoning | Not tested |
| Six stop sequences | 400, same text as K3 | Not tested |
| Public image URL | 400 | Not tested |
The rows from the 7,658-token prompt down were run on kimi-k3.1-pro, apart from thinking disabled, which was also run on Highspeed. AIHubMix serves both K3.1 Pro IDs on the Responses API as well, the protocol Codex uses. A separate speed spot check on the main IDs (one prompt asking for a 600-word explanation, reasoning_effort: "low", streamed, three runs per model) is quoted below where it matters. It's a spot check, not a benchmark.
Which path you're on
| You call Kimi through | Status on 24 October | What you change |
|---|---|---|
| Kimi Code (subscription) | k3.1-pro is live | Pick the ID; new session |
| Moonshot API, kimi-k3 | kimi-k3.1-pro is live | Model ID |
| Moonshot API, K2.x | Retires by end of 2026 | ID, thinking, sampling |
| AIHubMix, kimi-k3 | kimi-k3.1-pro is live | Model ID |
The Highspeed IDs are kimi-k3.1-pro-highspeed on Moonshot's API and AIHubMix, and k3.1-pro-highspeed in Kimi Code. 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 select K3.1 Pro explicitly. In Kimi Code, K3.1 Pro needs the Plus plan or above (Pro for 1M context) and Highspeed needs Pro or above; on legacy plans, Moderato and above, and Allegretto for 1M context and Highspeed. No retirement date has been announced for K3. The K2 dates apply to Moonshot's platform: AIHubMix still listed K2.6 and K2.7 Code on 24 October, with no retirement date.
Prerequisites
- An AIHubMix key in
AIHUBMIX_API_KEY. - The model ID
kimi-k3.1-pro, on Chat Completions, Responses or Messages. - A client that streams and has timeouts in minutes. In the spot check, K3.1 Pro's full answers at
lowtook 80 to 99 seconds. On Moonshot's API, K3.1 Pro's default output limit is 131,072 tokens, up to 1,048,576.
Repro: the temperature 400
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 400 invalid temperature: only 1 is allowed for this model for both main IDs. 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. Swap in coding-kimi-k3.1-pro and the same request returns 200.
Cause. 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.
Why your framework may not catch it. 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 carry no prefix, and AIHubMix's coding-channel IDs start with coding-. A Hermes Agent issue shows the result on K3: the main chat path omitted temperature, but a helper call to k3 still sent one and got the 400 every time.
That helper was Hermes's "smart approval" classifier. In the reporter's words, it "escalates (fail-open) on every call": the safety check stopped doing its job, and nothing in the main chat looked wrong. On K3.1 Pro, switching thinking off to save time doesn't work either: on AIHubMix it came back with no reasoning. If a safety check runs on K3.1 Pro, use reasoning_effort: "low" for speed, and make API errors fail closed.
Fix. Don't send temperature, top_p, n, presence_penalty or frequency_penalty at all, on any call path. Match on the model family, not on a name prefix, and test each model ID you route to.
The other errors
Thinking switched off
Moonshot's Kimi Code docs: K3.1 Pro models "only support thinking mode. Requests with thinking disabled are rejected." That's an HTTP 400 in Kimi Code; the docs don't quote the body. On Moonshot's API, K3.1 Pro has 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, so check responses for missing reasoning. Typical sources are K2.x code like extra_body={"thinking": {"type": "disabled"}} and tools that send off, none or disabled as the effort. Remove the switch and use reasoning_effort: "low" when you want short thinking.
A leftover thinking: {"type": "enabled"} block is a different case: AIHubMix's check got 200 for it on all four IDs. 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.
Keeping K2.7 Code as a fallback 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 off.
Effort values
K3.1 Pro has three levels: low, high and max, with max as the default. Moonshot's Kimi Code docs map third-party values like this:
| Tool sends | K3.1 Pro runs at |
|---|---|
| Nothing | max (default) |
| ultra, max, xhigh | max |
| high, medium | high |
| low, minimum, light | low |
| off, none, disabled | HTTP 400 |
| Anything else | HTTP 400 |
Moonshot's API documents only the three levels and no mapping. AIHubMix accepted low, medium, high, max and xhigh, which fits the mapping. Where the mapping says 400, AIHubMix answered 200 on kimi-k3.1-pro: off and an unknown value came back with reasoning, and none with none at all. On AIHubMix these fail quietly. Send low, high or max explicitly, and check what your tool actually puts on the wire.
stop limits
AIHubMix's July test of K3 returned:
Invalid request: stop array too long. Expected an array with maximum length 5, but got an array with length 6 insteadInvalid request: stop sequence must not be longer than 32, but got 33 instead
K3 accepts at most five stop sequences of up to 32 bytes each (on 24 October, six entries got the same 400 from kimi-k3.1-pro), 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. Trim the list, and remember that 32 bytes is fewer than 32 characters in Chinese or Japanese.
Codex on Moonshot's API: web_search.search_context_size
Moonshot's Codex guide for K3.1 Pro quotes 400 web_search.search_context_size is not supported. Remove search_context_size from your Codex config or tool definition. Codex doesn't send it by default. Through AIHubMix's coding channel, a Responses request with that field returned 200 on 24 October, so the error comes from Moonshot's own endpoint.
Silent failures (all return 200)
| What your code does | What happens | Fix |
|---|---|---|
| Omits reasoning_effort | Runs at max | Set an effort per workload |
| Sends medium or xhigh | Runs as high or max | Send low, high or max |
| Switches thinking off (AIHubMix) | 200 with no reasoning | Use low instead |
| Assumes low means short | Thousands of thinking tokens | Measure on your prompts |
| Switches an old session | Worse output, fewer cache hits | Start a new session |
| Changes model or effort | Cache invalidated | Fix both per session |
| Mistypes the Highspeed ID | K2.8 Preview in Kimi Code | Copy the ID exactly |
| Expects faster tool calls | Only output gets faster | Time the whole turn |
| Translates protocols in a proxy | Behaviour may vary | Use the native protocol |
| Times out after 60 seconds | Fails; retries pay again | Stream; minutes |
| Keeps only content | Unstable multi-turn output | Pass back the full message |
| Drops the dynamic-tool message | The tools disappear | Resend it every request |
Details behind the table:
-
Default effort. In Kimi Code, K3 defaulted to
high, so the same session now spends more tokens and quota. On Moonshot's API, K3 already defaulted tomax. Thinking bills as output; in AIHubMix's July game build on K3, 73% of 74,994 completion tokens were thinking. -
Low effort. In the spot check, K3.1 Pro reasoned for 5,561 to 7,356 tokens at
lowbefore answering, 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, butlowisn't a cheap mode on either. Leavemax_completion_tokensgenerous. - Sessions and cache. Moonshot's Kimi Code docs advise against switching to K3.1 Pro "within an existing K3 series, K2.8 Preview, or K2.7 Code Highspeed session": it degrades output quality and reduces cache hits. Changing the model or the effort invalidates the cache.
-
Highspeed ID. In Kimi Code, a wrong Highspeed ID "silently falls back to K2.8 Preview without thinking — no speedup." On AIHubMix, a mistyped ID fails loudly instead:
400 … This model ID is incorrect. -
Highspeed speed. Moonshot claims about 2–3× K3.1 Pro's speed with identical capabilities, but only model output gets faster, not tool calls or scripts. In the spot check on the main IDs (effort
low, three runs each), Highspeed's output ran about 1.6–1.75× Pro's speed. Kimi Code plans count about twice the quota for it. - Proxies. "Protocol translation through proxy tools may cause model behavior to vary," per the Kimi Code docs. Messages for Claude Code, Responses for Codex; AIHubMix serves both K3.1 Pro IDs on all three protocols.
- Timeouts. A non-streaming client with a 60-second timeout would have failed every K3.1 Pro run in the spot check (80 to 99 seconds). AIHubMix's July game build on K3 ran 2,541 seconds in one request.
-
Multi-turn and dynamic tools (K3 guides). The full assistant message, including
reasoning_contentandtool_calls, has to go back unchanged, and a dynamic-tool system message has to be resent, because the server doesn't keep it. On AIHubMix, dynamic tools work over Chat Completions: on 24 Octoberkimi-k3.1-procalled a tool injected this way. In AIHubMix's July K3 test, the Messages API ignored an injected tool.
One thing got better: in AIHubMix's July test on K3, the Messages API ignored a JSON schema and returned free text. On 24 October, K3.1 Pro returned {"city":"Paris"} for a one-field schema in output_config.format on all four IDs. Validate before you move JSON back to Messages. July's stop-sequence quirk on Messages (end_turn with stop_sequence: null) wasn't re-tested.
Billing
Prices here are from Moonshot's official price list, per 1M tokens. Cache writes are billed by TTL (5 minutes by default, or 1 hour):
| Moonshot model ID | Input | Output | Cached input | Write, 5 min | Write, 1 hour |
|---|---|---|---|---|---|
| kimi-k3.1-pro | $2.00 | $10.00 | $0.20 | $2.00 | $4.00 |
| kimi-k3.1-pro-highspeed | $4.00 | $20.00 | $0.20 | $4.00 | $8.00 |
| kimi-k3 | $3.00 | $15.00 | $0.30 | $3.00 | $6.00 |
K3.1 Pro is a third below K3 on every line, and Highspeed is exactly 2× Pro on everything except cached input.
Rate cuts and bills aren't the same thing. AIHubMix's July one-prompt game build on K3 (74,994 output tokens, 5,000 input tokens assumed) costs about $1.14 on K3. At the same token counts it would cost 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), so measure your own first.
- A 5-minute write costs the same as uncached input, as on K3. Moonshot says the write cost was already part of the input price, so default-TTL requests cost no more than before.
- AIHubMix passes the TTL through: a Messages request with a top-level
cache_controlTTL of1hreported its write as 1-hour cache tokens, andprompt_cache_optionson Chat Completions was accepted. - The 1-hour TTL costs $2.00 more per million tokens to write on K3.1 Pro ($4.00 against $2.00), and 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.
- Cache writes have their own usage field on K3:
prompt_tokens_details.cache_write_tokens(Chat Completions),input_tokens_details.cache_write_tokens(Responses),cache_creation_input_tokens(Messages). Update your cost tracking. - Caching is automatic. In the 24 October checks, a repeated 93-token prompt was 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-proreported 7,424 cached tokens over both Chat Completions and Messages.
To lower the bill:
- Set
reasoning_effortper workload instead of inheritingmax:lowfor lookups and classification,highfor routine coding. - Keep the model and the effort fixed per session, and start a new session when you change either.
- Put the stable parts first (system prompt, tool definitions, repository context), then the changing turn.
- Use Highspeed where you wait on model output, not in tool-heavy loops.
- Watch the share of thinking in completion tokens. If it stays above half on simple tasks, lower the effort.
Claude Code and Codex
AIHubMix serves kimi-k3.1-pro on Messages, which Claude Code uses, and on Responses, which Codex uses; Moonshot's own Codex guide also connects Codex to K3.1 Pro over Responses. Install and base configuration are in AIHubMix's evergreen guides; below is only what changes for K3.1 Pro.
| Claude Code | Codex | |
|---|---|---|
| Protocol | Anthropic Messages | Responses |
| Model ID to use | kimi-k3.1-pro | kimi-k3.1-pro |
| Base URL | https://aihubmix.com | https://aihubmix.com/v1 |
| Context to declare | 1M | 1048576 |
| Effort to set | low, high or max | low, high or max |
Claude Code
Start from 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"
}
}
Failure modes, from Moonshot's Kimi Code docs, its Claude Code guide (written for K3) and AIHubMix's tests:
- Old sessions. Start a new session instead of switching a K3 one; switching costs output quality and cache hits.
- Unset tiers fail silently. Claude Code uses different tiers for the main chat, summaries and sub-agents, and Moonshot warns that configuring only some of them makes the rest "fail silently". The Haiku tier can point at a cheaper model for background work.
-
Stale settings win. Old values in the
envblock of~/.claude/settings.jsonoverride 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. Sent as a model ID from any other client,kimi-k3.1-pro[1m]returns a 400. -
Effort. K3.1 Pro defaults to
max, the level Moonshot's K3 guide recommended viaCLAUDE_CODE_EFFORT_LEVEL=max.highspends fewer tokens on routine work. Other values are mapped as in the effort table. -
Highspeed. If a tier points at
kimi-k3.1-pro-highspeed, copy the ID exactly. On Kimi Code a typo falls back silently; on AIHubMix it returns a 400.
Codex
Codex only speaks the Responses API, so wire_api = "responses" is required. The Codex config.toml guide covers the rest. For K3.1 Pro:
model = "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. Per Moonshot's Codex guide, the warningModel metadata for kimi-k3.1-pro not foundis expected and harmless. -
Effort. Codex's
mediumandxhighrun ashighandmaxunder the Kimi Code mapping, and AIHubMix accepted both. Setlow,highormaxso you know which level you pay for. - Restart after edits. Codex reads config.toml only at startup, and CC Switch, if it manages your Codex config, may overwrite your edits.
Smoke test (about 15 minutes)
Once per tool, in a small repository with a test suite, start a fresh session on K3.1 Pro and ask: "Add a unit test for one function in this repo, run the tests, and fix anything that fails."
Pass criteria:
- The model reads files and runs the tests, so tool calls work.
- It continues after seeing the results, so reasoning and tool results are being passed back.
- It ends with green tests, and no request in the session returns a 400.
- Your AIHubMix usage log shows the model ID you set, and later requests show cached input tokens for the stable prefix. If they never do, something in your prefix changes every turn.
Record the turn time and completion tokens as your baseline for choosing an effort level and for judging Highspeed.
Before you hand it to an agent
- Safety checks fail closed. See the Hermes classifier above. On K3.1 Pro, neither a low temperature nor thinking switched off works for a fast classifier: the first can return a 400 on every call, and on AIHubMix the second came back with no reasoning.
-
Forced tool calls work. K3.1 Pro supports
tool_choice: "required", which K2.x rejected. -
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 returned400 Invalid request: tokenization failed. -
Images need base64. On 24 October,
kimi-k3.1-proon AIHubMix rejected a public image URL with400 Invalid request: unsupported image url. Moonshot's file IDs come from its own upload, which AIHubMix doesn't serve: anms://reference returned 404. A base64 image worked.
Pre-flight checklist
- Model ID: kimi-k3.1-pro on Moonshot's API and AIHubMix, Codex included; k3.1-pro in Kimi Code.
- K2.x code migrated before Moonshot retires the K2 series at the end of December 2026.
- A new session started for K3.1 Pro.
- No temperature, top_p, n or penalties on any call path, helper calls included.
- No thinking-off switch and no off, none or disabled effort; leftover K2.x thinking blocks deleted.
- reasoning_effort set to low, high or max explicitly.
- Model and effort fixed per session.
- Highspeed ID copied exactly and confirmed in the usage log.
- Stop lists of five entries or fewer, 32 bytes each at most.
- Full assistant message passed back; dynamic tool messages resent.
- Streaming on, timeouts in minutes.
- Structured output validated before relying on Messages.
- Cost tracking reads the separate cache-write field.
- Smoke test passed in each coding tool.
What this post can't verify
- What serves a thinking-off request on AIHubMix. It returned 200 under the K3.1 Pro ID with no reasoning; which path answered isn't documented.
- AIHubMix's cache-write billing. The model pages list no cache-write rate, so how a 1-hour write is billed isn't stated.
- Thinking disabled on Moonshot's API. The 400 is documented for Kimi Code; the pay-as-you-go API wasn't probed directly.
-
The 32-byte stop limit on K3.1 Pro. The five-entry limit was re-tested; the length limit is inferred from "the same parameter constraints as
kimi-k3". - The spot check. One prompt and three runs per model, on the main IDs.
- Structured output. A one-field schema, one request per ID.
-
The leftover-
thinking400. Moonshot doesn't publish its text; the cause comes from a third-party troubleshooting guide, and AIHubMix's check got 200.
Keep reading: the Kimi K3.1 Pro series
- Not sure the migration is worth doing yet? What changed, and what one real task costs on each version: Kimi K3 to K3.1 Pro: What Carries Over, What Breaks, and How to Measure the Bill
- Weighing alternatives before you commit? Here's 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 for Front-End Work: Benchmarks, Cost per Build, and a Three-Model Test Script
- Deciding whether to point your tools at Highspeed? Here's the speed and price trade-off, worked through: Timing Kimi K3.1 Pro vs Highspeed: 1.7x Faster for 2x the Price, and When That's Worth It
Top comments (0)