MiniMax M3.1 Flash五档推理实测：默认档位贵7倍却毫无收益

MiniMax M3.1 Flash 有一个容易被忽视的行为：它永远在思考，而且当请求里不传 effort 字段时，MiniMax 文档明确写着默认使用 max。这意味着从 M2.x 迁移过来的代码——那些从未设置过 effort 的旧调用——现在自动运行在最贵的档位上。

有人用同一个双 bug 修复任务，在全部五个 effort 档位加"省略"共六种配置下各跑了三次，每次都用 215 个隐藏测试评分。结论很直接：全部 18 次运行都完美通过。省略字段（即默认 max）平均消耗 6,364 个思考 token、56 秒、每次修复 $0.0045；而 low 档平均只用 591 个思考 token、9.5 秒、$0.0006。默认配置贵了约 7 倍，在这个任务上却没有换来任何额外收益。

测试设置：一个双 bug 的计费函数

测试任务是一个带两个 bug 的计费函数：暂停区间跨过周期末尾时会多算一天，重叠的暂停会被重复扣减。提示词描述了两个症状并要求用一个代码块给出修正后的函数。本地测试框架用 215 个用例验证——15 个手写边界用例加 200 个随机用例，对照暴力参考实现。原始的有 bug 版本只通过 138 个。

模型通过 AIHubMix 调用 minimax-m3.1-flash，端点为 OpenAI Chat Completions 格式，max_tokens 设为 32768，每个档位跑三次。价格按 AIHubMix 每百万 token 计算：输入 $0.165、输出 $0.66、缓存输入 $0.0165，思考 token 按输出计费。

三种协议下的字段名

同一个模型在三种协议下都能用，但 effort 字段的写法不同：OpenAI Chat Completions 用 reasoning_effort，Anthropic Messages 用 output_config.effort，OpenAI Responses 用 reasoning.effort。三者都接受 low、medium、high、xhigh、max 五个值，默认都是 max。

说个细节思考无法关闭。MiniMax 的 Messages API 文档说明，传 thinking: {"type": "disabled"} 或 effort 为 none 会返回 HTTP 400，错误信息是 model "MiniMax-M3.1-Flash" requires adaptive thinking。更早的 MiniMax 模型则会直接忽略 effort 字段。

reasoning_effort 的跨厂商语义差异：OpenAI 在 o 系列模型中引入 reasoning_effort，最初只有 low/medium/high 三档，后扩展至 xhigh 等更细粒度。Anthropic 的 output_config.effort 与 Responses API 的 reasoning.effort 是各自对同一概念的不同封装，网关（如 AIHubMix）在转发时需要做映射。问题在于各厂商对"未知值"和"none"的处理并不统一：有的直接拒绝，有的静默回退到默认档，还有的把 effort 翻译成内部的思考预算（thinking budget）。因此同一个字符串在不同端点上可能产生完全不同的实际计算量，这也是文中"静默失效"失败模式的根源。

thinking token 的计费口径：多数推理模型将内部思考产生的 token 计入输出侧计费，而非单独计价。这意味着 effort 档位直接决定账单大小，因为更高的档位会产生更多 reasoning token，而它们在 usage 中以 completion_tokens_details.reasoning_tokens 等形式单独报告。M2.x 时代的模型忽略 effort 字段、思考量相对固定，迁到 M3.1 Flash 后若沿用旧代码，计费模型会从"固定思考开销"变成"按档位放大"，成本曲线随之改变。

测量结果：质量持平，成本差距悬殊

六种配置的平均数据如下：

Effort	平均思考 token	三次范围	平均耗时	每次修复成本	测试结果
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

这张表能支持几个判断。质量完全持平：18 次 Chat 运行，18 个完美修复，在这个有边界的 bug 上，超过 low 的思考没有带来任何可测量的收益。low 到 medium 是真实的一步：思考 token 约为 2.6 倍，时间翻倍以上。但在 medium 之上，每组只有三次运行，无法对档位排序——xhigh 的平均值反而低于 high，max 与两者都有重叠。省略字段与 max 基本一致，符合文档说明，更高的平均值在运行间噪声范围内。

时间与 token 强相关。全部 24 次 Flash 运行（Chat 和 Messages）的吞吐稳定在约每秒 112 个输出 token，所以一次 6,000 token 的思考要花接近一分钟的实际时间。

短提示词的表现完全不同

