Auto review 预设与 Codex 推理模型不兼容（temperature 透传被拒）+ GPT-6 声明窗口远低于订阅上限

[Flipped929]

现象：将 Codex 订阅推理模型（如 gpt-6.1-sol）设为主控并开启 Auto review（EXP 权限预设）后，每次工具调用前审核报 auto-review: reviewer ended with error PI_AI_ERROR: Codex error: Unsupported parameter: temperature；长会话在约 272K 处被 pi-ai detected context overflow / CONTEXT_WINDOW_EXCEEDED 预检拒绝。

根因（两个独立问题）：

dsh-experimental-auto-review 的 classifyRisk 硬编码 temperature: 0 且强制复用当前会话主控模型（snapshot.provider/model），而 pi-ai 的 OpenAI Responses 通道对 temperature 无条件透传；Codex 推理模型不收该参数，审核器必炸——Auto review 与 Codex 推理模型主控不兼容。
模型目录给 gpt-6.1-sol 声明 contextWindow: 272000（Codex CLI 目录缓存值），但 Codex 订阅通道的服务端校验上限是 872K（裸 API 达 1.1M），声明值低估了 3 倍多，导致长会话在真实能力远未触顶时被预检误拒。
建议修复：① classifyRisk 不要在推理模型上带 temperature（或在 compat 上加 supportsTemperature 判定，参照 anthropic-messages 协议 gate 的既有做法）；② 将 Codex GPT-6 系列的声明 contextWindow 从 272K 对齐到订阅侧服务端校验上限 872K。临时规避：用标准权限预设（非 Auto review）+ 手动把 profile 里 GPT-6 条目的 contextWindow 改成 872000。

[Flipped929]

后续问题：Codex GPT-6 推理模型的自动压缩（compaction）损坏——effort:"none" 被拒，超限会话无法自救

环境：DSH 桌面版，服务商 openai-codex（ChatGPT 订阅 OAuth），在 cordis.patch.yml 中声明了 gpt-6-sol / gpt-6-luna / gpt-6-astra / gpt-6.1-sol，contextWindow: 872000、maxTokens: 128000。

会话超过服务端输入上限后，每轮都报错：

Codex error: Your input exceeds the context window of this model. Please adjust your input and try again. (CONTEXT_WINDOW_EXCEEDED)

同时自动压缩自救每次都失败：

Codex error: Unsupported value: 'none' is not supported with the 'gpt-6.1-sol' model. Supported values are: 'low', 'medium', 'high', 'xhigh', and 'max'.

会话日志证据（turn 334）：最后一次成功请求 input 18,050 + cacheRead 899,200 = 总计 917,804 tokens，服务端接受；下一次请求（约 930K）被拒。据此推断服务端包络约为 input + max_output_tokens ≤ ~1,048,576。所以之前把 contextWindow 修到 872000 是对的——这次的新问题出在自救链路本身。

根因——dsh-llm-pi-ai 与 pi-ai 的 codex 适配器之间语义断裂：

• dsh-llm-pi-ai 的 resolveModelReasoning（lib/index.js 约 L553–592）：profile 里写 reasoningEfforts: { off: null } 的意图是"不发送参数"，实现是让 off 键缺席于 thinkingLevelMap（注释写明"absent = supported, send nothing"）。完全未声明 reasoningEfforts 的模型则连 map 都没有。
• pi-ai 的 openai-codex-responses.js L414–428：请求 effort 为 "none" 时发送 thinkingLevelMap?.off === undefined ? "none" : thinkingLevelMap.off；无 effort 的分支发送 effort: model.thinkingLevelMap?.off ?? "none"。也就是说，只要 map 里没有 off 键，线上请求就会带上字面量 "none"，而 Codex GPT-6 后端会拒收（这类模型无法关闭思考）。
• 结果：dsh-compaction-basic 的自救请求在参数校验层就被拒，超限会话永远无法自动压缩。压缩器本身的预算设计没问题（保留原文尾巴 + 摘要头部、按窗口预算裁剪），纯粹卡在请求构造的参数上。

规避方案（已过 profile schema 校验）： 给每个 Codex GPT-6 模型显式声明 off 的实值：

reasoningEfforts:
  off: low        # 必须是实值；写 null 或缺省都会弄坏压缩
  minimal: low
  low: low
  medium: medium
  high: high
  xhigh: xhigh
  max: max

off: low 只影响“off”这个伪档位（该模型本来就关不掉思考），其余档位不受影响。改完后自动压缩正常工作，超限会话可以恢复。

上游修复建议：

1. pi-ai codex 适配器：thinkingLevelMap 缺 off 键时应省略 reasoning 参数（或回落到模型最低档），而不是发字面量 "none"——与 dsh-llm-pi-ai 文档化的语义对齐。
2. 文档标注订阅侧包络（≈ input + max_output ≤ 1,048,576）；实测 contextWindow: 872000 + maxTokens: 128000 是一组安全组合。

（本线程此前已报告：① auto-review 的 classifyRisk 硬编码 temperature: 0，Codex 推理模型拒收——Auto review 与 Codex 主控模型不兼容；② 目录 contextWindow: 272000 比订阅侧实际上限低了约 3 倍。）

[PerryLink]

你的定位在源码里逐字命中：temperature: 0 是硬编码的

1. 代码（HEAD = dsh-v0.2.1-alpha.1）

packages/experimental/auto-review/src/index.ts:634
    temperature: 0,

⇒ 你说的"classifyRisk 硬编码 temperature: 0"完全正确（该行是字面量，没有任何条件判断或按模型分支）。

2. 为什么这对 Codex/推理模型是致命的

新一代推理模型（含你举的 gpt-6.1-sol）不接受 temperature ⇒ 传了就报 Unsupported parameter: temperature。⇒ 而这里无条件传 ⇒ 凡是这类模型当主控 + 开 Auto review，每次工具调用前的审核必然失败 ⇒ 不是"偶发不兼容"，而是该组合不可用。

建议把这一句写进摘要："硬编码的 temperature 使 Auto review 与所有拒绝该参数的推理模型互斥"——这比"不兼容"更能说明范围。

3. 修法（两条，第一条最小）

1. 不要无条件传：把 temperature 做成可选，或按路由/模型能力决定是否携带（最简单的是：推理模型不带该参数）；
2. 更通用：审核调用本身不应复用主控模型的采样参数——它的目的是分类风险，采样温度为 0 只是"想要确定性"的实现手段；⇒ 应当由审核自己的配置决定，而不是顺手继承主控。

建议第 2 条作为诉求：它把"改一个字面量"变成"审核调用与主控解耦"，从而不会再被下一个模型特性打破。

4. 你的第二个问题（272K 被预检拒绝）请单独提一条

你写"长会话在约 272K 处被 pi-ai detected context overflow / CONTEXT_WINDOW_EXCEEDED 预检拒绝"，而订阅上限更高。⇒ 这是独立的第二个问题（声明窗口 vs 实际预检阈值不一致），与 temperature 无关。

建议拆开（你已注明"两个独立问题"，请把这一点放在最前面），并补：该模型的声明窗口是多少、预检阈值是多少（两个数字并列即可判定）。

5. 请补一样

ClassifyRisk 的调用点是否复用主控的其它参数（例如同一处还传了别的采样参数）⇒ 若还有别的硬编码参数，一并列出能避免"修完 temperature 又撞下一个"。

6. 版本

请补你复现的版本；我在当前最新 HEAD 上核到 :634 仍是字面量 temperature: 0 ⇒ 无需在新版重测即可确认存活。