[Bug] Runaway tool-call arguments consume the full output budget before validation

[luisnomad]

Summary

A local OpenAI-compatible model produced a runaway job_output tool argument after a continuable subagent started. The Harness allowed the malformed argument to stream until the model exhausted its entire output allowance, then surfaced only the generic Output token limit reached message.

This is ultimately a model-generation error, but the Harness can contain it much earlier and report the actual failure.

Environment

• @deepseek-ai/dsh: 0.1.1-rc.2
• Web profile with the standard continuable subagent and generic job tools
• OpenAI-compatible llama.cpp endpoint
• Gemma 4 26B-A4B IT MXFP4 MoE, reasoning disabled
• 131,072-token context; 4,096-token output limit
• Failure occurred at approximately 43K cached conversation tokens

The model and endpoint remained healthy throughout the incident.

Observed sequence

1. The parent called subagent successfully.
2. The tool returned started subagent a72944e6-6129-468c-8ab6-6a717af96a11.
3. On the next step, the model began a job_output call. (That is already the wrong control for a continuable subagent id; its settlement notice should be used instead.)
4. The streamed JSON began with the correct id, then repeated its suffix thousands of times:

{"job_id":"a72944e6-6129-468c-8ab6-6a717af96a717af96a717af96a..."}

5. The session recorded 4,096 output tokens, stopReason: "length", and a max-tokens turn end. The assembled assistant message contained no usable content.

The durable stream made the cause visible: a tool-call-delta sequence for job_output accumulated the runaway argument until block-end. The Web UI only showed Output token limit reached, which made this initially look like an ordinary response-length problem.

Expected behavior

The Harness should stop consuming a response once a tool-call argument exceeds a defensible configured bound or becomes impossible for the target tool, preserve a diagnostic attempt, and report a specific malformed/oversized-tool-call failure. It must not execute the malformed call.

Increasing maxTokens is not a fix; it only makes this failure slower and more expensive.

Suggested ownership and behavior

A stream guard on the existing llm/stream extension point seems preferable to changing the agent loop. Possible design:

• Add a configurable maximum raw argument byte count per tool call, with a conservative deployment default or tool-definition override.
• Count UTF-8 bytes across tool-call-delta chunks independently for each call index.
• When the bound is crossed, close the upstream iterator promptly and emit/preserve a provider-neutral failure such as TOOL_CALL_ARGUMENTS_TOO_LARGE.
• Include the tool name, call id, observed byte count, and configured limit in diagnostics without retaining the complete malformed payload.
• Make the resulting UI text distinguish this from an ordinary visible-answer output limit.
• Do not retry by default unless retry policy explicitly opts into the new failure code.
• Add a recorded-stream regression where a tool argument repeats until the bound, proving that inference is stopped before the model output limit and that the tool is never executed.

For the specific subagent confusion, the model-facing result or guidance could additionally state that started subagent <id> is a continuable child id and must not be passed to job_output; job_output is only for started background ... job <id> acknowledgements. That clarification is useful, but it does not replace the generic streaming guard.

Local mitigation

I switched council delegation to one-shot/foreground-returning subagents. Independent calls issued in one assistant response still run concurrently, while their results return directly and require no id polling. This avoids the trigger for this local model, but I am not proposing that continuable subagents be disabled upstream.

I can provide the redacted session-event excerpt or test a proposed guard against the same local model if useful.

[argszero]

@luisnomad 这个把「流式 runaway 参数」的链路断得非常清楚——而且你点的 llm/stream 扩展点确实可插件挂载，说明这不该等 core，插件能先兜。我在当前基线核对后补充几个源级事实，帮你把 guard 落到位：

一、llm/stream 接缝确实开放

packages/llm/llm/src/index.ts:72 定义了 llm/stream 这个 Cordis waterfall：

'llm/stream'(this: LlmRuntime, options: GenerateOptions, next: () => AsyncIterable<StreamChunk>): AsyncIterable<StreamChunk>

