[Bug] opencode-go/deepseek-v4.1-flash: prompt_tokens + max_tokens > 2^20 时上游 400，错误体被截成 31 字节（UI 显示 "400 status code (no body)"），可用上下文只剩 63%

[lnyuqian]

TL;DR (English) — With provider opencode-go / model deepseek-v4.1-flash (catalog: contextWindow: 1000000, maxTokens: 384000), every request carries max_tokens: 384000. The endpoint rejects the request with HTTP 400 once prompt_tokens + max_tokens > 2^20 (1,048,576). The 400 body is a 31-byte JSON fragment ({"model":"deepseek-v4.1-flash"}) without an error field, so the OpenAI SDK surfaces it as 400 status code (no body) and the desktop UI shows「本轮运行失败 400 status code (no body)」. Effective usable input is therefore 1,048,576 − 384,000 = 664,576 tokens (63.4% of the advertised 1M), and the auto-compaction threshold (thresholdRatio × contextWindow) ignores that output reserve, so long sessions deterministically hit the wall.

---

环境

• DSH desktop 0.2.0-rc.2（Windows），desktop profile，直连（无本地代理）
• provider opencode-go，baseURL: https://opencode.ai/inference/go/openai/v1
• model deepseek-v4.1-flash：contextWindow: 1000000, maxTokens: 384000
• 单 agent 会话（工具 78 个、系统提示 ~15 KB）；会话内无图片

观测数据（同一会话，数字来自 API 返回的真实 usage）

turn/step	prompt_tokens	+ 384,000	是否 > 2^20	结果
25-1	626,644	1,010,644	否（< 1,048,576）	✅ 200
29-7	662,208	1,046,208	否	✅ 200
29-8	≈673,267	1,057,267	是	❌ 400
30-1	≈673,267	1,057,267	是	❌ 400

边界落在 662,208 ~ 673,267 之间，命中 2^20 − 384,000 = 664,576。

注意 turn 25 那行：626,644 + 384,000 = 1,010,644 > 1,000,000 仍然成功 —— 说明窗口是 2^20 (1,048,576)，而不是 1,000,000。

失败后该会话每条请求都必败（usage: 0、0 token、INVALID_REQUEST，无 llm/retry），只能手动 /compact 才能恢复（/compact 之后同一会话又正常工作了 1 小时、turn 30→37）。

复现

A. 最小复现——同一份 ~2.93 MiB 的 messages payload，只改 max_tokens：

max_tokens	HTTP	响应体
384000	400	31 字节：{"model":"deepseek-v4.1-flash"}
8	200	正常流式 chunks

同一份 payload 再加 15 万个汉字（≈+150k token）后，max_tokens=8 仍 200、max_tokens=384000 仍 400 —— 即判定与「输出预留」强相关。

B. 自然复现：让会话 prompt 自然增长到 66 万 token 以上，下一次任意请求即 400（错误 UI 见上）。

根因分析

1. LLM 请求的 max_tokens 直接取模型目录的 maxTokens（384000）；而 DSH 自己的压缩实现默认只预留 headroomTokens = 65536。两者不一致 → 每次请求白扔 36.6% 的窗口。
2. 压缩阈值按 thresholdRatio × contextWindow 计算，没有减去 max_tokens，因此不会在这个预留造成的墙之前触发（该长会话 30 轮内一次自动压缩都没发生）。
3. 越界时上游返回的 400 body 被截断成 31 字节且不含 error 字段 → SDK 只能报 400 status code (no body)。用户侧完全看不出是「上下文+输出预留超限」，只能猜测网络/代理/密钥问题，排查成本极高。

建议