自适应思考的深度会随提示词缩放。把五张支持工单分到四个标签，low 档用了 0 个思考 token，默认档平均用了 6 个，标签全部正确。"17 × 23 等于多少？"在 low 档下没有产生思考，只有 2 个输出 token。对分类类调用来说，缺少关闭开关几乎不产生额外成本。

自适应思考（adaptive thinking）：这是 MiniMax M3.1 Flash 强制的行为模式，模型会根据提示词复杂度自行决定思考深度，无法通过 thinking: {"type": "disabled"} 或 effort 为 none 关闭。其后果是：同一个 effort 档位在不同输入上的实际思考量差异极大——短分类提示词在 low 档下可能产生 0 个思考 token，而编码任务在同一档位下可能上千。这也是文中"固定档位下延迟尖峰"现象的机制来源。对超时设置而言，effort 设定的是平均深度而非硬上限，工程师不能用某档位的平均耗时乘以安全系数来定超时，而应参考该档位的最大值或进一步放宽。

随机性与样本量：每个档位仅三次运行，均值受单次极端值影响很大。文中的 xhigh 均值低于 high、max 与两者重叠，都可能只是三样本下的噪声，而非真实的档位排序。要判断 medium 之上谁更划算，需要更大的样本量（例如每档 20 次以上）并报告分布而非均值。此外，单次运行的思考 token 波动可跨越数倍（如 Messages 端点 low 档从 511 到 6,060），这意味着单次成本预测本身就不稳定，预算估算应基于均值加尾部风险。

六种失败模式与对应修复

思考导致截断。 思考 token 计入 max_tokens。某次默认运行在一个函数上用了 9,376 个思考 token。从 M2.x 继承来的 4K 或 8K 上限可能以 finish_reason: "length" 结束并给出被切断的答案。修复方式是提高 max_tokens（MiniMax 建议 131,072，上限 524,288），并检查 finish_reason。

固定档位下的延迟尖峰。 在 Anthropic Messages 端点上，三次 low 运行的思考 token 分别是 511、1,861 和 6,060，最后一次耗时 56 秒。effort 设定的是平均深度，不是上限。修复方式是在 high 及以上档位把客户端和代理超时设到 120 秒以上，不要仅凭 low 的平均值来定超时。

静默失效的 effort 值。 通过 AIHubMix，reasoning_effort 传 none、minimal、auto 都返回 HTTP 200，模型照常思考。据一个网关项目的测试（sub2api issue #8025），MiniMax 自己的端点会拒绝未知值。修复方式是只发送五个文档化的值之一。AIHubMix 的统一推理参数文档描述了网关如何跨厂商映射推理字段。

不发送档位的工具。 OpenCode 对这个模型解析不出 effort 变体（anomalyco/opencode issue #54801），它的 effort 开关不起作用。一些框架还会发送"thinking disabled"，导致 400 错误。修复方式是检查实际发出的请求体。

混合模型路由。 M3 和 M2.x 会忽略 effort 字段，所以在 Flash 上省钱的档位在其他模型上毫无作用。

验证设置真的到达了模型。 读取 usage：Chat 协议看 completion_tokens_details.reasoning_tokens，Messages 协议看 output_tokens_details.thinking_tokens，Responses 协议看 output_tokens_details.reasoning_tokens。如果改变档位时这些数字不动，说明设置根本没有传到模型。

按任务选择起点

只有前两行有上述测量支撑，其余是根据重试率自查的建议。分类、抽取、路由类任务从 low 起步，难例标签出错时再上调。单函数修复、小规模审查从 low 起步，修复两次测试失败后再升。多文件修改、重构从 medium 起步，agent 漏掉依赖文件时再升。带大量工具调用的 agent 循环从 low 或 medium 起步，步骤重复或停滞时再升。硬调试和设计问题从 high 起步，答案持续浅薄时再升。交互式聊天、有人在等结果时从 low 起步，永远不要在这里默认用 max。

无法验证的部分

更高的档位从哪里开始回本，这次测不出来。任务在每个档位都被解决了，MiniMax 也没有发布按档位划分的 token、延迟或准确率数据，一个有边界的任务无法显示 high、xhigh、max 何时值得它们的成本。medium 之上的排序同样不成立：每个档位三次运行不足以区分 high、xhigh、max。此外，所有数字都来自一个短编码提示词和一个分类提示词，由 AIHubMix 测量，目前没有第三方复现。

对迁移中的团队来说，最有操作性的结论只有一条：显式设置 low，然后按任务往上调。 把 effort 当成一个需要主动配置的参数，而不是可以省略的默认项。