MiniMax M3.1 Flash Thinking Levels: Set and Check Effort
low, medium, high, xhigh and max. Its documented default is max, and thinking cannot be disabled.This guide uses EvoLink Chat Completions as the main configuration path. The request is based on the current documentation and has not been submitted as a paid model call for this article. It gives you a request to adapt, a local way to inspect its response and a task with checkable requirements; it does not supply an invented successful run.
What do MiniMax M3.1 Flash thinking levels control?
Use the following as starting hypotheses for your own evaluation. The task assignments are editorial recommendations, not official optimal settings or guaranteed latency bands.
| Level | Possible starting use | Evidence to collect before changing it |
|---|---|---|
| low | A narrow transformation with explicit rules | Required fields, format and boundary cases all pass |
| medium | A bounded repair with a known reproduction | The patch addresses the cause and passes its checks |
| high | A task combining several dependencies | The answer connects the evidence rather than inventing missing details |
| xhigh | A difficult case that still fails after input and tool problems are resolved | Repeating the task yields a useful improvement worth the expense |
| max | A hard case where a deeper attempt is justified, or a deliberate default-setting baseline | Acceptance, total elapsed time and actual usage remain within your budget |
Start with the task's failure cost and a setting you can compare consistently. If a screenshot is missing or a test runner cannot start, changing effort does not supply the missing evidence or tool. Resolve that gap first.
Use the field for your protocol
| Protocol | Thinking-depth field | Reasoning representation | Output limit |
|---|---|---|---|
| Chat Completions | reasoning_effort | reasoning_content | EvoLink recommends max_completion_tokens |
| Anthropic-compatible Messages | output_config.effort | thinking content block | max_tokens |
| Responses | reasoning.effort | Reasoning output item | max_output_tokens |
Send one explicit Chat Completions configuration
EVOLINK_API_KEY environment variable, a terminal with curl and Python 3, and a writable working directory for the response file. Use an account authorized to make the request. Running the following request can incur model charges.The task is deliberately small: extract three ticket fields from supplied text. It lets you check answer formatting and required values before involving a repository or tools. Passing it does not establish coding-agent quality.
curl --silent --show-error --fail-with-body \
'https://api.evolink.ai/v1/chat/completions' \
-H "Authorization: Bearer ${EVOLINK_API_KEY:?Set EVOLINK_API_KEY first}" \
-H 'Content-Type: application/json' \
--data '{
"model": "MiniMax-M3.1-Flash",
"reasoning_effort": "low",
"max_completion_tokens": 4096,
"stream": false,
"messages": [{
"role": "user",
"content": "Extract the ticket below. Return only a JSON object with exactly these string fields: ticket_id, status, priority. Do not add Markdown or invent values. Ticket: INC-1042. Status: open. Priority: high."
}]
}' \
--output m31-flash-response.json4096 limit is an illustrative test budget, not a recommended limit for every task. The generation budget includes reasoning and the final answer, so it can be exhausted before usable answer text appears. If you use an existing client, inspect its serialized request for the same model, setting and budget; its UI alone cannot show whether the adapter forwarded them.Keep the request configuration and the response file together, with credentials excluded from any shared record. If curl reports an HTTP failure, inspect the error before applying the success-response checker below.
Check the returned answer and the task separately
message.content separately from reasoning_content, plus usage and finish information. Inspect those fields rather than parsing reasoning text out of the answer. An optional or absent field should not crash your application.Run this local inspection only after a successful request. It prints observed values and checks this example's exact answer requirements; it does not contain a fabricated model response.
python3 - <<'PY'
import json
from pathlib import Path
response = json.loads(Path("m31-flash-response.json").read_text())
choices = response.get("choices") or []
if not choices:
raise SystemExit("No choices returned; inspect the response before scoring.")
choice = choices[0]
message = choice.get("message") or {}
answer = message.get("content")
finish = choice.get("finish_reason")
print("model:", response.get("model"))
print("finish_reason:", finish)
print("reasoning_present:", bool(message.get("reasoning_content")))
print("usage:", json.dumps(response.get("usage"), ensure_ascii=False))
if finish != "stop" or not isinstance(answer, str) or not answer.strip():
raise SystemExit("Incomplete or unexpected completion; inspect before scoring.")
try:
extracted = json.loads(answer)
except json.JSONDecodeError:
raise SystemExit("Task failed: final answer is not a plain JSON object.")
expected = {"ticket_id": "INC-1042", "status": "open", "priority": "high"}
if extracted != expected:
raise SystemExit("Task failed: keys or values do not match the supplied ticket.")
print("Task acceptance: PASS")
PYFor this non-streaming, text-only task, require a normal completion and the exact object. A tool-using or streamed application needs its own completion logic. Do not copy this small checker's termination rule into every agent loop.
A passing answer establishes the extraction result for that request. It does not prove the server's internal reasoning allocation, the optimal setting or reliability on new inputs. To verify client forwarding, inspect the outgoing request as well; reasoning text being present is not an echo of the effort setting.
Diagnose a slow or incomplete result in this order
| Symptom | Check first | Next action |
|---|---|---|
| The request is rejected after changing models | Unsupported thinking-off settings and protocol-specific field names | Compare the actual request against the chosen protocol's documentation |
| No final answer or a length-related termination | Output budget and returned finish information | Separate truncation from an incorrect answer; adjust the budget for a new recorded run |
| A valid answer takes too long | Network timing, retries, tool time and the explicit setting | Measure model and application time separately before attributing the delay |
| The client shows low but behavior seems unchanged | Serialized request, SDK version and configuration overrides | Confirm the field reaches the service; do not infer a bug from latency alone |
| The answer is complete but wrong | Input completeness, instructions and acceptance criteria | Fix evidence or instruction problems before evaluating a higher level |
effort: "none". Lower effort is the documented control to investigate instead. Exact errors and supported fields must still be checked on the service and protocol you use.For budget-related failures, keep the original failure record. A larger budget may allow completion, but it is a new configuration and may change expense. Repeatedly increasing it without checking the answer's requirements obscures the source of failure.
Compare levels with the same task
Save the example input, then choose a second level to evaluate only after the first request and answer can be inspected. Keep the prompt, protocol, model, output limit and tooling fixed unless the purpose of the experiment is to change one of them.
| Task revision | Explicit level | Request field checked | Acceptance | Total time | Usage/actual charges | Retries |
|---|---|---|---|---|---|---|
| Fill from your run | Save the value | Yes/no/unverified | Passed/failed/unverified | Measured | Recorded | Count |
Repeat on representative inputs before selecting a default. Record failed attempts and avoid presenting one quick response as a general latency finding. A higher setting is worth adopting only if the improvement matters to your task and fits its expense and time limits.
FAQ
Is low equivalent to turning thinking off?
No. It is one of the supported depth settings. Do not migrate a thinking-disabled workflow by treating low as the same contract.
What if my client has no thinking-level selector?
Check whether its current provider configuration can send the required field. Inspect the request or use a documented direct API path to isolate the client layer. This guide does not claim that a particular client's issue has been fixed.
Does a successful response prove that the chosen level took effect?
It proves that the request completed at the transport level. Check what was sent and any service-provided validation. Without an explicit returned setting, response length or reasoning presence alone cannot establish internal allocation.
How do I know whether to raise effort or fix the prompt?
First make sure the input contains the evidence needed to answer, the instruction is unambiguous and the tools work. If the complete answer is still wrong under those conditions, compare another level on the same task and retain both records.
Sources
- MiniMax model invocation and thinking controls.
- EvoLink M3.1 Flash Chat Completions.
- EvoLink M3.1 Flash Messages.
- EvoLink M3.1 Flash model configuration and pricing.
Documentation checked October 19, 2026. Examples explain documented configuration; no paid model requests or performance measurements were made for this article.
