Most models give you a temperature knob. Kimi K3.1 Pro gives you one dial and refuses three of the usual fields: thinking is always on, `reasoning_effort` takes `low`, `high` or `max` with max as the default, and `temperature=1.0`, `top_p=0.95`, `n=1` are fixed values you must omit from the request [VENDOR — Kimi platform documentation, 26 October]. OrcaRouter lists the same parameter set on its Kimi K3.1 Pro API card, with `reasoning_effort`, `max_tokens` and the tool-calling fields as the ones you can actually move, at the vendor’s list price.
That is a design decision with three consequences, and they are not the ones the launch coverage discussed. It changes what a request costs by default, it changes what a cached prefix is worth, and it rules out a category of workload that most teams assume is available.
The parameter surface, as documented
| Field | Behaviour |
| Thinking | Always on; cannot be disabled |
| `reasoning_effort` | `low`, `high`, `max`; default `max` |
| `temperature` | Fixed 1.0 — omit it |
| `top_p` | Fixed 0.95 — omit it |
| `n` | Fixed 1 — omit it |
| `presence_penalty` / `frequency_penalty` | Fixed 0 — omit them |
| `max_completion_tokens` | Defaults to 131,072; can be set up to 1,048,576 |
| Tools / structured output | Supported |
| Inputs | Text, image, video |
| Context | 1,048,576 tokens |
Two of those rows do most of the damage if you ignore them. The default effort of `max` means the first request you ever send is the most expensive configuration the model supports. And a default `max_completion_tokens` of 131,072 means a request that runs away has a ceiling eight times lower than the model’s real one — which is fine until you need the long answer you assumed you were paying for.
Consequence one: the default is not the cheap setting
Artificial Analysis measures the reasoning share of this model’s output directly: 34,883 reasoning tokens against 20,312 answer tokens per task — thinking is 63% of everything the model writes [INDEPENDENT]. Output is billed at $10.00 per million, and output is 26% of a typical task’s cost.
At `low` effort the model still thinks, but it spends less of the budget doing it. Nobody has published a per-effort cost table for this model, so the only responsible advice is to measure it: run a sample of your traffic at all three settings, record cost and quality, and choose per task type rather than globally. What can be said with confidence is directional: the default is the maximum, and the maximum is where most of the bill is.
See also: 10 Common Pilates Reformer Mistakes and How to Avoid Them
Consequence two: changing effort invalidates the cache
This is the interaction that catches teams who tune in production.
Prompt caching keys on a stable prefix. A reasoning setting is part of the request, and changing it changes the request. On a workload where 95% of input tokens are cache reads — which is the normal shape for this model [INDEPENDENT] — flipping effort between calls means every call after the flip pays a cache write at $2.00 per million instead of a read at $0.20. A tenfold increase on the largest line of the bill, for a parameter change you made to save money.
The practical rule: pick an effort level per workload, not per request. If you must A/B effort levels, do it as two separated traffic streams with two stable prefixes, so each stream keeps its cache. A loop that tries `low`, then `high`, then `max` on the same conversation is paying to rebuild the cache three times.
That interaction also explains a pattern worth recognising in your own data: a workload whose cost is 40% above estimate usually has an unstable prefix, not an expensive model. The biggest source of prefix instability in most stacks is a system prompt that changes per request. The second is a changing tool schema. Effort is the third, and the newest.
Consequence three: there is no cheap non-thinking mode
A lot of production traffic wants a fast, cheap, don’t-think-about-it answer: classification, extraction, a short rewrite, a routing decision. On most frontier models that is a separate mode. On Kimi K3.1 Pro it is not available — every request reasons.
The consequence is architectural rather than financial. For high-volume, low-complexity traffic, the right answer is usually not to use this model with a low effort setting; it is to use a different, cheaper model for that traffic and reserve this one for the requests that need it. That is the routing case in its simplest form: a 25.81-index model at $0.95/$4 handles classification, a 55.09-index model at $2/$10 handles the analysis, and one key reaches both.
If you do want to use Kimi K3.1 Pro for a simple task, `low` effort plus a hard `max_completion_tokens` is the cheapest honest configuration. It will still reason. It will just reason less.
What the fixed sampling fields mean in practice
`temperature=1.0, top_p=0.95` is a sampling profile: broad but not uniform, with the long tail truncated. For most workloads it is unremarkable, and it is the same profile Moonshot uses for the consumer product, so it is well exercised.
It matters in two places. The first is any task where you previously used a low temperature to force consistency — structured extraction, templated generation, deterministic test fixtures. You cannot do that here; consistency has to come from the prompt and from schema-constrained output, not from a low temperature. The second is evaluation: a benchmark run that does not record this profile is not reproducible on this model, and a model card comparison that lists a temperature you cannot set is comparing something other than what you will get.
One more practical note from the documentation: return the complete assistant message unchanged in multi-turn conversations and tool calls [VENDOR]. Trimming or reformatting the assistant’s previous turn — a common habit in hand-rolled agent loops — breaks the prefix the cache depends on and, at the margins, the model’s own thread of reasoning.
A configuration that works
For an agentic coding or analysis workload, the settings that produce a predictable bill:
Effort `high`, not `max`, for the steady state, with `max` reserved for tasks that fail at `high`. This is a per-workload decision, made once.
`max_completion_tokens` set explicitly, sized to the longest answer your task legitimately needs rather than left at the 131,072 default — and certainly not left at a value that silently truncates the 1M-token ceiling you paid for.
A frozen system prompt and tool schema, versioned rather than edited in place, so the prefix stays stable across a burst.
Temperature omitted, because sending it is an error, not a preference.
Two models on one key. Simple traffic to a cheap model, complex traffic here. This model’s refusal to have a cheap mode is an argument for routing, not an argument for tuning.
The summary: this is a model that thinks every time, defaults to thinking hard, and fixes the sampling profile its training expects. Those are reasonable choices by the vendor and hard constraints for you. Budget from the default, not from the rate card, and treat any mid-conversation parameter change as a cache event rather than a free adjustment.
Sourcing note: the parameter behaviour — thinking always on, the three effort levels with max as default, the fixed temperature and top_p, the 131,072 default completion ceiling, and the instruction to return assistant messages unchanged — is from Moonshot’s Kimi platform documentation, fetched 26 October 2026. The reasoning-token share, the 95%-cached input shape and the output-cost share are Artificial Analysis measurements on index v4.3.2 of the same date. Our card lists the same parameter surface and mirrors the vendor’s rates, though its generated one-line description also mentions a `none` effort level that the vendor’s documentation does not define; treat the vendor’s page as authoritative and test the field on your own integration before you depend on either. The routing recommendation and the cache-interaction reasoning are ours.
