[bug]SubAgent routing can use stale/wrong models and silently escalate cost

[HikariVerse]

SubAgent routing can use stale/wrong models and silently escalate cost

I have encountered two serious SubAgent routing issues in DSH.

1. SubAgents may inherit a stale model/provider route

In a previous long-running project, I switched the Root Agent to bailian/kimi-k3, but newly spawned SubAgents still used deepseek-official/deepseek-v4-pro.

This appeared to behave like a “one step behind” / stale route inheritance bug: the Root Agent showed the newly selected model, while SubAgents continued using a provider/model snapshot from the previous session/state.

In that run, the Root Agent was Kimi, but all 20 SubAgents were actually routed to DeepSeek V4 Pro, resulting in unexpected additional API cost.

So the model shown for the Root Agent does not necessarily represent the model that newly created SubAgents will actually use.

2. Flash Root Agent can silently spawn more expensive Pro SubAgents

More recently, I explicitly started a task with:

deepseek-v4.1-flash (high)

but DSH automatically spawned multiple:

deepseek-v4-pro (high)

SubAgents.

Three Pro SubAgents were created before I manually stopped the task. The run cost about RMB 6 and was still incomplete.

The current SubAgent Route Guard detected the route mismatch, but only after the first request had already happened. In other words, it currently behaves more like an audit log than a real guard.

Expected behavior

Before any SubAgent sends its first model request, DSH should resolve and verify its effective provider/model.

At minimum:

• A new SubAgent should not inherit a stale route from a previous Root/session state.
• SubAgents should not silently escalate from Flash to a more expensive Pro model.
• Any route mismatch or cost-tier escalation should be blocked during preflight, before billing occurs.
• Preferably, SubAgents should inherit the current Root model by default unless the user explicitly allows automatic model escalation.

The core issue is that SubAgent routing is currently not predictable enough for users to control either model selection or cost.

[yamingmou]

EN / English

Quick note: I checked current master and the stale-route half of this looks already addressed — child agents now take the parent's model/provider from its latest request header rather than a spawn-time snapshot. If you hit this on an earlier version that would explain it — which version were you running?

The Flash-root-silently-spawning-Pro-subagents half is real regardless of version though: the UI shows one model while children actually run another, with no warning about the cost jump. That one deserves a fix on its own.

---

中文版 / ZH

补一句：我翻了翻当前 master，stale 路由这部分看起来已经处理了——子代理现在是从父会话最新的 request header 拿模型/provider，不是创建时快照。如果你是较早的版本遇到这个，那就说得通了——你当时跑的是哪个版本？

Flash Root 静默拉起 Pro 子代理那半，跟版本无关、是真实问题：界面显示一个模型、子代理实际跑另一个，成本跳档也没有任何提醒——这半值得单独修。

[argszero]

@HikariVerse @yamingmou

我核对了一下当前 master（c389f96bf3），支持 @yamingmou 对"stale-route 半段已修"的判断，但想把你这个报告的两个半段拆开——它们的机制其实不同，别混在一起定位。

① stale-route 半段：master 已修（支持 @yamingmou）
packages/subagent/subagent/src/child-agent.ts:68-85 的 parentAgentOptionsForDelegation 现在读的是 parent.session.requestHeader()?.config（父代理最新一次请求头的 provider/model/reasoningEffort），只在没有 request header 时才回退到 parent.options。也就是说子代理继承的是"父代理当下真正在用的 route"，而非 spawn 时刻的快照。所以如果你之前遇到"Root 显示新模型、子代理仍用旧模型"，那基本可以确定是旧版本的 spawn-time 快照行为——新 master 已经改了。你方便的话贴一下你跑的版本号（dsh 闭包版本），能帮确认。

② Flash-root→Pro-subagent 半段：这是真的，但机制不是 stale-route，而是"纯继承跳过 cost-tier preflight"
关键在于 packages/subagent/tool-subagent/src/index.ts:473-474：

const requiresRoutePreflight = hasDelegationModelRequest(modelRequest)
  || hasConfiguredLlmSelection(config.agentOptions)

preflightChildLlmRoute（index.ts:495）只在有显式 modelRequest（模型工具调用里选了 route/effort）或配置了 agentOptions 时才跑。纯继承（两者都无）→ requiresRoutePreflight = false → 不 preflight，子代理直接继承 parentOptions（= 父代理最新 request header 的 route）。

所以"Flash root 却 spawn 出 Pro 子代理"，现实有三种可能，都指向 cost-tier 治理而非路由陈旧：

1. route 确实发生了继承：父代理某次请求 header 的 model 已经是 Pro（可能是 provider 代理/proxy 路由、或 catalog 默认给的高层 model），纯继承把它带给了孩子。
2. providerRouteDefaults/配置层给了 Pro：子代理实例 (config.agentOptions) 或 provider 默认路由指向 Pro。
3. cost 来源本身是 route 默认：这不是"用了错误模型"，而是"inherit 了比 root 预期更高的 tier"——正是你说的"用户没法控制 model 或 cost"的核心。

你期望的"preflight 在首次请求前解析并验证有效 provider/model、阻止 tier 升级"，实际上就是要把 requiresRoutePreflight 的判定从"有显式选择"扩展到"纯继承也检查 cost-tier 边界"——比如继承的 route 若超过 root 当前选定的 tier，preflight 就 warn / block（可配置成默认继承 root 的 tier 而非静默升级）。

③ 一个可挂载的插件面提示（与你的诉求相关）：我发过一个 @argszero/cordis-plugin-subagent-effort（处理 #4666 进程内后端 reasoningEffort 被静默忽略 + subagent_effort 工具每调用传 effort/model），它管的是 effort 透传那一环。而你这里"子代理 route 可预测性/成本控制"是更宽的一条线——subagent.started 通知目前只带 parentSessionId/childSessionId，不带实际生效的 provider/model/effort，所以上层（或插件）今天无法在子代理创建后展示它真正用的 route。我此前在 #5904 提过这个"生效配置展示缺口"。如果你想让"子代理实际 route"可观测，可以考虑在 subagent.started/会话事件上富化展示——那是插件可挂载的面。

建议：如果你能确认版本 + 提供该次运行的 route 快照（root 当时 request header 的 provider/model），就能把②的三种可能收敛到具体一种；若确认是纯继承跳过 preflight 的 cost-tier 问题，那值得单独提一个"给纯继承子代理也做 route/cost-tier preflight"的 feature（core 面），我可以帮忙起草。