为subagent选择了模型为什么还是使用的主模型？

[useryyonghu]

我在subagent只选择某模型做子代理，主模型只管大方向方案和代码评审。但是我发现很多子代理启动后都是使用的主模型，这是为什么？

[argszero]

Short version

That card authorizes which models the agent may choose — it is not a "default model for subagents". And a second delegation tool (subagent_fork) cannot take a model at all, by design. So "the child runs the parent's model" is the expected result in two of the three cases below, not a broken setting.

1. The preference is an authorization list, not a child default

• packages/subagent/tool-subagent/src/model-selection-settings.ts:24-25 (docstring): "Exact child LLM routes offered to newly composed top-level Sessions" — a candidate list the agent picks from per delegation. The UI says the same ("Models agents may choose", "Applies only to new sessions"), but it reads like "the model subagents use".
• The choice is made by the agent, per call: subagent(provider: 'X', model: 'Y'). If it omits those fields, nothing is overridden — and the tool's own system prompt tells it that omission is the normal case (index.ts:373): "Child LLM selection is optional. Omit provider, model, and reasoning_effort to use configured child defaults and inherit compatible missing values from the parent Agent."
• The merge confirms it — model-selection.ts:93-95: if (!hasDelegationModelRequest(request)) return configured. With no explicit route, whatever the child would have used anyway survives untouched.

⇒ Enabling the card and picking a model is only half the path: the agent still has to name that route in each subagent call, or the child inherits the parent on purpose.

2. subagent_fork never offers model selection (the likely answer to "many subagents")

• packages/bundle/base/cordis.patch.yml:363-368, the comment above the fork row: "Fork omits model selection so provider/model stay equal to the parent and the inherited history remains eligible for KV Cache reuse."
• The fork rows carry no modelSelectionSettings (base :369-374; presets/standard/agent.cordis.yml:193-198), and the route fields only exist on the schema when that flag is set (index.ts:401-419: ...modelSelectionEnabled ? { provider, model, reasoning_effort } : {}). ⇒ subagent_fork's children always run the parent's route.
• That is deliberate: a fork child replays the parent's conversation, and a different model would void the KV-cache reuse the tool exists for. So any delegation that goes through subagent_fork (it is its own tool name) is out of the setting's reach.

3. There is a composition prerequisite — and when it is unmet, your setting is read by nobody

• modelSelectionSettings defaults to false (index.ts:109). The base bundle mounts tool-subagent without it (base/cordis.patch.yml:356-361); the shipped presets enable it (standard:186, ptc:193, cordis:182), and the Web app's default preset is standard (bundle/web-app/cordis.patch.yml:514-517) — so a stock Web install on the default preset does have the capability.
• But on any composition whose tool-subagent row omits it, this happens: index.ts:609-612 returns before the settings are consulted — const settings = ctx.get('subagentModelSelection') sits at :614, after the early return. The preference is then stored, rendered in the settings UI, and read by nobody, with no warning anywhere in the tree. This is the one silent case here, and the one worth reporting if it matches your install.

A one-step check

Does the session expose the list_subagent_models tool? It is registered iff a model-selection policy is live for that session (index.ts:361-363), and an invariant keeps the policy, the route fields and list_subagent_models together (invariant.ts:26-38). So:

• present ⇒ the card is live for you; the answer is (1) or (2) — check whether those delegations called subagent or subagent_fork.
• absent ⇒ the capability is off in that composition ⇒ the panel is inert, i.e. case (3).

If you want it deterministic

• Composition-level: give the tool instance child defaults — Config.agentOptions (index.ts:73-76: "Agent options applied to every child; omitted fields use child-loop defaults"), i.e. per-instance provider / model / reasoningEffort / maxTokens. Every child of that instance then starts from that route.
• Plugin-level: @argszero/cordis-plugin-subagent-model@0.1.0 — it hooks the agent/request waterfall and pins a child's provider/model per session, so it depends neither on the modelSelectionSettings prerequisite nor on which preset/bundle composed the session. Mount it with a dsh.bundle.patch row. v0.1.0 pins one choice for all children; a per-child roster is not implemented.

Honest boundary

Nothing above says your install is broken: (1) and (2) are documented behaviour, and only (3) is a silently-inert configuration. If what you actually expect is "children default to the model I picked", that is a reasonable product suggestion rather than a bug report — the current copy is accurate, but it points the other way from how it reads.

[useryyonghu]

谢谢