1. 发送 max_tokens = min(catalog maxTokens, headroomTokens / 可配置值)（或按 window − prompt 动态收敛），让 1M 窗口真正可用 ~94%。
2. 压缩判定使用有效窗口 contextWindow − max_tokens（或显式扣除预留）。
3. 网关 400 的响应体请保留 error 字段；现在这种 31 字节碎片会把所有 400 都伪装成「no body」。
4. agent-default-model entry 的 config 不接受 maxTokens（实测手动写入后，应用启动时该键被剥离，且那次启动核心服务不可用：sessionController is unavailable，会话列表空白）。建议要么支持该键，要么在文档里指明正确位置是：
   • llm-pi-ai.providers.<provider>.modelOverrides[model].maxTokens（schema 已支持）
   • 或 agent-loop.agents[].maxTokens

（附：排查中确认 llm-pi-ai 的 modelOverrides/models[] 都声明了 maxTokens，所以用户侧是有覆盖点的，只是位置不直观、且与压缩的 headroomTokens 语义不一致。）

[lnyuqian]

补充两点独立印证 + 一个观察。

1. 上游硬数字印证（第三方实测，与本文互证）

同一 DeepSeek 网关返回的原文数字：

• 上下文硬上限：1,048,570（报错原文：Input length 1280009 exceeds the maximum length 1048570）
• 最大输出：393,216（即 384K，与 catalog 的 maxTokens: 384000 一致）

⇒ 可用输入 = 1,048,570 − 384,000 = 664,570。而本文实测边界落在 662,208（成功）~673,267（失败）之间，命中 2^20 − 384,000 = 664,576。两个独立来源吻合到个位数量级：窗口是 2^20 量级（1,048,570），不是 10^6；且被 384K 输出预留吃掉约 37%。

（来源：API易 2026-08-05 对 DeepSeek V4 系列的网关实测，含 Input length ... exceeds the maximum length 1048570 原文与 393,216 输出上限。）

2. 关于「自动压缩为什么没救回来」

dsh-compaction-basic 的 schema 暴露了这些键（含默认值）：

键	默认	说明（取自插件文档串）
auto	true	Enable automatic condensation and overflow recovery
maxOverflowRetries	1	Maximum retries after a confirmed context-window overflow
compactionRetries	1	首次压缩后仍高于阈值时的额外压缩次数
thresholdRatio / retainRatio / headroomTokens / maxTokens	—	阈值、保留比例、预留、摘要输出上限
modelPolicies	[]	按 {provider, model, ...} 覆盖单条模型路由

本机 desktop profile 已配 compaction-basic.modelPolicies[opencode-go / deepseek-v4.1-flash] = { thresholdRatio: 0.35, retainRatio: 0.05 }，但在 30 个 turn、prompt 从 35,957 涨到 662,208 的全过程中，会话文件里没有任何 compaction/start 事件；唯一的 compaction/summary 出现在用户手动 /compact 时。也就是说自动压缩没有在 0.35 × 1,000,000 = 350,000 处触发。同时 maxOverflowRetries 的溢出恢复也没有体现。

推测（供维护者参考）：本次越界的 400 响应体被截断成 31 字节且没有 error 字段，DSH 无法把它识别为 “confirmed context-window overflow”，因此既不触发溢出恢复、也不触发压缩；会话此后每条请求必然重复 400，只能靠用户手动 /compact 恢复。若属实，这与本文第 3 条建议（错误体需保留 error 语义）是连带的——错误体丢失不仅让用户看不懂，还会让自动恢复逻辑失效。

3. 补充：本机可用的覆盖点（供其他用户规避）

• llm-pi-ai.providers.<provider>.modelOverrides["<model>"].maxTokens（schema 已支持；覆盖发送的 max_tokens，例如压到 65536 → 可用输入回到 ~983k）
• agent-loop.agents[].maxTokens
• agent-default-model entry 的 config 不接受 maxTokens（实测手动写入后键被剥离，且那一次启动核心服务不可用、会话列表空白），文档里最好显式说明这一点。

[argszero]

Your arithmetic holds, but the mechanism inside the harness is not root cause #2, and the difference decides what fixes it. Everything below is source from d743267388 (0.2.1-alpha.2).

The threshold does subtract an output reserve — just not the number your request sends

packages/compaction/compaction-basic/src/config.ts:172-193:

