[bug] Spawn-backed subagents drop reasoningEffort; endpoints that require thinking reject every delegation

[yangwuan55]

Summary

Fresh spawn-backed subagents silently drop reasoningEffort while inheriting the parent's provider/model route, producing requests without a thinking parameter. Endpoints whose models always think then hard-reject every delegation.

Real-world failure (z.ai GLM glm-5.3-flash, reasoningEfforts low/high/max):

400 {"code":"1210","message":"This model always engages in thinking and cannot be disabled; please use low, high, or max"}

The parent tool only sees Error: subagent run failed — no diagnostic — because the in-process driver never populates SubagentResult.diagnostic.

Evidence

Two child sessions, same parent, same provider/model (glm/glm-5.3-flash):

backend	request/header config	outcome
subagent_fork	{provider, model, reasoningEffort: "max"}	✅ completed
subagent (spawn)	{provider, model} — no effort	❌ 400 / 1210

Root cause chain (v0.1.1-rc.2 sources):

1. AgentOptions (packages/core/agent/src/runtime-types.ts) has no reasoningEffort field at all;
2. resolveChildAgentOptions (packages/subagent/subagent/src/child-agent.ts) documents inheriting "the parent's provider/model/maxTokens route" — effort cannot even ride along;
3. In-process children install no installModelSelection, and a fresh loop has no persisted request/header to restore effort from (agent-loop/src/agent.ts buildRequest seeds {provider, model} only);
4. Adapter omits the thinking parameter when effort is undefined (dsh-llm-pi-ai translates absence as provider-default) → z.ai rejects.

Fork is unaffected because it clones the full session header including the persisted effort.

Proposed fixes (PR incoming)

1. Add optional reasoningEffort?: ReasoningEffortId to AgentOptions; inherit it in resolveChildAgentOptions; fall back to it when building a fresh loop's seed config (persisted header keeps precedence).
2. Populate SubagentResult.diagnostic in the in-process driver from the child terminal turn/end error (LlmFailure.message) so parents see endpoint detail instead of a bare headline.

Environment

DSH 0.1.1-rc.2 · agent preset gamedev · tool-subagent provider spawn (backgroundMode continuable)

Filed here because the repository issue tracker is disabled.

[yangwuan55]

Branch: yangwuan55/deepseek-harness @ fix/spawn-effort-inheritance (commit 2e8a9eb)

One-click PR: master...yangwuan55:deepseek-harness:fix/spawn-effort-inheritance
(API/GraphQL PR creation is blocked for my token against this org, hence the manual link.)

[yangwuan55]

复现步骤（最小）

1. 在 llm-pi-ai 里配一个强制 thinking、且服务端不允许禁用 thinking 的模型（如 z.ai glm-5.3-flash，配 reasoningEfforts: [low, high, max]）
2. 设 agent-default-model 为 { provider: glm, model: glm-5.3-flash, reasoningEffort: max }，并用它正常开一个交互会话
3. 会话里直接调用 subagent 工具（provider: spawn）派一个空任务
4. 期望：完成；实际：Error: subagent run failed，子会话日志 request/header 无 reasoningEffort，provider 返回 400/1210。

对照实验：同一父会话改用 subagent_fork 得到完全相同任务 → 成功，子日志 header 带 reasoningEffort: "max"。

绕过方式（用户侧）

换用不强制 thinking 的默认模型（如 deepseek-v4-flash）即可立即解开；但这是绕路由模型差异掩盖缺陷，并非修复。

[argszero]

Reviewed the branch (fix/spawn-effort-inheritance, 5 files, +151/-8) against rc.2 sources — every claim in the write-up checks out:

• AgentOptions has no reasoningEffort (core/agent/src/runtime-types.ts) — confirmed, and the addition with the inheritance JSDoc is consistent with the existing maxTokens pattern.
• resolveChildAgentOptions inherits only provider/model/maxTokens (subagent/src/child-agent.ts:73-79) — confirmed. The new spread keeps the ...requested override-after-inherit ordering, so a request-level effort would still win.
• The seed path: buildRequest previously collapsed to undefined on a fresh loop (agent-loop/src/agent.ts:443-444) — confirmed; the fallback to this.options.reasoningEffort is the right seam, and on a resumed child the persisted header (which the fresh seed logged) keeps precedence via the persistedConfig.model === route.model branch, so cold-resume effort is covered through the header path rather than the option path.
• SubagentResult.diagnostic unpopulated in rc.2 (subagent-in-process-driver/src/index.ts:228-232 — three return paths, none carry diagnostic) — confirmed, and the parent tool already renders it (tool-subagent/src/index.ts:153-163: \nDiagnostic: ${result.diagnostic}), so the fix connects a seam that was built but never fed.
• The extraction shape is right: error turn endings carry { kind: 'error', error: { message, code } } (agent-loop/src/agent.ts:309-314), so lastEnd.data.reason.error.message is the correct path (not .failure).
• Bonus: subagent-fork-in-process calls the same startInProcessRun (fork-in-process/src/index.ts:63), so the diagnostic half lands on the fork path too, not just spawn. Effort on fork rides the seed header as before; the option inheritance is belt-and-braces.

