llm-pi-ai 缺少「每请求图片张数」预算：遇到有硬性图片上限的路由（opencode-go / deepseek-v4.1-flash，>16 张）会让整个会话永久报废

[bailihua93]

环境

• dsh 0.2.1-rc.5（桌面版）
• provider: opencode-go，model: deepseek-v4.1-flash（api: openai-completions）
• @deepseek-ai/dsh-llm-pi-ai 0.2.1-rc.5，@earendil-works/pi-ai 1.1.0

现象

一个以截图为主的会话里，用 read_image 读入第 17 张图片之后，请求开始失败：

400 invalid_request_error
Upstream request failed: [invalid_request_error]
this feature is not yet supported by atlas (request_id: gw-ad8e54dbb9ce-1e0baf)

之后每一轮都在第 1 步就失败，usage 全为 0（请求体根本没被接受）。也就是说这个会话
永久无法继续，而 UI 里没有任何办法把历史中的旧图片去掉。

最小复现（同一 key、同一路由，直接打 API）

请求内容	结果
16 张图	200
17 张图	400（18、20 张同样 400）
17 张图集中在一条消息里	400
16 × 15KB 小图	200
17 × 15KB 小图	400

可见上限与体积无关：16 张共约 14MB 可以通过，17 张共约 225KB 反而失败。

上限是模型级而非路由级：同一个 key 下 deepseek-v4-pro、claude-haiku-5-5 分别接受
17 / 32 / 64 张图片（均 200），只有 deepseek-v4.1-flash 的后端（错误信息中的
"atlas"）卡在 16 张。

在 dsh 内的复现路径：在同一个会话里连续调用 read_image 17 次，然后继续对话即可。

预期行为

适配器应该统计请求中的图片出现次数，超限时以 IMAGE_OFFLOAD_REQUIRED 失败（就像
llm-deepseek 适配器那样），从而让 dsh-compaction-image-offload 把最旧的图片替换成
占位文本并重试本次请求。

实际行为

返回的只是一个通用的 INVALID_REQUEST 400：不会抛出 IMAGE_OFFLOAD_REQUIRED，
image-offload 插件不会动作，该轮次直接报错结束；而图片仍然留在历史里，于是后续每一轮
都复现同一个 400。

根因（看起来是某一个适配器漏接）

• @deepseek-ai/dsh-llm 的 offloadedImagePrefixCount() 本来就支持
  budget.maxImages 与 budget.countQuantum。
• @deepseek-ai/dsh-llm-deepseek 已经接上了：bounds() 传入
  maxImages: connection.maxImagesPerRequest（默认 600）和
  countQuantum: connection.imageOffloadCountQuantum（默认 20）。
• @deepseek-ai/dsh-llm-pi-ai 只传了 { representation: "base64", maxBytes } 给
  requiredImageOffload；其 provider profile schema 里只有 maxRequestImageBytes /
  requestImageMaxBytes / requestImagePixelBudget，完全没有张数预算字段。

建议修复

1. 给 pi-ai 的 provider profile schema 增加 maxRequestImages（正整数，默认 600，
   与 llm-deepseek 对齐），并在 requiredImageOffload 的预算对象里作为 maxImages
   传入（可另加 countQuantum）。
2. 更好的做法是让模型目录也能声明该上限，例如在
   inputLimits.images.maxCount 中为 opencode-go/chat:deepseek-v4.1-flash 设为 16。
   注意：仅靠 deepseek 适配器的 600 默认值对这条路由仍然过高，按模型给值才是真正的修法。
3. 无论适配器如何，建议让这类失败可恢复：当某条路由因携带图片而拒绝请求时，给出明确的
   用户可见路径（"卸载旧图片后重试"），而不是直接结束轮次。

影响面

任何截图密集的会话（浏览器 QA、UI 走查、视觉 diff）都会撞上——17 张截图是很低的门槛，
而且失败是永久性的，不是瞬时抖动。

已验证的临时绕过

把该会话的模型切换为 claude-haiku-5-5，待发的请求即可通过；随后执行 /compact
压缩掉旧图片。