主会话设置子代理的时候，不能给模型设置推理程度，这不好吧？

[Brovetrue]

主会话设置子代理的时候，不能给模型设置推理程度，这不好吧？

[weijiafu14]

确实不能——DSH 的 subagent 工具参数里没有推理档位这一项，resolveChildAgentOptions 也只透传 provider / model / maxTokens，reasoningEffort 会被丢掉。用推理必需的模型（比如 ox-alpha）派子代理还会直接 400，#4555 有完整的源码定位。

要按子代理单独设推理档位，今天可以走另一条子代理运行时：

dsh plugin --profile <你的 profile> add pi2dsh
dsh plugin --profile <你的 profile> add @tintinweb/pi-subagents
# 装完重启 dsh

它派出的子代理是真正的 DSH 会话，per-child thinkingLevel 会变成那个子代理自己的 reasoningEffort（走官方 agent/request waterfall，不外泄给兄弟或父级）；模型也能按子代理单独指定，不指定就跟随调用方当前实时选择的路由。

边界：这不修复 DSH 原生的 subagent 工具，是并行的另一套。

examples/subagents · 验收报告

[fan56]

哈,我也自己写一个. https://github.com/fan56/dsh-subagent-registry
然后 disable 默认的 subagent 工具,只用我的

[nokkies]

Agreed, and implemented — the gap is real and narrower than it looks, which is why it is easy to miss.

AgentOptions carried provider, model, and maxTokens but not reasoningEffort, so a delegating caller could pick a child's route and output budget and not its thinking budget. Effort reached a request only one way: restored from a session's own logged request/header when it belonged to that exact route. A freshly spawned child has no such history, so it always took whatever the route defaulted to, and the obvious swarm shape — a cheap model at low effort for fan-out, the flagship at high effort for the hard step — was unexpressible.

What we landed:

• AgentOptions.reasoningEffort, seeded into the request config exactly as model and maxTokens are. A resumed session's logged effort still wins where it belongs to that route (that history was produced under it); only its absence falls through to the declared value.
• Children inherit effort with the route rather than beside it. Effort is chosen for a model, so a child on the parent's model inherits the budget picked for that model, while a request naming its own model overrides route and budget together. Mixing one session's effort into another session's model is the bug that shape avoids.
• The subagent tool's modelChoices carries it, so a deployment offers named aliases (cheap = small model + low effort, deep = flagship + high) and the model picks between them through the existing model parameter.

One deliberate omission: no validation was added at any of these layers. The LLM runtime already rejects an effort the routed model's catalog does not declare (UNSUPPORTED_REASONING_EFFORT), so a wrong value fails loudly at the one place that actually knows the answer, instead of being re-checked in three places that would drift.

Worth flagging for anyone adopting this: it only does something where the provider entries declare an effort catalog. On a route whose models declare none, setting it is correctly inert — we confirmed exactly that on one deployment, where the knob would have been a no-op until someone adds efforts to those model entries.