MiniMax M3.1 Flash Five Effort Levels Tested: Default Setting Costs 7x More With Zero Benefit

MiniMax M3.1 Flash has an easily overlooked behavior: it is always thinking, and when the request does not include an effort field, the MiniMax documentation explicitly states it defaults to max. This means code migrated from M2.x—those old calls that never set effort—now automatically runs at the most expensive level.

Someone ran the same dual-bug fix task three times each across all five effort levels plus "omitted," six configurations total, scoring each run with 215 hidden tests. The conclusion is straightforward: all 18 runs passed perfectly. Omitting the field (i.e., the default max) consumed an average of 6,364 thinking tokens, 56 seconds, and $0.0045 per fix; while the low level used an average of only 591 thinking tokens, 9.5 seconds, and $0.0006. The default configuration costs about 7x more with no additional benefit on this task.

Test Setup: A Billing Function With Two Bugs

The test task is a billing function with two bugs: pause intervals that cross the end of a billing period overcount by one day, and overlapping pauses get double-deducted. The prompt describes both symptoms and asks for the corrected function in a single code block. The local test harness validates with 215 cases—15 hand-written edge cases plus 200 random cases—against a brute-force reference implementation. The original buggy version passed only 138.

The model was called through AIHubMix using minimax-m3.1-flash, with an OpenAI Chat Completions format endpoint, max_tokens set to 32768, and each level run three times. Pricing is based on AIHubMix per million tokens: input $0.165, output $0.66, cached input $0.0165, with thinking tokens billed as output.

Field Names Under Three Protocols

The same model works under three protocols, but the effort field is written differently: OpenAI Chat Completions uses reasoning_effort, Anthropic Messages uses output_config.effort, and OpenAI Responses uses reasoning.effort. All three accept the five values low, medium, high, xhigh, and max, defaulting to max.

One detail: thinking cannot be disabled. MiniMax's Messages API documentation states that passing thinking: {"type": "disabled"} or effort as none returns HTTP 400 with the error message model "MiniMax-M3.1-Flash" requires adaptive thinking. Earlier MiniMax models simply ignored the effort field.

Cross-vendor semantic differences in reasoning_effort: OpenAI introduced reasoning_effort in its o-series models, initially with only low/medium/high, later extended to finer granularity like xhigh. Anthropic's output_config.effort and the Responses API's reasoning.effort are different wrappers around the same concept, and gateways (like AIHubMix) need to map them when forwarding. The problem is that vendors handle "unknown values" and "none" inconsistently: some reject outright, some silently fall back to the default level, and others translate effort into an internal thinking budget. So the same string can produce completely different actual compute on different endpoints, which is also the root of the "silent failure" failure mode described in this article.

How thinking tokens are billed: Most reasoning models count internal thinking tokens on the output side rather than pricing them separately. This means the effort level directly determines the bill size, because higher levels generate more reasoning tokens, which are reported separately in usage as completion_tokens_details.reasoning_tokens and similar fields. Models from the M2.x era ignored the effort field and had relatively fixed thinking amounts; after migrating to M3.1 Flash, if old code is reused, the billing model shifts from "fixed thinking overhead" to "scaled by level," and the cost curve changes accordingly.

Measurement Results: Quality Flat, Cost Gap Huge

The average data for the six configurations is as follows:

Effort	Avg thinking tokens	Range across three runs	Avg time	Cost per fix	Test result
low	591	344–812	9.5 s	$0.0006	215/215 ×3
medium	1,522	970–2,488	21.7 s	$0.0013	215/215 ×3
high	2,863	2,194–3,673	27.1 s	$0.0022	215/215 ×3
xhigh	1,949	1,019–2,562	19.2 s	$0.0015	215/215 ×3
max	4,699	2,612–6,246	40.4 s	$0.0034	215/215 ×3
omitted	6,364	4,284–9,376	56.3 s	$0.0045	215/215 ×3

This table supports a few judgments. Quality is completely flat: 18 Chat runs, 18 perfect fixes—on this bounded bug, thinking beyond low brought no measurable benefit. low to medium is a real step: thinking tokens about 2.6x, time more than doubled. But above medium, with only three runs per group, levels cannot be ranked—xhigh's average is actually lower than high, and max overlaps with both. The omitted field is essentially identical to max, matching the documentation, with higher averages within run-to-run noise.

Time correlates strongly with tokens. Across all 24 Flash runs (Chat and Messages), throughput held steady at about 112 output tokens per second, so 6,000 thinking tokens take nearly a minute of wall-clock time.

Short Prompts Behave Completely Differently

Adaptive thinking depth scales with the prompt. Assigning five support tickets to four labels, the low level used 0 thinking tokens, the default level averaged 6, and all labels were correct. "What is 17 × 23?" produced no thinking at low, just 2 output tokens. For classification-type calls, the lack of an off switch costs almost nothing extra.