const messageBudgetTokens = contextWindow - reservedCompletionTokens
const pressureBudgetTokens = messageBudgetTokens - policy.headroomTokens
const thresholdTokens = Math.floor(Math.min(
  contextWindow * policy.thresholdRatio,   // DEFAULT_THRESHOLD_RATIO = 0.8 (:20)
  pressureBudgetTokens,
))

and the reserve is (src/index.ts:65-68, used at :317):

function reservedCompletionTokens(agent: Agent, defaultMaxTokens: number | undefined): number {
  const configured = agent.session.requestHeader()?.config.maxTokens
  return configured ?? defaultMaxTokens ?? 0          // ← note the last fallback
}

defaultMaxTokens is set only for a cap the deployment explicitly configured — adapter.ts:315-325, with the catalog's own comment at catalog.ts:838-846:

pi-ai requires maxTokens as the model's output capability, while the harness seam's defaultMaxTokens is a cap the deployment chose to send on requests that name none. Materializing a catalog capability as a request default would start capping every request at a number nobody picked, so only an explicit configuration lands here.

The wire takes the other number. The adapter forwards a cap only when the call carries one (adapter.ts:405, ...options.maxTokens === undefined ? {} : { maxTokens: options.maxTokens }); otherwise pi-ai sizes the request from Model.maxTokens — your 384000, which came from the catalog entry rather than from an explicit profile cap.

So the two numbers have different owners, and with your route (contextWindow: 1,000,000, maxTokens: 384,000, headroom 65,536):

reserve the compactor subtracts	thresholdTokens	your prompt at 673,267
384,000 (explicitly configured cap)	550,464	compaction fires
0 (nothing explicit)	800,000	below pressure — no compaction, which is what you observed

That gap is the wall

The gate is a fraction of the declared window, while the provider refuses everything above 2^20 − 384000 = 664,576. 0.8 × 1,000,000 = 800,000 therefore sits 135,424 tokens past the point of death: a session can be required to compact at a size it can no longer request, and it only learns this from a 400. Your own step 25 (626,644 + 384,000 = 1,010,644 > 1,000,000, still 200) shows the declared window is below the provider's real cap — the one direction in which reserve subtraction cannot help, because the declared fraction (800,000) is larger than the true safe input (664,576).

Two consequences worth separating:

• The request-time check is one-sided. config.ts:172-178 throws only when contextWindow - reservedCompletionTokens <= 0. A configuration that leaves a non-zero but unusable message budget (1,000,000 − 384,000, against a provider that counts prompt and reserve against the same cap) passes silently.
• Nothing recovers. The built-in overflow path is gated on the code alone (compaction-basic/src/index.ts:194: failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE || signal.aborted), and your failure arrives as INVALID_REQUEST from a 31-byte body with no error field — so no compaction, which is exactly your "only a manual /compact recovers".

The meter is not the gap, for what it's worth: token-meter prices the tool schemas too (estimateToolsTokens(header) + surfaceTokens, token-meter/src/index.ts:171-187), so measurement.totalTokens is a fair proxy for prompt_tokens even with your 78 tools.

What we can contribute

We publish @argszero/cordis-plugin-length-stop-overflow, which exists for this classification gap — the built-in recovery runs on CONTEXT_WINDOW_EXCEEDED, so a failure that is an overflow but arrives under another code recovers from nothing. Its three triggers today: 413/size wording on a request rejection, provider-counted saturation (≥ 0.99 × window), and finish_reason: length read as a normal finish. Your report is outside all three — no wording to read, and the prompt sits at 67% of the declared window — and the predicate it needs is the table above: prompt_tokens + cap actually reserved on the wire > declared contextWindow, evaluated on a failure frame. Stated the way your report states it, the reserve is what belongs in the comparison, and the harness currently lets the two reserves disagree. We're adding that as a fourth input; the published 0.3.0 does not cover your report.

[clearnature]

这个是共享上下文1m ,包含了工具，提示词等。技能加载多了会消耗上下文，可以使用极简模式测试数据。

[argszero]

