Authoritative effective model selection for subagents and plugin runtimes

[Altairpaca]

Summary

Third-party DSH plugins that route models (agent distributions, team runtimes, workflow plugins) need an authoritative seam to determine the effective provider / model / reasoningEffort of a request. This is a question about the ecosystem contract, not a bug report.

Background

DSH already provides rich seams: ctx.llm.resolveModelInfo for exact-model capability, installModelSelection for composing provider/model/reasoningEffort into an agent's request config, prepareCall for validating a call config, and the session log's request/header event as the durable record of what was actually sent.

We are building DSHelm, an independent DSH-native agent distribution, and we wrote a keyless contract test that asserts the full chain:

DSHelm resolved policy (provider/model/reasoning)
  → real agent loop + installModelSelection composition
  → session request/header event
  → adapter GenerateOptions (the actual provider I/O)

For our own path these four agree (test: packages/dsh/tests/dsh-request-contract.test.ts). The question is about plugin-authored model routing — e.g. a team runtime that wants per-member models.

Observations on the ecosystem

• dsh-agent-teams (0.1.5) passes per-member agentOptions: { provider, model } into subagents.startContinuable and uses a withPending bridge to make the selection visible while the child materializes. That is a reasonable composition strategy.
• The durable, replayable record of what actually happened is the child session's request/header event (and the adapter's GenerateOptions).
• There is no documented "effective model resolution" service: resolveModelInfo answers capability questions, prepareCall validates, but neither is an authority on which route a particular child ended up with.

Questions

1. Is the session request/header event the authoritative evidence plugin authors should assert against for effective provider/model/reasoningEffort? (That is what we do; we'd like this confirmed as the intended contract.)
2. Is there (or is there a plan for) a public seam that answers "what effective route did this agent/child resolve to" — e.g. a request/header read helper, a model-selection snapshot, or a documented invariant?
3. For plugin-authored routing (per-member models, fallback chains), what is the recommended composition point: agentOptions on SubagentStartRequest, installModelSelection in the child setup scope, or both with an explicit precedence?

Environment

• dsh --version: 0.1.0-rc.6
• @deepseek-ai/dsh-*: 0.1.0-rc.6, Cordis 4.0.1
• Test evidence: keyless composition (scripted rc.6 adapter), no credentials needed

We encountered this while building DSHelm, an independent open-source agent distribution for DSH (not affiliated with DeepSeek). Happy to turn any of the above into a concrete proposal or test fixture if that helps.

[Electricitysheep]

模型路由需要"权威生效模型选择"（子代理/插件运行时）——第三方插件做模型路由时缺一个标准接口，和 #1498/#2006 的诉求同源。

模型选择/继承的机制第 9 章有讨论：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/09-mcp-subagent-workflow.md

[Cfomodz]

Duplicate of #1581/#1472/#2006

[weijiafu14]

先说一句：@Cfomodz 的"Duplicate of #1581/#1472/#2006"我认为判错了，而且这个判错会让这帖被埋掉，所以值得说清楚。

那三帖是缺陷报告（子代理继承了创建期冻结的模型快照，导致跨 provider 计费）。你这帖你自己在开头就写明了：

This is a question about the ecosystem contract, not a bug report.

你问的是"插件作者该拿什么当权威证据"。这两件事不但不重复，而且是互补的——那三帖恰恰是"该拿什么当权威"这个问题答错时的后果。下面我把这层关系说清楚，也算是对你三个问题的一份来自另一个消费者的回答。

你的问题 3 先答：agentOptions 不能当权威，而那三帖就是证据

你问"per-member models 这类插件自建路由，推荐的组合点是 agentOptions on SubagentStartRequest 还是子代理里的 installModelSelection"。

#2470 那份 RCA 把 agentOptions 这条路的性质查得很清楚：resolveChildAgentOptions 读的是 parent.options（父 agent 创建/恢复时传入的 AgentOptions），而父 agent 的实际服务路由可以被模型选择瀑布按请求覆盖。两者一旦分叉，子代理就静默记到 agent.options 里写的那个 provider 上——那次事故是 61 个子会话、约 770 万 token 全记错了账。

更关键的是那位补的一条：GUI 里换一次模型就会立刻产生分叉，不需要重启。所以：

agentOptions 是一份创建期快照，它在语义上就不是"这个子代理实际会用哪条路由"的答案。 把它当权威读，就会复现 #1581 / #1472 / #2470 那一族。

这正好解释了 dsh-agent-teams 为什么要加那个 withPending 桥——它是在补一个"选择已表达但尚未生效"的窗口，而这个窗口的存在本身就说明 agentOptions 不是权威。

你的问题 1：我们也把 request/header 当权威，算一份独立的实践数据点

我维护 pi2dsh（Pi 生态兼容层），它跑一套 Pi 生态的子代理。我们的端到端断言里有一条是 "父会话切换 /model 之后，未固定模型的子代理跟着换到新路由"——而验证这条靠的正是读会话日志里那条实际发出的记录，不是读任何"计划要用什么"的字段。

也就是说：在没有官方表态的情况下，至少有两个独立的第三方（你们和我们）不约而同地选了 request/header 当权威，理由也一样——它是事后不可否认的记录，而所有"事前意图"类的字段都可能在中途被覆盖。

（严格说这不是对你问题 1 的回答——只有维护者能确认它是不是"intended contract"。我能提供的只是"另一个人也这么做，并且这么做的原因是什么"。）

你的问题 2：这个 seam 现在有第二个消费者了

你问有没有（或计划有）一个"这个 agent/child 最终解析到哪条有效路由"的公开面。补一条你可能没看到的：

#2639 提的 RFC（"每次新 activation 重新解析 continuable 子代理策略"）需要的是同一个东西——它要在每次 create / followup / retry / cold-resume 之前解析出当前有效策略，而"当前有效策略是什么"正是你问的那个 seam。

两帖并起来看，这个 seam 有两类需求方：

	需要它做什么
你（#2053）	读：断言"这个 child 实际用了什么"，作为契约测试与可观测性的依据
#2639	写：在 activation 发布前决定"这个 child 该用什么"

一个既能读又能写的权威解析点，比两个各自的补丁值钱。建议互相引一下——一个 seam 提案有两个来自不同方向的真实消费者，是最难自证也最有说服力的东西。

一个附带的建议

你们那个契约测试（DSHelm 解析策略 → agent loop + installModelSelection → request/header → adapter GenerateOptions 四者一致）本身很有价值。建议在原帖里把它的"能证伪什么"写得更显眼——它不是"我们的实现是对的"，而是"如果这四者哪天不一致了，这个测试会红"。这个社区里最近连着出了好几例"声明处有值、消费处读不到、中间没人报错"的问题，而你们这条链恰恰是那类漂移的探测器。

边界与利益相关

我们不修 DSH 自家组件——模型选择瀑布、request/header、subagent 的 options 解析都在 DSH 里。上面全是对已有报告的引用与一份实践数据点；我没有读过 DSHelm 或 dsh-agent-teams 的源码，关于它们的描述完全采信你的原帖。

利益相关：我维护 pi2dsh，它也做模型路由，所以我和你在这个 seam 上是同一类需求方——先说在前面。这条不推销：你要的是官方确认一个契约，装我们的东西对此毫无帮助。