也就是说插件可以 ctx.on('llm/stream', (options, next) => 包一层迭代器)——与 in-tree invariant.ts:88（validateStream 的 global+prepend 校验）同一种写法。StreamChunk 的类型（llm/llm/src/types.ts:388-394）也明确包含你要监听的：

| { type: 'tool-call-delta'; index; id; name?; argumentsDelta: string }

argumentsDelta 就是你要按 call index 累计字节数的字段。

二、三点细化（对应你的设计）

1. 字节累计按 call index 分桶：tool-call-delta 带 index 但多个 tool-call 可并存，必须按 index（或 id）独立累计 argumentsDelta 的 UTF-8 字节，不能全局一个计数。你的「Count UTF-8 bytes across tool-call-delta chunks independently for each call index」正确。
2. 关闭上游迭代器：llm/stream wrapper 返回的 AsyncIterable 需要在你检测到超界时提前 return（对上游 next.return()），并 emit 一个 provider-neutral 的失败。注意失败如何交给下游——你在 llm/stream 层无法直接改 result，但可以在超界那个 chunk 之后停止迭代，让 assembler 用已有的「未闭合 tool-call」路径处理；若要让模型看到 TOOL_CALL_ARGUMENTS_TOO_LARGE 结构化失败，需要在 tools/execute 层（或 tool-call-delta 的 block-end 补偿）配合。这两个接缝（llm/stream 挡、tools/execute 转错误）我知道分别怎么用——我此前在 tools/execute（@argszero/cordis-plugin-steer-preempt / read-image-guidance）和 llm/stream（@argszero/cordis-plugin-thinking-loop-guard）都已实现过同款接缝。
3. job_output 误用 subagent id：你最后那条「started subagent <id> 是 continuable 子 agent id、不该传给 job_output」是对的——但这是模型引导问题（seam 在 tool-subagent 的 settlement 语义/tool 描述），与 stream guard 正交。可作附带说明。

三、插件可挂载面判别

这不是纯 core——llm/stream guard 可以做成一个独立插件（跟你 thinking-loop-guard 同族），在 llm/stream 包一层按 index 累计字节 + 超界提前 stop。真正需要 core 配合的只有「把失败转成结构化 TOOL_CALL_ARGUMENTS_TOO_LARGE 且不执行该调用」这段（agent loop 的 tool-call 门槛）。插件能做前半（流式挡 + 停止），core 做后半（不执行 + 结构化报错）——如果你有意向，我可以下一轮把「流式超界 guard」的插件版做出来（偏 thinking-loop-guard 模板，落在 llm/stream），并在本帖闭环。

判别：你的根因分析完整且接缝落点正确；llm/stream guard 可插件化（流式挡），core 需配合跨 step 的错误转义；maxTokens 不是解法（同意）。

[argszero]

@luisnomad 闭环一下——这个缺口已经有一个插件形态的实现兜底了，你提的「插件应该先兜」我直接就做了。已在 npm 发布 @argszero/cordis-plugin-llm-tool-call-guard@0.1.0，仓库在 https://github.com/argszero/cordis-plugin-llm-tool-call-guard：

它做什么：包一层 llm/stream（就是我上条回复里确认的那个 waterfall 接缝），按每个 tool-call block index 独立累计 argumentsDelta 字节数。当某一个 call 的参数超过可配置上限（maxArgsBytes，默认 24 KiB）时，它：

1. 停止消费上游生成器（释放 provider 连接和仍在增长的参数流），并
2. 发一个合成的终端 error finish，携带稳定路由码 TOOL_CALL_ARGUMENTS_TOO_LARGE。

为什么它能真正防止执行（不只是记日志）：我把 packages/core/agent-loop/src/agent.ts:442-464 读了一遍——agent loop 是先按 finish reason 分支再 filter assistant content 里的 tool-call 块。当 finish.kind === 'error' || 'aborted' 时，它 settle 这次 attempt、dispatch agent/request-error（重试/抛错），根本走不到 :486 的 .filter(block => block.type === 'tool-call')。所以发 error finish 是能阻断那个 runaway / 超长 call 被执行的，不是纸面的。另外 llm-invariant（packages/llm/llm/src/invariant.ts:75）显式允许 error/aborted finish 带 open block index，所以这个 finish 协议合法。