Test quality is good: a direct resolveChildAgentOptions unit case (including the no-effort negative), an integration case asserting the child's logged request/header carries the effort, and the diagnostic case. The errorResponse fixture (error finish with INVALID_REQUEST) exercises the exact z.ai 400 shape.

Three notes, none blocking:

1. Precedence interplay with adapterDefaults.reasoningEffort: the new fallback also fires when persistedHeader.adapterDefaults.reasoningEffort === true — previously that branch deferred to the adapter's own default (undefined), now an explicitly set options.reasoningEffort overrides it. I read that as intended (explicit caller intent beats adapter default), but it changes behavior for presets that set a default effort on an adapter that manages its own. Worth one sentence in the JSDoc or a test asserting the precedence, so the next reader doesn't have to infer it.

2. Per-delegation effort still cannot be expressed: the fix inherits the parent's effort, but tool-subagent's schema has no agentOptions field, so a per-call reasoningEffort override in the tool invocation is dropped at the schema boundary (same gap as the per-call agentOptions drop documented in tool-subagent 静默丢弃子代理路由覆盖（每调用 agentOptions）+ 两个面向仓库外（下游）插件的扩展点缺口 Subagent route override is silently dropped by tool-subagent (per-call agentOptions), plus two extension gaps for out-of-repo (downstream) plugins #1619). Inherited effort now works end to end; per-call effort remains a follow-up.

3. Family cross-link: this is the subagent model-route family ([BUG] Spawned subagents inherit the parent's creation-time model options — stale provider keeps 401ing until server restart #2904/subagent 继承 stale 的 agent.options.provider，忽略 Web 模型选择，导致子代理用错 provider 计费 #3552/BUG: Spawned subagents inherit `agent.options` stamped at agent creation, not the agent's current model selection #4077/[Bug] Manual /compact on a resumed session summarizes through the session's stale routed provider, with zero cache reuse #3565/Subagents inherit the parent's creation-time model seed instead of its live route, delegation silently runs on for exmaple `openrouter/auto` after the default model is switched #4065/[Bug] Subagents inherit session-start options.model instead of the current UI-selected model (causes unexpected v4-pro billing) #1472) — effort is part of the route, and this closes the in-process-child half of route fidelity. The resolveChildAgentOptions route (provider/model/maxTokens/effort) is now the single inheritance surface, which is the right shape for future route fields.

Thanks for the minimal reproduction (the glm-5.3-flash 400/1210 vs fork-completes contrast is exactly what makes the route gap provable) and for shipping the branch despite the disabled-PR workaround.

[denial123789]

Operator field note: the smallest rc.2 proof is a three-header comparison, not the parent-facing error string: capture the parent request/header, the fresh spawn child first request/header, and a fork child header for the same bounded task. Matching provider/model with effort present only on parent and fork isolates the route-fidelity gap before credentials, maxTokens, or retries are changed. For containment, fork is reasonable only when inherited completed context is acceptable; otherwise route the spawn-backed tool explicitly to a model whose contract permits omitted effort. A successful fork is a control result, not proof that spawn is repaired. I documented the evidence template, safe containment boundaries, and fourteen regression gates here: https://sandbaseai.github.io/deepseek-harness-handbook/spawn-subagent-reasoning-effort.html (independent community handbook).

[argszero]

Good template — and it aligns with the branch's own coverage: the author's integration test asserts the spawn child's request/header carries the inherited effort (the spawn side of your three-header comparison), and the fork side rides the persisted seed header — fork reuses the same in-process driver, so its header carries effort as a control by construction. Your point that a successful fork is a control rather than proof of repair is exactly right: the fork path was never broken, so it cannot validate the spawn fix; only the spawn header assertion does.

On containment: agreed, and worth scoping the branch precisely — it fixes inherited effort (parent → child). Per-delegation effort overrides are still dropped at the tool-subagent schema boundary (no agentOptions field, same gap as the per-call agentOptions drop in #1619), so a caller who wants effort on one delegation and not another still cannot express it. Your three-header template is the right acceptance evidence for the inherited path; the per-call path is a separate gap that needs its own schema change.

[weijiafu14]

The effort-inheritance half is well covered — branch reviewed line by line, and @denial123789's three-header template is the right containment. I want to argue for your fix #2, which has had four comments of attention on #1 and none on it.

SubagentResult.diagnostic is not the cosmetic half of this report. Note how you found the root cause: the parent tool showed Error: subagent run failed, and you had to open the child's session log to see 400 / 1210 and the missing reasoningEffort in request/header. The endpoint's message was specific, correct, and already persisted — it just never reached the only party who could act on it. Everyone who hits any future version of this has to repeat your jsonl archaeology.

And this is a repeating class in this repo, not a one-off. Four instances I have read this week, all the same shape — the system held the diagnostic and dropped it before the person who needed it:

• Turn fails with "Cannot read properties of undefined (reading prepare)" on tool dispatch (0.1.1-rc.2) #4667: the tool scheduler lookup returns undefined; the turn dies with Cannot read properties of undefined (reading 'prepare'), naming neither the tool nor the duplicated package that caused it. The reporter reconstructed it from a jsonl.
• [Bug Report] 运行中热重载 cordis.patch.yml 插入 MCP 插件后，新建会话/选择工作区失败（界面闪回未选择状态） #902: the backend returned a fully-populated agent-preset-invalid (preset, loader, package, conflict, file) and the frontend threw it away; the user saw "new session flashes back to no workspace selected", and someone reverse-engineered it.
• DSH 中的 pi 组件把 API 错误误判成「上下文超长」，导致不会触发自动重试 #4657: an empty-body 400 gets classified as CONTEXT_WINDOW_EXCEEDED, so the real cause is not merely hidden — it is replaced with a confident wrong one.
• [Bug][Windows] atomic-write writer lock leaks after first write, breaking all settings persistence (dsh web) #4689: the lock file records the holding PID and nothing reads it, so a crashed process leaves a lock that the next process refuses to touch without explaining why.

The practical argument for landing #2 with #1 rather than after: effort inheritance is one endpoint-contract mismatch. There will be others — a required parameter some gateway wants, a tool-choice mode some model rejects — and each one, with #1 landed and #2 not, produces the identical bare Error: subagent run failed and identical archaeology. Fix #1 closes one instance; fix #2 closes the class of "the child knew and the parent was not told."

One implementation note, since forwarding raw provider text to a parent agent is the kind of thing that gets pushback in review: the child's terminal turn/end error is already persisted in the child session, so #2 is a routing change rather than new information capture — which should make its blast radius easy to argue.

Interest disclosure: I maintain a third-party DSH plugin, and I ship subagent functionality through it, so I am not a neutral party on this topic. That is exactly why I am not proposing anything of mine here — the branch on this thread is the right fix and DSH's native subagent path is not something we touch or could repair. The only thing I am asking for is that the second half of your own report not fall off the end.

[argszero]

This is the strongest argument I've read for #2 being part of the same change rather than a follow-up. Four instances this week across different subsystems, and the shape is identical: the system held the diagnostic and dropped it before the person who could act. The one I can independently confirm from rc.2 source is #902's agent-preset-invalid — api-proxy.ts:346 returns { code, message, details: { agentPreset, reason } } and rpc.schema.ts:54 models it fully, so the backend holds a complete description and the user saw only a flash-back symptom. The diagnostic class is real, and #1 alone closes exactly one endpoint-contract instance of it.

Your "repeating class, not a one-off" framing also sharpens why #2 is the cheap half. The child's terminal turn/end error is already in the child session log — #2 routes existing persisted data to the parent, it does not capture anything new. And readResult is the single seam where the driver decides what the parent sees, so the blast radius is one function that already translates child state into SubagentResult.

Two notes to make #2 reviewable, since "forward raw provider text to a parent agent" is exactly the kind of thing that will get pushback:

1. It's already the model-facing diagnostic, not new sensitive text. The child's turn/end error messages are surfaced to the child's model for self-correction in the child loop (agent.ts maps LlmFailure into the error reason). Forwarding the same text to the parent is not widening the trust boundary so much as it is extending the existing model-facing surface to a second viewer at the same agent plane. Worth stating explicitly in the PR so a reviewer doesn't read it as raw endpoint plumbing.

2. Sort the message. There's a real difference between "the model always engages in thinking and cannot be disabled" (an endpoint-contract fact the parent should act on) and Cannot read properties of undefined (reading 'prepare') (an internal crash). The former deserves to reach the parent; the latter needs a category distinction so it isn't presented as actionable model feedback. A typed SubagentResult.diagnostic is fine; the value should be labeled by whether the turn ended in a provider rejection vs an internal failure rather than being a bare string. The branch's stopReason: 'error' (from the error turn/end) plus diagnostic is the right shape; just make sure the diagnostic the parent acts on is the code+message pair the LlmFailure carried, not a flattened text.

Your disclosure is exactly right, and the argument stands independent of it — the branch on this thread is the fix, and #2 is as much the report as #1.

[yangwuan55]

Thanks for the thorough review — really appreciate the line-by-line check.

One blocker on my side: my token only has pull access to this repo, so I can't open the PR myself.

If you or anyone with write access wants to take it the rest of the way, the branch is yangwuan55:fix/spawn-effort-inheritance (commit 2e8a9eb17) — open the PR from it, or merge it directly, whichever is easier. Happy to follow up on any of the notes once it's up.

Thanks again!

[argszero]

Thanks for the branch and the offer. On the PR itself, I checked the upstream state: this repo has both issues and PRs disabled (hasIssuesEnabled:false, PR list empty), so there is currently no upstream PR channel for anyone to open against — that is why the branch lives on your fork and the fix is being carried in discussion. So "open the PR from it" isn't actionable yet on the upstream side; the branch remains the source of truth.

What I can do, and would offer: I've reviewed the branch and the diagnostic half especially. Two things that would make it land cleanly if/when a channel opens, or if a maintainer picks it up:

1. Order the two fixes as written — #1 (effort inheritance) and #2 (diagnostic) are orthogonal. #2 is the one that closes the "child knew and the parent was not told" class, and weijiafu14's four-instance framing is the strongest argument to land it with #1 rather than after. Both touch different files; #2 is a single function (readResult).

2. For reviewability of #2, since forwarding provider text to a parent agent will get scrutiny: label the diagnostic by whether the turn ended in a provider rejection vs an internal failure, rather than emitting a bare string. The branch's stopReason: 'error' (from the error turn/end) already distinguishes them structurally; carry the LlmFailure code alongside message so the parent can act on an endpoint-contract rejection but not treat an internal crash as actionable model feedback.

If you want, I can build the branch locally and run the existing subagent test suites against it as an extra signal (I can't merge or open a PR, but I can at least confirm it holds up on the test side). Let me know if that's useful.

[argszero]

Following up on the per-call effort gap in this thread: I built and published a community plugin that closes it end to end.

@argszero/cordis-plugin-subagent-effort — https://www.npmjs.com/package/@argszero/cordis-plugin-subagent-effort (source: https://github.com/argszero/cordis-plugin-subagent-effort)

It works on two layers:

1. Effort plumbing (fixes the silent drop). The agent loop's request builder only reads provider / model / maxTokens from AgentOptions (buildRequest in packages/core/agent-loop/src/agent.ts), so a reasoningEffort declared via tool-subagent's agentOptions was accepted and then silently ignored — the model never saw it, no error. The plugin extends the merge-extensible AgentOptions interface with reasoningEffort and injects it into every request through the agent/request waterfall, so config-level effort now actually reaches the adapter.
2. Per-call tool. It registers subagent_effort, which accepts reasoning_effort (off / low / high / max, the DeepSeek adapter vocabulary) and an optional model override per call, forwarded as child agentOptions — the per-delegation control discussed above (your fix #2 direction).

Usage (mount in your profile's cordis.patch.yml, last-write-wins per row):

- set:
    - id: subagent-effort
      config:
        provider: spawn

Verified against the published rc.2 packages with a 13-case smoke test on a real Cordis context (tool lifecycle, request injection, option forwarding). It's deliberately an independent community plugin rather than an upstream change, since PRs are disabled in this repo — and I'd be glad to fold any learnings back into the upstream fix if that path opens.

[yamingmou]

EN / English

Your root-cause trace matches what we found line-by-line when we were digging into dsh-subagent subagent lifecycle — AgentOptions has no reasoningEffort field, and resolveChildAgentOptions only forwards provider / model / maxTokens.

We'd been poking at the same class of bug — option propagation, module-level singletons, lifecycle handoff — and #4793 is where we left our notes on it: dsh-subagent manages cross-module state and lifecycle contracts weakly, and these are two parallel symptoms — option inheritance dropped on spawn, and continuable children orphaned on dispose. Notes there:

Agent disposal does not propagate to continuable subagents
🔗 #4793

Your #4666 is a clean, independently-reproduced instance of the option-propagation half, and the SubagentResult.diagnostic gap you flagged is a good catch on the observability side. The community converging on the same root cause from different angles — we agree with that read.

Verified on @deepseek-ai/dsh 0.1.1-rc.2.

Status update (2026-08-28): the option / inheritance half is now fixed natively in 0.1.2-alpha.1 (argszero verified it against the current tree in this thread), so this thread's option half is closed. Still open: dispose-not-propagating-to-child (see #4793 / #4909) and the SubagentResult.diagnostic observability gap — the latter we're picking up.

---

中文版 / ZH

你这条根因追踪和我们抠 dsh-subagent 子代理生命周期时记的结论逐字吻合——AgentOptions 没有 reasoningEffort 字段，resolveChildAgentOptions 只转发 provider / model / maxTokens。

我们之前也一直在抠这一类问题（选项传播、模块级单例、生命周期交接），#4793 就是我们留下的笔记：dsh-subagent 对跨模块状态与生命周期契约管理薄弱，这是两个并列的症状——spawn 路径上丢选项继承、dispose 时让可续传子代理变孤儿。笔记在那：

Agent disposal does not propagate to continuable subagents（Agent dispose 不传播到可续传子代理）
🔗 #4793

你的 #4666 是"选项传播"这一半一个干净、独立复现的实例；你提的 SubagentResult.diagnostic 缺口，是从可观测性角度很好的补充。社区从不同角度收敛到同一个根因，这点我们认同。

验证环境：@deepseek-ai/dsh 0.1.1-rc.2。

状态更新（2026-08-28）：option / inheritance 这一半已经在 0.1.2-alpha.1 原生修复（argszero 在本帖核过当前树），所以本帖的 option half 已关闭。仍开放的是 dispose 不传播子 agent（见 #4793 / #4909）与 SubagentResult.diagnostic 可观测性缺口——后者我们准备接。

[argszero]

Thanks for the maintainer-side confirmation — and good timing: this gap is now fixed natively in 0.1.2-alpha.1, which is already released upstream. Verified against the current tree:

• AgentOptions now declares reasoningEffort?: ReasoningEffortId (packages/core/agent/src/runtime-types.ts), and the agent-loop request builder consumes it: buildRequest resolves this.options.reasoningEffort ?? persistedReasoningEffort and folds it into the agent/request proposal (packages/core/agent-loop/src/agent.ts).
• dsh-tool-subagent now declares per-call agentOptions in its schema and exposes a model-facing reasoning_effort parameter, forwarded as child agentOptions — the second half of the gap this thread was about, plus run_in_background/continuable delegation on top.

So the option-propagation half of the #4666/#4793 pattern is closed as of the alpha.1 line. My community plugin @argszero/cordis-plugin-subagent-effort is therefore superseded on ≥ 0.1.2-alpha.1 — I've marked it as such in its README and it stays only as a fix for users pinned to 0.1.1-rc.2, where the silent drop still exists.

One loose end the thread raised that I'd still like to see covered: the SubagentResult.diagnostic observability gap. If the architecture-layer series picks it up, I'm happy to help verify against the current code once it lands.

(Related: the browser-UUID half of this same "weak cross-module contract" theme — #4756 — also landed in alpha.1 via the new packages/util/crypto module; posting a separate confirmation there.)

[yamingmou]

EN / English

Your confirmation just pushed our #4793 notes forward a version: the option / inheritance half landed natively in alpha.1, so our rc.2 reproduction is only valid for ≤ rc.2 — the notes need a re-baseline to alpha.1. The dispose half (parent dispose not propagating to continuable child agents) is still in #4793 / the #4909 we just posted, and for now only Jstn-1g's reference implementation exists.

The SubagentResult.diagnostic observability gap — we'll take it. It's really the "weak cross-module contract" pattern showing up on the observability side, same frame as #4909. Your line about "the system held the diagnostic and dropped it before the person who could act" nails the root of it. Once our write-up lands at the code level, happy for you to verify against the current tree.

(Side note: #4756 browser-UUID also landed in alpha.1 — noting it for the record.)

---

中文版 / ZH

你这条确认正好把我们 #4793 的笔记往前推了一版：option / inheritance 这一半在 alpha.1 原生合入了，那我们 rc.2 的复现只对 ≤ rc.2 有效，笔记得 re-baseline 到 alpha.1。dispose 那半（父 dispose 不传播到可续传子 agent）还在 #4793 / 我们刚发的 #4909 里，目前仍只有 Jstn-1g 的参考实现。

SubagentResult.diagnostic 那个可观测性缺口——我们接。它本质就是"弱跨模块契约"在可观测性侧的体现，跟 #4909 同框架。你那句"系统握着诊断信息、却没递到能动手的人手里"正好点准了根。等我们那篇落到代码层，欢迎你帮核对当前树。

（顺带记一笔：#4756 browser-UUID 也进了 alpha.1。）