auto 档在 on_base 为空的 provider 上表达不了「开」，ENABLE_THINKING=true 会静默不推理 #21

New Issue

2026-09-05T22:36:56+08:00

iomgaa commented

2026-09-05 22:36:56 +08:00

一句话

auto 档在 on_base 为空的 provider 上表达不了「开推理」,而 resolve_thinking 的 Phase 5 又无条件放行它——于是 ENABLE_THINKING=true 配在 MiniMax-M3 上会静默不推理。1.3.3 已用权宜之计堵住 minimax 一段,正解待本 issue。

怎么发现的

2026-09-05 T10 经 new-api 对 26 个模型逐个实测(约 500 次真实调用)时撞到。当时的判断是「on_base={} + AUTO 不注入任何参数,语义仍是『开』,因为这些模型默认都推理」——实测推翻了它: MiniMax-M3 不发任何推理参数时 5/5 轮不推理,而六个强度值 minimal/low/medium/high/xhigh/max 全部生效且彼此等价。

机制

三层各让一步,合起来就是静默:

层	行为	为什么堵不住
provider wire	`minimax.on_base = {}`	「开」这件事本身不发任何字节,完全依赖「模型默认就推理」这个前提
能力表	M3 的 `supported_efforts` 实测为 `(none, minimal, low, medium, high, xhigh, max)`,不含 `auto`	表里已经如实记了「本模型没有 auto 这一档」
`resolve_thinking`	Phase 5 对 `auto` 无条件放行,不查清单	放行的理由是: `auto` 在请求体里是「不写 `effort_key`」而非某个取值,可满足性只取决于 `on_base` 在不在

第三层的理由在 on_base 非空时成立(qwen/deepseek/zhipu/moonshot: 发 enable_thinking:true 或 thinking.type:enabled,确实与档位无关),在 on_base 为空时不成立——那时「开」根本没有载体。

1.3.3 做了什么(权宜)

把 minimax.on_base 改回 {"reasoning_effort": "medium"}(与本次换代前逐字相同),恢复旧行为。代价是退回了「库替下游选一个档」,而那正是本次工作要消灭的东西。

只动了 minimax 一段。openai/anthropic/google 三段同样是 on_base={},但它们涉及的模型(gpt-5.x / claude-5 / gemini-3)默认都推理(OpenRouter 记 default_enabled: true 或 mandatory: true),未被实测覆盖(claude 撞 7 天限额、gemini 上游报错、gpt-5.4 全账号限流),故按无证据不动处理。

正解的几个方向(未定,需 brainstorming + 人类门)

让 auto 受能力表约束: 清单不含 auto 时报错并指路显式档位。语义最干净,但会让存量 ENABLE_THINKING=true 配在档位型模型上一律报错——需要评估三项目迁移影响。
能力表记「默认是否推理」: 恢复一个类似 default_enabled 的事实字段(初稿曾有 default_effort,因当时无消费者被删,现在有了)。auto 在「默认不推理」的模型上转为报错或映射到最省档。
wire 增 auto_effort 字段: 由 provider 声明「auto 该发什么」,minimax 填一个档。比方向 2 少一张表,但把模型级事实塞进了 provider 级声明,与既有的形态/能力分层相悖。

选型时注意: 这三条都改变公共行为,按 CLAUDE.md 属 MANDATORY brainstorming + 人类确认。

验收判据

ENABLE_THINKING=true + MiniMax-M3 时,库要么真的开启推理,要么明确报错并给出可执行档位——不允许静默不推理。且 openai/anthropic/google 三段在其模型被实测覆盖后,同一判据要重跑一遍。

## 一句话 `auto` 档在 `on_base` 为空的 provider 上表达不了「开推理」,而 `resolve_thinking` 的 Phase 5 又无条件放行它——于是 `ENABLE_THINKING=true` 配在 MiniMax-M3 上会静默不推理。1.3.3 已用权宜之计堵住 minimax 一段,正解待本 issue。 ## 怎么发现的 2026-09-05 T10 经 new-api 对 26 个模型逐个实测(约 500 次真实调用)时撞到。当时的判断是「`on_base={}` + `AUTO` 不注入任何参数,语义仍是『开』,因为这些模型默认都推理」——**实测推翻了它**: MiniMax-M3 不发任何推理参数时 5/5 轮不推理,而六个强度值 minimal/low/medium/high/xhigh/max 全部生效且彼此等价。 ## 机制三层各让一步,合起来就是静默: | 层 | 行为 | 为什么堵不住 | |---|---|---| | provider wire | `minimax.on_base = {}` | 「开」这件事本身不发任何字节,完全依赖「模型默认就推理」这个前提 | | 能力表 | M3 的 `supported_efforts` 实测为 `(none, minimal, low, medium, high, xhigh, max)`,**不含 `auto`** | 表里已经如实记了「本模型没有 auto 这一档」 | | `resolve_thinking` | Phase 5 对 `auto` **无条件放行**,不查清单 | 放行的理由是: `auto` 在请求体里是「不写 `effort_key`」而非某个取值,可满足性只取决于 `on_base` 在不在 | 第三层的理由在 `on_base` 非空时成立(qwen/deepseek/zhipu/moonshot: 发 `enable_thinking:true` 或 `thinking.type:enabled`,确实与档位无关),在 `on_base` 为空时不成立——那时「开」根本没有载体。 ## 1.3.3 做了什么(权宜) 把 `minimax.on_base` 改回 `{"reasoning_effort": "medium"}`(与本次换代前逐字相同),恢复旧行为。代价是退回了「库替下游选一个档」,而那正是本次工作要消灭的东西。只动了 minimax 一段。`openai`/`anthropic`/`google` 三段同样是 `on_base={}`,但它们涉及的模型(gpt-5.x / claude-5 / gemini-3)默认都推理(OpenRouter 记 `default_enabled: true` 或 `mandatory: true`),**未被实测覆盖**(claude 撞 7 天限额、gemini 上游报错、gpt-5.4 全账号限流),故按无证据不动处理。 ## 正解的几个方向(未定,需 brainstorming + 人类门) 1. **让 `auto` 受能力表约束**: 清单不含 `auto` 时报错并指路显式档位。语义最干净,但会让存量 `ENABLE_THINKING=true` 配在档位型模型上一律报错——需要评估三项目迁移影响。 2. **能力表记「默认是否推理」**: 恢复一个类似 `default_enabled` 的事实字段(初稿曾有 `default_effort`,因当时无消费者被删,现在有了)。`auto` 在「默认不推理」的模型上转为报错或映射到最省档。 3. **wire 增 `auto_effort` 字段**: 由 provider 声明「`auto` 该发什么」,minimax 填一个档。比方向 2 少一张表,但把模型级事实塞进了 provider 级声明,与既有的形态/能力分层相悖。选型时注意: 这三条都改变公共行为,按 CLAUDE.md 属 MANDATORY brainstorming + 人类确认。 ## 验收判据 `ENABLE_THINKING=true` + MiniMax-M3 时,库要么真的开启推理,要么明确报错并给出可执行档位——**不允许静默不推理**。且 `openai`/`anthropic`/`google` 三段在其模型被实测覆盖后,同一判据要重跑一遍。

iomgaa referenced this issue from a commit

2026-09-06 00:43:53 +08:00

fix: put the tier back where "on" by itself is not on

iomgaa referenced this issue from a commit

2026-09-06 00:43:53 +08:00

docs: cut 1.3.3 notes for the tier work

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: iomgaa/PolyGateway#21