边界诚实说明：「不要执行这个超大调用」是由 core 的 error-finish 路径提供的，本插件负责检测 + 切断。如果以后 harness 需要把这转换成一条结构化 assistant 消息（而不是抛/重试 LlmError），那是 core 改动，超出插件范围。另外 maxTokens 不是替代品——一个很小的 maxTokens 仍然可能被一个 runaway call 整段吃掉，而且没有任何 per-call 信号。

用法：npm install @argszero/cordis-plugin-llm-tool-call-guard，然后在 dsh profile 里 mount：

- insert:
    - id: llm-tool-call-guard
      name: '@argszero/cordis-plugin-llm-tool-call-guard'

默认 maxArgsBytes: 24576、fail: true（越界 → 发 error finish 不执行）。想调成 fail: false（只 cut 源、发正常 stop finish，把部分 call 当普通 call）和 maxArgsBytes: 0（纯透传/禁用）都支持。

12/12 测试通过（含「per-block-index 独立计数」「越界切断 + error finish」「observe-only 发 stop finish」「文本/reasoning delta 不计入预算」）。如果作者觉得默认预算或行为需要调整，直接在仓库开 issue 或 @我。

[luisnomad]

Thank you—this confirms the seam and ownership split very clearly. Yes, I would be happy to test the plugin against the same local model and failure mode. I can also provide a redacted recorded-stream excerpt containing the runaway tool-call-delta sequence for a deterministic regression fixture.

The plugin-first split makes sense to me: stop and close the upstream stream at llm/stream, then pursue the structured TOOL_CALL_ARGUMENTS_TOO_LARGE error and execution veto as a smaller core follow-up. Please let me know which fixture format is most useful.

[argszero]

@luisnomad 太好了——作者愿意实测 + 提供录制流是最理想的一步。关于 fixture 格式，给出一个最省事的选项：

插件测试消费的 chunk 协议

@argszero/cordis-plugin-llm-tool-call-guard 的 guardStream(iter, opts) 包的是一个 AsyncIterable，测试直接喂 chunk 数组。判定只依赖两类字段：

1. tool-call-delta（只数这个的 argumentsDelta）：

   { type: 'tool-call-delta', index: 1, id: 'call-1', argumentsDelta: '{"a":"' }

   • index = tool-call block index（不是 id —— 两个不同 tool-call 可能被上游复用同一个 id，但 index 是独立的，所以插件按 index 分桶累计）
   • argumentsDelta = 该块这一次 delta 的字符串，按字节数累计
2. text-delta（不计入预算）：{ type: 'text-delta', index: 0, text: 'hello' }
3. finish：{ type: 'finish', reason: { kind: 'stop' } } 或 { type: 'finish', reason: { kind: 'error', failure: {...} } }

你那份录制流怎么给最有价值

最理想是只给触发越界的那个序段，去掉 carrier/连接层：

• 最小可复现：一个 tool-call 在 maxArgsBytes（默认 24576）以内正常累计，随后某个 delta 把单块总共推过 24576 —— 这会验证「越界即 cut + 发 error finish」。
• 如果录制里有「一个 id 被复用于两个不同 call」（index 不同但 id 相同），请务必保留 —— 这正是按 index 分桶的价值，能防住按 id 分桶会误判（把一个 call 的预算算到另一个头上）的错误。
• 如果流里还夹着 reasoning-delta，一并保留没问题 —— 插件只数 tool-call-delta 的 argumentsDelta，其它 delta 类型全部忽略。

交付形态建议

可以给两种，任选其一即可：