@argszero/cordis-plugin-length-stop-overflow@0.4.0 is published with this report's shape as its fourth trigger — and it comes with a correction to the arithmetic we stated earlier in this thread.

Narrowing what we wrote earlier

We first stated the predicate as prompt_tokens + cap actually reserved on the wire > declared contextWindow. That is the provider's rule, and it is what your report measures — but it is not evaluable at the plugin face, and 0.4.0 does not pretend to evaluate it. The cap a request carries is decided below the llm/stream seam:

• llm-pi-ai forwards a cap only when the call names one (adapter.ts:405), and a loop-built call names one only when the session's effective envelope does (llm/src/call-config.ts:23); otherwise pi-ai sizes the request from the catalog's own maxTokens;
• LlmResolvedModelInfo (llm/src/types.ts:410) reports context.contextWindow and an adapter's defaultMaxTokens, and no catalog output capability — maxTokens appears in that type only on a discovered model (types.ts:316), which is a settings-time draft rather than the request path;
• the number actually sent is produced after that, inside pi-ai's clampMaxTokensToContext on the clamped request path, from a local estimate. It is not reported back to the harness at all.

So "the reserve actually carried on the wire" is not readable from either side of the seam — which is exactly why the compaction threshold (a fraction of the declared window) and the wire cap are free to disagree. That disagreement is the other half of your report, and it is a core question: 0.4.0 does not address it. What 0.4.0 changes is what the failure means, so the tree can recover from it.

What 0.4.0 does instead

Two numbers the plugin does own: the harness' own meter, and the declared window. tokenMeter.measure(session).totalTokens is the same measurement compaction-basic/src/index.ts:278 compares against its own threshold, so the two verdicts are stated in one currency:

error finish, nothing attributed, harness meter >= fullRequestRatio x window   (default 0.5)
    ->  { kind: 'error', failure: { code: 'CONTEXT_WINDOW_EXCEEDED', … } }

On a turn like yours (declared window 1,000,000, the session's own meter at 673,267) the terminal failure becomes:

opencode-go/deepseek-v4.1-flash refused the request as INVALID_REQUEST while this session's own
meter priced it at 673267 token(s) against the 1000000-token window that route advertises (0.67x,
at or above the 500000-token line this rule acts on): 400 status code (no body). Reclassified as
CONTEXT_WINDOW_EXCEEDED by length-stop-overflow (discussion #9434): the refusal named no cause and
carried no usable count, and on a request this full the only built-in recovery that can shrink what
is sent is context-overflow compaction.

dsh-compaction-basic then compacts and returns { kind: 'retry' }, bounded by its own maxOverflowRetries — so the turn is recovered instead of repeating the same 400.

Three properties worth stating, because they are what makes it safe to leave on by default:

• Fail-closed three times over: no sessions/tokenMeter service, no session for the id the request carried (or no session id at all), or a measurement that is not a finite non-negative number — and the failure keeps the code the adapter chose. A profile without a meter still gets the other three triggers.
• The provider's count wins when it exists. Trigger 3 (≥ 0.99 × window on the provider's own count) is evaluated first; this rule only sees what it declined, and the two share one window lookup.
• A healthy turn pays nothing — no measurement, no window lookup. The gate is a failure whose code attributes nothing.

fullRequestRatio (default 0.5) is a policy, not an identity, deliberately below the compaction policy's own threshold (thresholdRatio, default 0.8), because the whole defect is that the provider's real input capacity can be smaller than the window the harness believes in. Raise it if your routes are honest and you would rather act only on near-certain cases; classifyFullRequestRefusals: false keeps 0.3.0's behaviour.

npm i @argszero/cordis-plugin-length-stop-overflow     # 0.4.0

The README section The line is a substitute — the earlier arithmetic is not observable here carries the same narrowing with the source lines. 136 tests; the rule is pinned in both directions — it fires at the line and declines below it, an attributed code at the same price and a max-tokens finish at the same price cost neither a measurement nor a window lookup, and a size refusal that would also qualify is never relabelled by a rule that runs later.