9月24日消息，MiniMax 还没有发布过的型号 M3.1，出现在其官方开源项目 MiniMax Code 的仓库里。线索来自公开仓库的测试代码，不是官方公告。值得关注的问题是：这些代码能证明什么，又不能证明什么。
测试代码里的 M3.1
MiniMax Code 是 MiniMax 开源的终端编程 Agent，仓库最新版本为 0.5.4。在负责模型选择的测试文件中，一个测试用例把 MiniMax-M3.1 设为默认模型，并配了一套完整约束。思考强制开启，不能关闭。思考强度分 low、high、max 三档，目录默认 high。上下文只认 512K 和 1M 两档，填中间值会直接报错。输出上限 128K tokens。
测试还约定了默认行为：不指定模型时按运行时默认走，即 max 档加 1M 上下文；只点名 M3.1 时，回落到目录默认的 high 档和 512K。也就是说，这个托管目录既提供默认值，也做硬校验。
代码能说明什么
这个锚点公开可查：代码在 MiniMax 官方组织的仓库 main 分支上，任何人可以逐行核对。参数具体到档位和默认值，不像随手写的占位符。同一个文件里还维护着 M3 的同类测试：M3 官方档默认 512K、最大 1M，与 M3.1 的选项完全一致，两个型号并列存在。
这些放在一起，「MiniMax 产品体系里存在 M3.1 这个型号，并且被 MiniMax Code 当作默认模型」的可能性较高。支撑是三件事：官方仓库、参数密度、与 M3 并列维护。
不能说明的部分
有一个反直觉的细节：M3.1 的约束参数和 M3 一模一样。这削弱了「M3.1 是全新升级权重」的直觉。同样成立的解释是，它只是 M3 在 API 或 Agent 渠道的产品侧新型号，对外模型线仍叫 M3。新模型先在自家 Code 渠道落地、之后再官宣，也不能排除。
所以，M3.1 是不是新权重，现有证据无法判断；「产品侧型号」的解释目前更顺。
另有一层边界：这些约束写在测试配置里。测试配置反映的是目录数据的形态，不等于线上产品的真实配置。「思考强制开启、默认 high 档」会不会原样进入产品，判断只能到中等。
目前，MiniMax 未公布过这一型号，也未回应此事。
AI 速览
