请求图片超过上限后无法继续、无法压缩上下文，导致会话无法继续

[ddxl123]

本轮运行失败400: {"param":null,"type":"invalid_request_error","message":"Error from provider (Console Go): Upstream request failed: [invalid_request_error] Too many images in request: 31 > 30"}
INVALID_REQUEST
失败

/compact
Compaction could not produce a useful summary. The conversation is unchanged; the attempt is recorded in the se

[Ariex]

官方的文档说支持图片的那个模型应该允许600张图，所以限制可能是在dsh里。
最简单的方法就是，在对话历史里找到第31个图片上传的那个消息之前的最后一条可fork的消息，从那里fork一个新的session，这样只要不再继续贴图片，就可以保留原有聊天的基础上继续说下去了。
复杂点的方法就是，找到官方的有这个限制的部分，既然一切都是插件，你也可以写个插件去掉这个限制，然后替换掉官方的。
再再复杂点的方法，可以找一套记忆系统，把以后的session都存进去，这样无论在哪个session都可以秒回忆出之前聊过的东西了。这有现成的，也可以让dsh给你写一套，我就自己搞了一个，确实很好用，随便开session都行。

[PerryLink]

楼上说反了方向：600 是 DSH 自己的上限，30 才是上游 API 的限制。问题不是「DSH 拦你」，而是两边上限不一致，导致 DSH 的图片卸载机制永远不会触发。

机制（0.1.5-rc.2 源码逐行核对）

1. llm-deepseek 每次请求在序列化前都会做最老优先的图片卸载，packages/llm/llm-deepseek/src/adapter.ts:560-568：

const requestMessages = offloadRequestImagesWithPolicy(options.messages, {
  representation: 'raw',
  maxBytes: connection.maxRequestFilesBytes,
  maxImages: connection.maxImagesPerRequest,        // ← 默认 600
  byteQuantum: connection.imageOffloadByteQuantum,
  countQuantum: connection.imageOffloadCountQuantum, // ← 默认 20
  ...
})

2. maxImagesPerRequest 默认 600（index.ts:198）。你的上游在 31 张 就拒绝，而 31 < 600 ⇒ 卸载判定永不触发 ⇒ 31 张原样发出 ⇒ 上游 400。

3. 这也解释了 /compact 为什么救不了：compaction 压缩的是文本；图片作为历史内容留在会话里，压缩完请求还是 31 张图。

修复：把 DSH 的上限调到上游限制之下

settings 里 llm-deepseek 段：

llm-deepseek:
  maxImagesPerRequest: 20       # 低于上游的 30
  imageOffloadCountQuantum: 5   # 必须 ≤ maxImagesPerRequest（index.ts:363-364 有校验）

之后请求超过 20 张时，DSH 会按最老优先把超出的图卸载（替换成文本占位），上游就只会看到 ≤20 张，会话可以继续。

代价：最老的图不再以图像形式参与上下文 —— 这正好是你要的「能继续」；如果你需要那些图的视觉内容，就按楼上说的从第 31 张之前 fork 一个新会话。

（两条字段的校验见 packages/llm/llm-deepseek/src/index.ts:340-364。）

[Ariex]

关于最大600，来源是 https://api-docs.deepseek.com/zh-cn/guides/vision，这也算是“上游限制”吧，我一般都是用的这个。
此外dsh代码里也没那段错误信息。所以正如 @PerryLink 老兄说的， @ddxl123 的问题可能出在上游，你的大模型提供商不允许超过30张图。 @PerryLink 的解决方案也是最适合你的。