Adaptive thinking: This is the behavior mode forced by MiniMax M3.1 Flash, where the model decides thinking depth based on prompt complexity on its own, and it cannot be disabled via thinking: {"type": "disabled"} or effort as none. The consequence: the same effort level produces wildly different actual thinking amounts on different inputs—short classification prompts may produce 0 thinking tokens at low, while coding tasks at the same level may produce thousands. This is also the mechanism behind the "latency spikes at fixed levels" phenomenon in this article. For timeout settings, effort sets average depth, not a hard cap—engineers cannot set timeouts by multiplying a level's average time by a safety factor, but should reference that level's maximum or loosen further.

Randomness and sample size: Each level has only three runs, so averages are heavily influenced by single extreme values. The xhigh average being lower than high, and max overlapping with both, may just be noise from three samples rather than a real ranking of levels. Determining which is more cost-effective above medium requires a larger sample size (e.g., 20+ runs per level) and reporting distributions rather than averages. Additionally, single-run thinking token fluctuation can span several fold (e.g., Messages endpoint low level from 511 to 6,060), meaning single-run cost prediction is itself unstable, and budget estimates should be based on the average plus tail risk.

Six Failure Modes and Corresponding Fixes

Thinking causes truncation. Thinking tokens count toward max_tokens. One default run used 9,376 thinking tokens on a single function. Inherited 4K or 8K limits from M2.x may end with finish_reason: "length" and give a cut-off answer. The fix is to raise max_tokens (MiniMax recommends 131,072, up to 524,288) and check finish_reason.

Latency spikes at fixed levels. On the Anthropic Messages endpoint, the three low runs used 511, 1,861, and 6,060 thinking tokens respectively, with the last taking 56 seconds. Effort sets average depth, not a ceiling. The fix is to set client and proxy timeouts to 120 seconds or more at high and above, and not set timeouts based solely on low's average.

Silently failing effort values. Through AIHubMix, passing none, minimal, or auto as reasoning_effort all return HTTP 200, and the model thinks as usual. According to tests from one gateway project (sub2api issue #8025), MiniMax's own endpoint rejects unknown values. The fix is to send only one of the five documented values. AIHubMix's unified reasoning parameter documentation describes how the gateway maps reasoning fields across vendors.

Tools that don't send the level. OpenCode cannot parse the effort variants for this model (anomalyco/opencode issue #54801), and its effort switch has no effect. Some frameworks also send "thinking disabled," causing 400 errors. The fix is to check the actual request body being sent.

Mixed-model routing. M3 and M2.x ignore the effort field, so levels that save money on Flash do nothing on other models.

Verify the setting actually reached the model. Read usage: for the Chat protocol check completion_tokens_details.reasoning_tokens, for the Messages protocol check output_tokens_details.thinking_tokens, for the Responses protocol check output_tokens_details.reasoning_tokens. If these numbers don't move when you change the level, the setting never reached the model.

Choosing a Starting Point by Task

Only the first two rows are supported by the above measurements; the rest are suggestions based on retry-rate self-checks. For classification, extraction, and routing tasks, start at low, and raise when hard-case labels err. For single-function fixes and small-scale review, start at low, and raise after two test-failure fixes. For multi-file edits and refactoring, start at medium, and raise when the agent misses dependency files. For agent loops with heavy tool use, start at low or medium, and raise when steps repeat or stall. For hard debugging and design questions, start at high, and raise when answers stay shallow. For interactive chat where someone is waiting for results, start at low—never default to max here.

What Cannot Be Verified

Where higher levels start to pay off cannot be tested here. The task was solved at every level, and MiniMax has not released per-level token, latency, or accuracy data; a single bounded task cannot show when high, xhigh, or max are worth their cost. Ranking above medium likewise fails to hold: three runs per level are insufficient to distinguish high, xhigh, and max. Furthermore, all numbers come from one short coding prompt and one classification prompt, measured by AIHubMix, with no third-party reproduction yet.

For teams migrating, the single most actionable conclusion is: explicitly set low, then raise per task. Treat effort as a parameter that needs deliberate configuration, not a default that can be omitted.

One-line Summary

MiniMax M3.1 Flash defaults to max when effort is omitted—7x the cost with no quality benefit

Paragraph Summary

When the effort field is omitted in requests, MiniMax M3.1 Flash defaults to the max level, so old code migrated from M2.x automatically runs at the most expensive configuration. The author ran a dual-bug fix task three times each across five effort levels plus omitted—six configurations total—scoring each run with 215 hidden tests, and all 18 runs passed perfectly with completely flat quality. The default configuration averaged 6,364 thinking tokens, 56 seconds, and $0.0045, while the low level used only 591 thinking tokens, 9.5 seconds, and $0.0006—about a 7x cost difference. Thinking tokens count toward max_tokens, so old low limits cause truncation; some gateways silently fail on unknown effort values. Since there are only three runs per level, levels above medium cannot be ranked. The actionable conclusion is to explicitly set low and raise per task, treating effort as a parameter that needs deliberate configuration.