【BUG/性能】压缩摘要调用不携带 reasoningEffort ⇒ 与同会话主请求的缓存键不同 ⇒ 每次压缩白烧 ≈25 万 token

[echopharmsu]

1. 报告摘要

在 DSH + OpenCode Go 订阅（本机：DSH kernel 0.1.7-rc.2，路由 opencode-go， 模型 deepseek-v4.1-flash）下，每次压缩（compaction）会额外产生约 25 万未缓存 token， 而其中绝大部分是可避免的。

根因不在上游，在 DSH 侧的一处调用参数缺失：

@deepseek-ai/dsh-compaction-basic/lib/index.js:312–323 构造压缩摘要请求时， options 里没有 reasoningEffort。

后果：该请求的 reasoning_effort 与同一会话内所有主请求的取值不同。 实测表现：把该值改为与会话一致之后，同一次压缩的缓存命中由 1.2%–8.0% 变为 99.9% （未缓存输入 227,606–280,919 → 474），其它条件（会话、模型、上游端点、请求体前 1 MiB 的字节）全部不变。

⚠️ 本报告只报告实测现象，不主张上游缓存键的成因。 「该字段参与前缀缓存键」是本次 A/B 的表现，其真实性与设计意图应由上游确认 （同一发现已同步至 OpenCode 侧，询问该行为是否已文档化）。 若上游确认「与 effort 无关」，则本报告的机制解释需要重做——但 A/B 现象本身仍成立， 修复方向（让辅助调用携带会话 effort）也不会因此变坏。

因此，摘要请求此前只能命中「系统提示 + 工具定义」这段公共头，其后全部未缓存。

实测 A/B（同一会话、同一模型、同一上游端点、前缀逐字节相同）：

	摘要请求的 reasoning_effort	缓存命中
修复前（4 次压缩）	none（缺省的落点）	1.2% / 8.0% / 8.7% / 4.8%
修复后（1 次压缩）	max（与会话一致）	99.9%（390,528 / 391,002）

8. 验证清单（可执行）

1. 开一个会触发压缩的长会话（或用 /compact）；
2. 在请求侧记录每条请求发出的 reasoning_effort（代理、插件或 debug 日志均可）；
3. 比对：压缩摘要请求 与 同会话主请求 的该字段是否一致；
4. 比对：摘要请求的 cache_read 是否仍只等于「系统提示 + 工具定义」的量级 （本机实测该量级约 24,576）；
5. 若一致后命中率显著上升 ⇒ 本报告成立。

复现门槛很低：只要能看到自己发出的请求体与响应里的用量，就能验证，不需要服务端访问。

9. 相关文件索引

• 本机实测数据与逐请求表：可按需提供（时间 / inputTokens / cacheReadTokens / reasoningEffort / endpoint）
• 本机修复实现：ocgo-sync/plugin/lib/index.js（patchReasoningEffort + 中间件分支）
• 上游侧并行反馈：OpenCode 仓库对应 issue 与邮件（同一发现的另一半视角）

[argszero]

Confirmed on the source you cite (I read d743267388): packages/compaction/compaction-basic/src/summarizer.ts builds the summarization request without the field — the string reasoningEffort does not occur anywhere in that file. The request object is:

const options: GenerateOptions = {
  provider: target.provider,
  model: target.model,
  messages,
  toolHistory: agent.session.toolHistory(),
  ...input.tools === undefined ? {} : { tools: [...input.tools] },
  maxTokens: config.maxTokens,
  sessionId: agent.session.id,
  purpose: 'compaction',
  ...signal === undefined ? {} : { signal },
}

Two things that make the fix smaller than it looks, and that your report does not state:

1. The session's own request header is already in scope a few lines above the omission. summarizer.ts:127 reads const latest = agent.session.requestHeader()?.config and uses it as one of the candidate targets (:131-135 also reads agent.options.provider/model). request/header.config is a LlmCallConfig, and LlmCallConfig extends LlmCallControls, whose first field is reasoningEffort (packages/llm/llm/src/call-config.ts:16-24); the loop logs exactly that snapshot into the session whenever it builds a request (packages/core/agent-loop/src/agent.ts:637-650). So "carry the session's effort" is taking one more field from a value this function already reads.

2. Route defaults cannot explain the gap. resolveCallWithInfo (packages/llm/llm/src/index.ts:885-911) applies reasoning.defaultEffort on every dispatch path, including the raw ctx.llm.stream() call the summarizer makes (adapterStream, :1038-1040). So if the main requests carry max while the summarization request carries nothing, the max is coming from the deployment's own request controls, not from the route default — and that is the value that has to be carried over. It is checkable from your own side: the request/header session event records the config the loop actually built.

On your caveat that you do not claim the cache mechanism — that is the right discipline, and there is upstream text that speaks to it without settling it. The module header of call-config.ts says request-header state is "Provider routing, model, reasoning effort, and sampling values … that can affect cache reuse", and carries // TODO(call-config-shape): Revisit which fields are epoch-level for cache reuse (:4, :23). So the design already treats this field set as defining the reusable prefix; whether a given provider keys reasoning_effort into that prefix is still theirs to confirm, but your finding lands inside the set the design names.

If it helps: a published plugin already sits on this seam, so the mitigation does not require a core patch — @argszero/cordis-plugin-aux-reasoning@0.1.0 (npm; source discussion #7109) rewrites the reasoning level of purpose-marked calls through the public llm/stream waterfall. Two honest caveats: its default target is off (it exists to stop unasked-for thinking, which is not your goal — you would point it at the session's level), and it only fills the field when it is absent, which is precisely your case. The structural enabler for the version you want is that GenerateOptions carries both sessionId (packages/llm/llm/src/types.ts:546) and purpose (:552), so a listener can remember the last non-auxiliary call's effort per session and stamp it onto the auxiliary call — that is the shape your A/B motivates.