中转站按 base64 文本计价时，图片成本比 token-meter 高约 3,500 倍；且 pi-ai 的静默溢出判定会丢弃已完成回答

[lomom]

中转站把 base64 当文本计价时，图片成本比计量器高约 3,500 倍，且 pi-ai 的静默溢出判定会丢弃已完成回答

Summary

在 api: anthropic-messages 的中转路由上，图片被上游按 base64 文本计价（实测 ≈1 provider token / 原始图片字节），而 dsh-token-meter 把每个 image 块按附件引用 JSON 的长度计价（55–59 token/张）。两者相差约 3,500 倍。后果是：图片累积到"像素本身吃掉 95% 上下文额度"时，harness 侧的仪表仍显示只用了 6 万 token，压缩永远选不中图片，最后撞上上游硬 400：

400 {"error":{"type":"InvalidParameter","message":"Input exceeds the context limit (1048568 tokens). Please shorten the input. ...

另外在同一份日志里发现第二个独立缺陷：mapStopReason 的静默溢出判定会把已经完成的回答整段丢弃并判 CONTEXT_WINDOW_EXCEEDED（与 #9230 同类，但发生在 llm-pi-ai + anthropic-messages 路径上）。

Environment

• DeepSeek Harness Desktop 0.2.1-rc.3（安装包 44.7.0），Windows x64
• 路由：llm-pi-ai 自声明路由 blow，api: anthropic-messages，baseURL: https://boclaw.cn，模型 deepseek-v4.1-flash
• 该模型条目只声明了 id / name / input: [text, image]，未声明 contextWindow、未声明任何图片字节预算（resolveProfiles 因此取 defaultContextWindow = 262144）
• 9 份会话日志（$DSH_HOME/sessions/*/session.v4.jsonl.zstd），2769 个成功步骤，4 份会话复现同一个 400
• 无 API key、无对话正文、无用户标识随本报告提供

复现

会话里连续 read_image 几张全分辨率截图即可。最小复现是一份只跑了 19 步的会话：两次 read_image 读入 1920×1080、751,223 B + 758,081 B 两张 PNG，inputTokens 才涨到 102,276 就 400 死掉——因为这两张图的真实成本约 1,373,466 token，已经超过上游的 1,048,568。

主要会话（session-66e87b4e，38 个 assistant 步）的触发点是确定的：

seq	事件	值
461	最后一次成功的 assistant/message	inputTokens = 735,304（其中 4 张图 724,814 B ≈ 659,580）
462	tool/call read_image {"file_path":"p0026_root.png"}	—
463	tool/result，+375,255 B	≈ +341,482 token
468	assistant/attempt finish	400 ... Input exceeds the context limit (1048568 tokens)，code: CONTEXT_WINDOW_EXCEEDED
472	turn/end	kind: error

预测请求 ≈ 1,076,786 vs 上限 1,048,568（超出 ≈28,218）。

证据 1：该路由按原始图片字节计费，≈1 token/字节

用同一路由下"图片到达、期间无压缩"的相邻两步做差分（8 个独立样本）：

样本	原始字节	其 base64 字符数	实测边际 token	base64 字符/token	token/原始字节
seq 189→198	510,635	680,848	466,535	1.459	0.914
seq 239→253	203,247	270,996	189,189	1.432	0.931
seq 392→403	10,932	14,576	11,707	1.245	1.071

即上游是把 base64 当普通文本分词（≈1.4 字符/token），而不是按视觉 token 计价。作为对照，同样 5 张图按 Anthropic 公开公式 w*h/750 只应收 6,860 token——该路由收了 1,001,062，146 倍。

主会话 surface 上 5 张图共 1,100,069 B ⇒ ≈ 1,001,062 token = 上限的 95.5%。像素之外留给文本/工具/系统提示的只有约 4.5%。

证据 2：dsh-token-meter 对图片的计价与之相差约 3,500 倍

estimateStructuralBlock()：

if (block.type === "image") {
  const { offloaded: _offloaded, ...reference } = block;
  return BLOCK_OVERHEAD + Math.ceil(JSON.stringify(reference).length / CHARS_PER_TOKEN);
}

主会话这 5 张图的实际计价：

seq	字节	JSON 引用长度	计量器价
195	510,635	217	59
242	94,191	208	56
243	109,056	209	57
398	10,932	201	55
463	375,255	210	57

合计 284 token，真实 ≈ 1,001,062。

priceSurface(nodes, pricing, fileText) 只在 pricing !== undefined 时重定价；而 TokenMeter._routeImagePricing(header) 取 ctx.get("llm")?.imageRequestPricing(provider, model)。全仓库只有 dsh-llm-deepseek 与 dsh-llm 接口声明了它，dsh-llm-pi-ai 没有实现（只实现 imageRequestTarget）。所以在这条路由上图片永远按上面的引用长度计价——并且这个错误价同时进入三处决策：

1. compactIfNeeded(trigger="pressure") 的阈值比较；
2. selectCompactableRange 的保留尾部与范围选择；
3. summarizeCompaction 的收缩闸门 framedSummaryTokenCount >= prepared.shadowedRouteTokenCount。

本会话记录的仪表读数：request/context.contextWindow = 262144、contextPressure.surfaceTokens = 60928、contextBreakdown 三项和 68,293。

与 #9255 / #9230 的区别：那两份报告描述的是"少算"（视觉 token 未计，约 1k–2k/张）。本条报告的是另一种量级：上游把 base64 文本计入 prompt，真实成本 ≈1 token/原始字节。在 1920×1080 截图下，250 KB 的 PNG 就是 250,000 prompt token——比"漏算 1–2k"高两个数量级。对这类路由，任何基于"视觉 token 数"的兜底估价仍然会低估约 250 倍。

证据 3：mapStopReason 丢弃已完成的回答

同一份安装的另一个会话（session-077662a9，同一路由）有两次这样的 assistant/attempt：

{"kind":"error","failure":{"message":"pi-ai detected context overflow for model \"deepseek-v4.1-flash\"","code":"CONTEXT_WINDOW_EXCEEDED"}}

但它的 replayState 明确写着上游是正常结束的，且回答内容已经生成：

"response": {
  "kind":"pi-ai","version":2,"api":"anthropic-messages",
  "provider":"blow","model":"deepseek-v4.1-flash",
  "responseModel":"deepseek-v4-1-flash-260910",
  "responseId":"021792856147480d1a31addd6d38d14c8141e1e64f1efaa8f1b1d",
  "stopReason":"stop"
}

（两个样本：seq 648 带完整 reasoning 块 + usage input=1007885, cacheRead=1007616, output=21515；seq 700 带完整 text 块 + usage input=1026422, cacheRead=1026176, output=1265。第二个样本的正文是一份完整的四组识图实测结论表。）

mapStopReason(message, contextWindow) 的静默溢出分支：

// Case 2: Silent overflow (z.ai style) - successful but usage exceeds context
if (contextWindow && message.stopReason === "stop") {
  const inputTokens = message.usage.input + message.usage.cacheRead;
  if (inputTokens > contextWindow) return true;
}

于是：上游已经收下这次请求（stopReason=stop）并生成了完整回答，harness 却因为自己声明的窗口比上游小（262,144 vs 上游实际接受的水平）把这整段回答判成溢出并丢弃，转而去压缩。这个判定还在压缩请求上复用，因此"已完成的摘要"也可能被同一个本地检查丢掉（同 #9230 的机制）。

补充一点可疑之处：这里 input + cacheRead 是 2,015,501，而上游自己的上限是 1,048,568，并且上游明确接受了这个请求。也就是说 input + cacheRead 并不是上游真正设限的那个量（在 9 份日志 / 2,769 个成功步骤里，被接受的最大 inputTokens 是 1,048,084，而 input + cacheRead 曾达到 2,094,996 并被正常接受）。用 input + cacheRead 去比窗口，会在这类路由上系统性地误判。

证据 4：唯一能移除图片的机制在这类路由上不可能触发

toPiContextWithImages 只在累计 base64 载荷超过 maxRequestImageBytes（默认 20 MiB）时抛出：

if (offloadImages > 0) throw new LlmError(`pi-ai request images exceed the ${maxRequestImageBytes}-byte base64 bound; ...`, IMAGE_OFFLOAD_REQUIRED_CODE, { offloadImages });

主会话峰值 base64 载荷约 1.47 MB，远低于 20 MiB。结果是 9 份会话日志里 image/offload 事件总数为 0。也就是说：字节预算这道闸是按"字节"设的，而真正被烧掉的是"token"——在一个按字节计 token 的路由上，19 步就能烧掉一个满额上下文，但字节数离任何闸门都差一个数量级。这道闸正是本该救回本会话的那一道。（相关：#6521 提出按数量而非字节设预算，方向一致。）

证据 5：压缩确实够不到像素

对该会话 24 条 compaction/summary / compaction/prune 记录的 shadowedSeqs 逐一核对：

• 没有任何一条记录包含过 5 张图中的任何一张。seq 195 的图片一直活到 seq 463 触发致命 400。
• 其中 8 次以"收缩闸门"失败：summary is not smaller than the shadowed content (1824 estimated framed tokens >= 1768) 等——闸门两侧用的都是上面那个瞎眼的计量器。
• 另有 10 次以 pi-ai detected context overflow for model "deepseek-v4.1-flash" 失败——按 262,144 判的。
• 9 次 compaction/prune 各只删掉一个纯文本节点（12,491 / 3,171 / 8,100 / 3,890 / 9,130 / 5,296 / 3,507 / 2,065 / 3,470 token）。按其文档，pruner 只裁文本，"images and structured blocks keep their order"。

原因是结构性的：selectCompactableRange(session, measurement, retainTokens) 从尾部往前走，把最后若干节点整段保留；而 checkpoint 消息被插到 surface 头部（validateSurfaceRegion 用 nodes.slice(startIdx, endIdx+1) 就地替换，替换后 surface 的第一个节点就是 checkpoint，后续 indexOf 因重复而落到它上面）。掌握压缩顺序的人可能是对的，但结果是：图片永远落在保留尾部的"后面"，永远进不了 shadowed 范围。这与 #9635 / #7212 描述的"压缩选中自己的 checkpoint / 永不收敛"是同一族现象，但从"图片"这个入口看，它意味着在这类路由上压缩永远无法降低真实上下文占用。

次要发现：defaultContextWindow 262,144 与上游实际 1,048,568 相差 4 倍

（与 #7213 同一问题，这里补一条"按路由声明即可修复、且无需重启"的实测。）

该路由未声明窗口 ⇒ request/context 全程 contextWindow: 262144，而 400 里的真实上限是 1,048,568。这直接决定了上面第 5 条里那 10 次失败的判定基准。

在 profile 里给该路由加 defaultContextWindow: 1048576 后，正在运行的会话在下一次请求就切换了（request/context 从 262144 变为 1048576，无需重启）：

seq 22    09:12:14  window=262144
seq 1851  23:53:46  window=1048576

需要说明：这只是把仪表修正到真实值，并没有修掉根因。 像素仍然撤不掉、压缩仍然选不中图片、计量器仍然只看到 57 token/张。它能减少"按错误窗口反复触发/误判"的无效压缩，但不能阻止那个 400。

Suggested direction

按"该在哪一层做决定就在哪一层修"的顺序：

1. llm-pi-ai 实现 imageRequestPricing；或者更通用地，让 TokenMeter 在路由未声明图片定价时，退化为按传输字节估价（例如 base64 长度 / 4），而不是按附件引用 JSON 的长度。当前的三处决策（压力阈值、范围选择、收缩闸门）都建立在"图片几乎不要钱"这个假设上，而 api 默认投影并不能覆盖"上游把 base64 当 prompt 文本"的中转形态。
2. 让图片离线预算能被"token"而不是"字节"触发：现有 maxRequestImageBytes 默认 20 MiB，在按字节计 token 的路由上等于永不触发（本安装 9 份会话、0 次 image/offload）。可考虑按"估算 provider token"设预算，或提供 maxRequestImages。
3. mapStopReason 不要丢弃已完成的回答（同 [Bug] Completed Codex responses are misclassified as context overflow above the catalog window (tested patch) #9230 的修法）：stopReason === "stop" 且 content.length > 0 时应以内容为准，把超窗 usage 作为"下一轮该压缩"的信号，而不是把回答变成 CONTEXT_WINDOW_EXCEEDED。当前行为在最坏情况下把用户拿到的唯一一份答案丢掉。
4. 重新审视静默溢出判据用 input + cacheRead 比窗口：本安装里被上游接受的最大 inputTokens 是 1,048,084，而 input + cacheRead 到过 2,094,996 仍被接受；用它比窗口会在这类路由上系统性误判。
5. resolveCompactSpec / 路由默认窗口：无声明时按 262,144 兜底，而这类自定义中转通常另有真实上限（本例 1,048,568）。窗口属于"提供方事实"，不该由适配器猜；至少应在无法确知时给出可见告警，而不是静默采用一个 4 倍偏小的值。（[Bug] llm-pi-ai silently resolves an unconfigured route to a 262144 context window while the provider declares 1048576 #7213 / [llm-pi-ai] renamed custom provider routes silently lose installed-catalog metadata (contextWindow/maxTokens) — catalog matched by provider name only #4409 已讨论。）

Honest caveats

• 1,048,568 是上游 400 报文里给出的数字，不是文档承诺；"≈1 token / 原始字节"是从 8 个样本差分测出来的，不是规范。
• 我无法证明该中转对所有 anthropic-messages 路由都这样计价；本条结论限定在"按 base64 文本计价的中转"这一类，这也是它值得单列的原因——api: anthropic-messages 这个声明本身给出不了任何关于计价的保证。
• 第 5 条给出的默认窗口实测（1048576）是本安装的配置层规避，不是本报告主张的修复。

[xiaonerner0821]

补充复现：膨胀只发生在 tool_result 里的图片，换协议或换模型都正常

环境：DSH Desktop（dsh-compaction-basic 0.2.1-rc.2），Windows x64；llm-pi-ai 自声明路由，api: anthropic-messages，第三方中转网关，模型 openai/gpt-6.1-sol-cpr（网关会转换协议），contextWindow 取默认值 262144。

直接请求网关，同一张 1440×960 PNG（106,973 B）

条件	网关计费的 input tokens
GPT · anthropic-messages · 图片放在 tool_result 里	93,775（≈0.88 token/原始字节，和本帖的约 1 token/字节吻合）
GPT · openai-responses · 图片放在 function_call_output 里	6,005
GPT · anthropic-messages · 图片放在 user 消息里（另一张 2 MB 的 1024² 图）	1,242
Claude · anthropic-messages · 图片放在 tool_result 里	正常（个位数）

所以这次的触发条件比「中转站按 base64 计价」更窄：只有网关把 Anthropic 格式转成 OpenAI 格式、并且图片在 tool_result 里时才会膨胀。read_image 恰好把图片放在 tool_result 里。

会话日志里的后果

• 第 14 轮 read_image 读入 2 MB 的图后，请求输入从 183k 跳到 407k（上限 262k）。之后 token-meter 估算的 surface 一直在 47k，而网关每次计费约 292k。
• 自动和手动压缩共失败 40 次：31 次是 summary is not smaller than the shadowed content，因为压缩区段只选中上一次的摘要，和 [Bug] Compaction selects its own previous checkpoint as the whole span, so a long session never converges (59/79 attempts rejected, 44.6 min burned) #7212 类似；9 次是 pi-ai detected context overflow，因为摘要请求原样带着这张图，和 [compaction bug] Session becomes permanently unusable on context overflow: token underestimation, summarizer replay overflow, and no manual recovery path #9635 一样。
• image/offload 事件 0 条：dsh-compaction-image-offload 只响应 IMAGE_OFFLOAD_REQUIRED，按 token 计算的溢出（CONTEXT_WINDOW_EXCEEDED）不会触发它卸载最旧的图片。如果溢出时能先卸载旧图片再重试摘要，这类会话本来可以自救。

恢复方法（结合 #9888）

把 GPT 改到 openai-responses 路由，或者切到 Claude，先发一条普通消息更新 request/header，再执行 /compact。