Kimi K3.1 Pro Defaults to Max Reasoning, So Set reasoning_effort Yourself and Delete Your Old Sampling Settings

Moonshot AI's Kimi K3.1 Pro always thinks, defaults reasoning_effort to max, and fixes its sampling parameters. Choosing the effort level yourself and cleaning up legacy request settings is the fastest way to cut latency and cost before its open weights land.

Moonshot AI's Kimi K3.1 Pro is one of the most talked about models of the week, and teams wiring it into their applications are running into the same surprise. According to Moonshot's Kimi API documentation, the model's reasoning_effort parameter accepts low, high, and max, and the default is max. If you send a request without setting it, you are asking for the most expensive and slowest reasoning the model offers on every call, including the simple ones.

There is no way around reasoning by turning it off. The documentation states that K3.1 Pro always has thinking mode enabled and that it cannot be disabled. The only lever is the effort level, which makes setting it deliberately the single most important configuration decision you will make with this model. Moonshot's own guidance is that if reasoning takes too long, you should lower reasoning_effort to low.

The second trap is code carried over from older models. Moonshot's documentation says K3.1 Pro's temperature, top_p, n, presence_penalty, and frequency_penalty are fixed and should be omitted from requests. Sampling settings tuned for earlier Kimi models or other providers do nothing useful here, so delete them rather than leave them in place where they create a false impression of control.

Output length deserves a look too. The documentation says max_completion_tokens defaults to 131072 and can be set as high as 1048576. Those are generous ceilings for a reasoning model, so set a lower limit wherever you need predictable latency and cost. For agent loops, the documentation is explicit that you should return the complete assistant message unchanged in multi turn conversations and tool calls, not only its content, so the model keeps its own reasoning context between steps.

Finally, if responsiveness matters more than depth, Moonshot offers kimi-k3.1-pro-highspeed, which its documentation describes as delivering two to three times the speed of K3.1 Pro. Route interactive, user facing traffic there and keep the standard model for the hard problems.

Try it today

1. Set reasoning_effort explicitly on every request: low for routing, extraction and chat; high or max only for genuinely hard reasoning.
2. Remove temperature, top_p, n, presence_penalty and frequency_penalty from your K3.1 Pro requests, since Moonshot fixes them.
3. Lower max_completion_tokens from its 131072 default wherever you need tighter latency or cost limits.
4. In agent loops and tool calls, append the complete assistant message to history, not only its content.
5. Send latency sensitive interactive traffic to kimi-k3.1-pro-highspeed and benchmark it against the standard model on your own tasks.