1. 一段 JSON（chunk 数组），形如下面 —— 我直接可做回归 fixture 粘进测试：

   const runaway = [
     { type: 'text-delta', index: 0, text: 'Let me call that.' },
     { type: 'tool-call-delta', index: 1, id: 'call-x', argumentsDelta: '{"a":"' },
     { type: 'tool-call-delta', index: 1, id: 'call-x', argumentsDelta: 'x'.repeat(25000) }, // 越界
   ]

2. 或一段录制流文件的原始（脱敏后的）串，注明哪些行是 tool-call-delta、各自的 index/id/argumentsDelta，我来转成上面这个形状。

拿到之后我会把它做成一个固定的回归用例，加进 test/llm-tool-call-guard.test.js（会连同 fail / observe-only 两种模式各跑一遍），并在 npm 上发一个 0.1.1 把回归用例带上。要是你的录制流能顺便确认「error finish 之后 agent loop 确实没执行那个 call」那最好——那就是把「插件兜底 + core 执行否决」两半都验到了。

[argszero]

@luisnomad @everyone 小更新——@argszero/cordis-plugin-llm-tool-call-guard 已发 v0.1.1，在你提供的录制流 fixture 之前先补了一个独立缺口。

新增：maxTotalArgsBytes（整请求聚合预算）

v0.1.0 只按每个 call index 单独卡 maxArgsBytes。但模型可以每个 call 都判为「超界一下没超」、然后连发很多个，直到它们累计把整个输出预算吃光——这跟单个 runaway call 是两种失败形状（「一个 call 太大」vs「call 太多」）。

v0.1.1 加了一个可选 maxTotalArgsBytes（默认 0 = 关），按整个流里所有 tool-call 块的 argumentsDelta 之和计数。超过时它同样 cut 源 + 发一个不同的终端 error finish，码是 TOOL_CALL_ARGUMENTS_TOTAL_TOO_LARGE（区别于单块的 TOOL_CALL_ARGUMENTS_TOO_LARGE），让消费方能区分「该抬单块上限」还是「该让模型少发几个 call」。

- set:
    - id: llm-tool-call-guard
      config:
        maxArgsBytes: 8192      # 单块上限
        maxTotalArgsBytes: 32768  # 整请求聚合上限；0 关闭
        fail: true

关于你那份录制流 fixture

还在等你的最小可复现段（:18372208 我问的是「单个 call 在限内、某个 delta 把单块推过 24576」或「一个 id 复用于两个不同 index 的 call」两种）。拿到后我会把它做成固定回归用例，加进 test/llm-tool-call-guard.test.js（fail / observe-only 两种模式各跑一遍），并作为 v0.1.2 发出。

当前 20/20 测试通过（v0.1.1 新增 5 个聚合预算用例）。仓库 https://github.com/argszero/cordis-plugin-llm-tool-call-guard。

[luisnomad]

I pulled the real failing stream from the parent session log and redacted the payload. It has a slightly different (and useful) shape from the expected >24 KiB case:

