OMP M3 模型补丁：为 pi-ai 添加 MiniMax M3 支持

Mon, 01 Jun 2026 12:00:00 +0800

MiniMax 在 2026-06-01 发布了 M3 模型（OpenRouter 上的 ID 是 minimax/minimax-m3-20260531），但 @oh-my-pi/pi-ai@15.7.3 自带的 models.json 还没来得及更新。这篇文章记录了我手动给 M3 加支持的过程——给全部 5 个 provider 端点都加上了对应的模型条目。

目标文件

1

~/.bun/install/global/node_modules/@oh-my-pi/pi-ai/src/models.json

添加的 Provider 条目（5 个）

所有条目都追加在各自 provider 对象的末尾，结构完全参照已有的 MiniMax-M2.7 条目。

1. `minimax`（官方 Anthropic 兼容 API）

key: MiniMax-M3
api: anthropic-messages
baseUrl: https://api.minimax.io/anthropic
contextWindow: 204800, maxTokens: 131072
费用: input 0.3, output 1.2, cacheRead 0.06, cacheWrite 0.375
thinking: budget 模式, minimal..xhigh

2. `minimax-cn`（官方 Anthropic 兼容 API，国内）

key: MiniMax-M3
api: anthropic-messages
baseUrl: https://api.minimaxi.com/anthropic
上下文窗口、费用和 thinking 配置与 minimax 相同

3. `minimax-code`（Coding 计划，OpenAI 兼容）

key: MiniMax-M3
api: openai-completions
baseUrl: https://api.minimax.io/v1
费用: 全部为 0（Coding 计划包月制）
兼容性: supportsStore=false, supportsDeveloperRole=false, supportsReasoningEffort=false, reasoningContentField=reasoning_content
thinking: effort 模式, minimal..high

4. `minimax-code-cn`（国内 Coding 计划）

与 minimax-code 镜像，baseUrl 改为 https://api.minimaxi.com/v1，provider 为 minimax-code-cn。

5. `openrouter`（OpenRouter 中转）

key: minimax/minimax-m3-20260531
api: openai-completions
baseUrl: https://openrouter.ai/api/v1
费用: input 0.3, output 1.2, cacheRead 0.05, cacheWrite 0
thinking: effort 模式, minimal..high

验证

在补丁文件中搜索 "MiniMax-M3|minimax-m3" 恰好返回 5 个匹配——每个 provider 块一个。

注意事项

omp update 会覆盖这个补丁。更新后需要重新打补丁，或者锁定包版本。
如果上游后续发布了官方 M3 条目，本地副本可能会与官方版本产生差异（定价/上下文窗口不同），直到下次更新。
M3 的定价数据是根据 M2.7 模板和 OpenRouter 列表（$0.30 / $1.20）推断的。如果对成本准确性有要求，请以 MiniMax 官方定价页面为准。
上下文窗口（204800）和 maxTokens（131072）沿用了 M2.7 的参数——如果 M3 正式版有调整，请相应修改。

补遗（2026-06-02）：走 OMP 用户配置的正规路线

上面的 pi-ai 补丁是 hack：omp update 一执行，bun 重新拉包，patch 直接被冲掉。 OMP 推荐的正道是 ~/.omp/agent/models.yml——在用户目录下追加 provider， OMP 启动时按「内置 → 自定义 merge」顺序加载，不依赖 bun 全局路径，也不会被 omp update 覆盖。

最终配置

在 ~/.omp/agent/models.yml 末尾追加：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# MiniMax M3 Code Plan
# 需先在 ~/.zshenv 配置 MINIMAX_API_KEY
 minimax:
 baseUrl: https://api.minimaxi.com/anthropic
 apiKey: MINIMAX_API_KEY
 api: anthropic-messages
 authHeader: true
 disableStrictTools: true
 models:
 - id: MiniMax-M3
 name: MiniMax M3
 reasoning: true
 input: [text, image]
 contextWindow: 1000000
 maxTokens: 16384
 cost:
 input: 0
 output: 0
 cacheRead: 0
 cacheWrite: 0

apiKey: MINIMAX_API_KEY 走 OMP 的解析约定：先当 env name 取值，取不到再当字面量。我在 ~/.zshenv 里 export MINIMAX_API_KEY=$MINIMAX_CODE_PLAN_KEY，所以 key 是从环境变量读的，dotfile 本身保持纯净，可以直接进 git。

几个关键选择

为什么选 anthropic-messages 而不是 openai-completions： M3 同时支持两套协议。先用 openai-completions 试了一轮有两个小坑：

OMP 在 openai-completions 下对 reasoning 模型会发 developer role + reasoning_effort，MiniMax 这边的 schema 校验比 OpenAI 严格，reasoning 字段为空时会偶发 400
切到 anthropic-messages 后，工具调用、流式 reasoning 都直接走 Anthropic SDK 归一化路径，跟 kimi、claude 走同一条 promote 链路

为什么 disableStrictTools: true： Anthropic SDK 默认会给所有 tool 发 strict: true，第三方 Anthropic 兼容网关（MiniMax、kimi 等）通常不识别这个字段，会直接 400。同文件里 kimi provider 也开了这个 flag，是接入第三方 Anthropic 端点时基本必开的开关。代价是工具 schema 不会被服务端强校验，偶尔需要靠 prompt 兜底。

上下文窗口 1M / maxTokens 16K： contextWindow 取 1M 是按 OpenRouter 上 minimax/minimax-m3-20260531 的 spec 填的（M2.7 是 204800，M3 翻了 5 倍）。maxTokens 沿用 M2.7 的 16K，没找到 M3 官方精确数字。cost 全 0 是因为 Code Plan 是包月制，按 token 计费为 0。

切换使用

1
2
3
4
5


# 启动时直接指定
omp --model minimax/MiniMax-M3

# 或在 TUI 内
/model minimax/MiniMax-M3

切到 M3 后，/status 里应该能看到 ANTHROPIC_BASE_URL（OMP 内部字段名）指向 api.minimaxi.com/anthropic。

两条路的关系

维度	pi-ai 内置 models.json 补丁	models.yml 自定义 provider
持久性	`omp update` 覆盖	持久
多机同步	否（路径依赖 bun 全局）	是（dotfile 走 git）
升级成本	重新打补丁	OMP 自动 merge
优先级	与内置合并	与内置合并，后写覆盖

两者是叠加关系，不冲突。models.yml 加的 provider 走 OMP 的「自定义」通道， pi-ai 后续合并的 M3 条目（如果官方补上）走「内置」通道。如果两条都对同一个 provider/model 写了不同 baseUrl，OMP 用 last-write-wins 规则—— 所以 models.yml 永远会赢内置。

M3 on Svtter's Blog