• one tool call, index: 0, one stable id, name job_output
• 4,074 tool-call-delta fragments over about 115 seconds
• only 4,658 ASCII bytes total
• fragment-size histogram: 3,492 x 1 byte, 581 x 2 bytes, 1 x 4 bytes
• it begins like {"job_id":"<redacted UUID>..., then continues emitting hex characters and never closes the JSON string/object
• upstream eventually emits { type: 'finish', reason: { kind: 'max-tokens' } }

So the current 24 KiB default does not catch our actual failure. This is a fragment-count runaway, rather than a large-argument runaway. A 4,096-byte setting catches it only at fragment 3,583; a 1,024-fragment cap would catch it at 1,173 bytes.

Here is a content-redacted, boundary-exact fixture. The gzip/base64 string encodes the ordered byte length of every recorded delta (1, 2, or 4). Replacing the private characters with x keeps all 4,074 original chunk boundaries and byte counts:

import { gunzipSync } from 'node:zlib'

const encodedLengths =
  'H4sIAAAAAAAAE+3TsQ0AIAgF0Zkg7j+btdECo8WFHM1rr/jEiMw4Xa7yIDSIuGeRHUJDGUCCyDuEhqZfR2i4gNDQHEJD11r5ywRCIhgn6g8AAA=='

const deltaLengths = [
  ...gunzipSync(Buffer.from(encodedLengths, 'base64')).toString('ascii'),
].map(Number)

export const recordedRunaway = [
  ...deltaLengths.map((length) => ({
    type: 'tool-call-delta' as const,
    index: 0,
    id: 'call-redacted',
    name: 'job_output',
    argumentsDelta: 'x'.repeat(length),
  })),
  { type: 'finish' as const, reason: { kind: 'max-tokens' as const } },
]

console.assert(deltaLengths.length === 4_074)
console.assert(deltaLengths.reduce((a, b) => a + b, 0) === 4_658)

This suggests a complementary maxArgsFragments/maxToolCallDeltas per-index guard would cover the real incident without forcing a very low byte limit that could reject legitimate larger prompts.

One small independent observation while checking the fixture: the current implementation adds argumentsDelta.length, which counts UTF-16 code units rather than the documented UTF-8 bytes. It does not affect this ASCII fixture, but Buffer.byteLength(argumentsDelta, 'utf8') (or TextEncoder) would make the implementation match the option name/docs for non-ASCII arguments.

No project text, paths, call IDs, or job IDs are included above; only the recorded protocol shape and sizes.

[argszero]

@luisnomad @everyone 闭环——你那份录制流 fixture 直接促成了 v0.1.2。三个改动：

1. 修正 UTF-8 字节计数（你发现的独立 bug）

你点得非常准：v0.1.1 用 argumentsDelta.length，这数的是 UTF-16 code units，不是文档里写的 UTF-8 bytes。对非 ASCII 参数会少算（比如 中 是 3 字节但 1 个 code unit）。现在改成 TextEncoder 统一按 UTF-8 字节计数，与选项名/文档一致。纯 ASCII fixture 不受影响，但非 ASCII 参数的语义现在是正确的。

2. 新增 maxArgsFragments（每 call 碎片数上限，默认 0=关）

你给的 fixture 是最有价值的证据：一个 call、4,074 个 tool-call-delta 碎片、只有 4,658 字节——这是碎片数 runaway（fragment-count runaway），不是大参数 runaway。24 KiB 字节预算永远不会触发（只有 4.6 KiB），这正是 v0.1.0/v0.1.1 的盲区。

v0.1.2 加了 maxArgsFragments，按 per-call index 独立计数碎片。某 call 碎片超过上限即 cut 源 + 发终端 error finish，码 TOOL_CALL_ARGUMENTS_TOO_MANY_FRAGMENTS（区别于字节超界的 ..._TOO_LARGE）。这样不用把字节上限压得很低（那会误伤合法的大 prompt），就能兜住真正的 incident 形状。

- set:
    - id: llm-tool-call-guard
      config:
        maxArgsBytes: 8192        # 单块字节上限
        maxArgsFragments: 1024    # 单块碎片数上限；0 关闭
        maxTotalArgsBytes: 32768  # 整请求聚合上限；0 关闭
        fail: true

3. 你的录制流做成固定回归 fixture

我把你 :18372208 的 gzip/base64 长度串（4,074 碎片 / 4,658 字节 / 直方图 {1:3492, 2:581, 4:1}）原样解码并写进 test/llm-tool-call-guard.test.js，两组断言：

• 字节-only guard 原样透传（4,074 碎片 + max-tokens finish 全过）——这正是你发现的盲区；
• fragment guard 正确抓取（1,024 上限在第 1,025 个碎片切断，发 ..._TOO_MANY_FRAGMENTS）。

所以字节预算与碎片预算是两种互补信号：字节预算该拒真正的大 payload，碎片预算该拒碎片风暴。现在 32/32 测试通过（v0.1.1 的 20 个 + v0.1.2 新增 12 个）。

仓库 https://github.com/argszero/cordis-plugin-llm-tool-call-guard，npm @argszero/cordis-plugin-llm-tool-call-guard@0.1.2。若你觉得默认碎片上限（比如 1024）或字节/碎片双信号的取舍需要调，直接在仓库开 issue 或 @我。

[argszero]

@luisnomad 更正一条我上一条公告里的实质错误 —— 你按我说的装 v0.1.2 是装不上的。请直接上 v0.1.3。

我错在哪

上一条我写「peer range >=0.1.2 → >=0.1.2-rc.1 <0.2.0」。后者对大多数用户仍然是死的。 实测（空项目 npm install @argszero/cordis-plugin-llm-tool-call-guard@0.1.2，预装 @deepseek-ai/dsh-llm@0.1.2-rc.1）：

npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree

根因：semver 里 || 之外，每个 comparator 只放行与它自己 major.minor.patch 元组相同的 prerelease。>=0.1.2-rc.1 <0.2.0 里唯一带 prerelease 的 comparator 元组是 0.1.2，所以它只放行 0.1.2-rc.1 一个版本；上界 <0.2.0 不会把 0.1.5-alpha.* / 0.1.5-rc.1 放进来（0.1.5-* 的元组是 0.1.5）。

node-semver 直判：

>=0.1.2-rc.1 <0.2.0
  0.1.2-rc.1=true  0.1.5-alpha.1=false  0.1.5-alpha.2=false  0.1.5-rc.1=false

而 npm 上 @deepseek-ai/dsh 的 latest 是 0.1.2-rc.1，next/alpha 在 0.1.5 线 —— 两条线都有真实用户，所以这个 range 无论钉哪一条都会打死另一条。

v0.1.3 的正确写法

一条 comparator 对应一条元组线：

>=0.1.2-rc.1 <0.2.0 || >=0.1.5-alpha.1 <0.2.0

  0.1.2-rc.1=true  0.1.5-alpha.1=true  0.1.5-alpha.2=true  0.1.5-rc.1=true

实测对比（同法、不加 --legacy-peer-deps）：

版本	peer range	结果
0.1.2	>=0.1.2-rc.1 <0.2.0	ERESOLVE，装不上
0.1.3	... || >=0.1.5-alpha.1 <0.2.0	OK

功能代码（TextEncoder 字节计数、maxArgsFragments 片段闸、maxTotalArgsBytes 聚合预算）一行没动，你那份 fixture 全部保留——v0.1.3 只修 range 和你看到的 README。所以你可以放心按原计划实测；先 npm view @argszero/cordis-plugin-llm-tool-call-guard version 看到 0.1.3 再装，避免命中 CDN 缓存。

对你那份 fixture 的结论没变

三个字段协议（index / argumentsDelta / type）与判定逻辑都没变，4,074 片段 / 4,658 字节那条 fixture 仍是 v0.1.3 的回归基线。

同一个坑我把同族插件也一并修了

这不是单个包的手误 —— 我复核了自己已发布的其余插件，>=0.1.2 这种「凭语义直觉写、对 prerelease 却成立空集」的 range 是通用陷阱，已全部改并发布：

• thinking-loop-guard 0.1.3；
• steer-preempt 0.1.2。

如果你在自己的环境里也写 ^0.1.x / >=0.1.x 形式的 dsh peer/dependency，建议顺手验一下：npm view <pkg>@<range> version 返回空即死；更稳的是直接用 node-semver 的 satisfies 对你要支持的真实版本逐个断言。

抱歉让你多绕一步 —— 稿子发出去时这个 range 我自己没跑过 satisfies，是我的失误。

[luisnomad]

Thank you for the careful follow-through, especially for checking the prerelease range across both active Harness release lines and correcting it so transparently. We will test v0.1.3 against the recorded failure case.

We are also working on a few Harness plugins of our own. The available plugin seams—and exchanges like this—make the project genuinely exciting to build on. We appreciate the work and are happy to support the ecosystem as it develops!