BUG: Spawned subagents inherit agent.options stamped at agent creation, not the agent's current model selection

[duoartisan]

Spawned subagents inherit agent.options stamped at agent creation, not the agent's current model selection — silent cross-provider divergence after a model switch

Summary

An agent's options (provider/model/maxTokens) are stamped once at session/agent creation and are never rewritten when the user changes the model. Per-request model changes are applied by a separate layer — the agent/request waterfall (installModelSelection in dsh-agent) — which only overrides the current agent's own requests using a live per-session selection.

Subagents, however, inherit the parent's options (resolveChildAgentOptions in dsh-subagent) and completely bypass that overrides layer.

Net consequence: after the user switches the session model, the parent's live requests use the new model while every subsequently spawned subagent runs the old model — potentially a different provider with real billing/quota impact — with no visible sign in the parent session.

Observed in a real session: the parent session ran 100% of its requests on provider bitdeer, while all 43 subagents spawned by 6 workflow runs ran on provider opencode-go / model deepseek-v4-flash, exhausting that provider's weekly quota (429 GoUsageLimitError). The parent session log contains zero references to opencode-go.

Environment

• dsh packages: 0.1.1-rc.2 (dsh-agent, dsh-agent-loop, dsh-subagent, dsh-workflow-worker-thread, dsh-llm-pi-ai)
• Surface: Web GUI (dsh web), llm-pi-ai multi-provider adapter
• OS: Windows (platform-independent)

Reproduction

Preconditions:

• Configure at least two providers under llm-pi-ai.providers, e.g.:
  • opencode-go with model deepseek-v4-flash
  • bitdeer with model deepseek-ai/DeepSeek-V4-Flash
• The session/agent must be created while the effective model is opencode-go / deepseek-v4-flash (via agent-default-model or the session's /model selection at creation).

Steps:

1. Create a session (its agent's options are stamped with opencode-go / deepseek-v4-flash).
2. After the agent exists, switch the model to bitdeer / deepseek-ai/DeepSeek-V4-Flash (composer /model, or change agent-default-model).
3. Verify the parent's own next requests now use bitdeer (visible in the session's request/header).
4. Run a workflow whose agent() calls pass no provider / model override (e.g. agent(prompt, { label, phase })).
5. Inspect each spawned subagent's request/header.

Actual result: every spawned subagent's request/header config is { "provider": "opencode-go", "model": "deepseek-v4-flash" } — the provider captured at agent creation — while the parent's own concurrent requests are { "provider": "bitdeer", "model": "deepseek-ai/DeepSeek-V4-Flash" }. In the observed session this silently consumed a third-party weekly quota (429 GoUsageLimitError, "Weekly usage limit reached").

Expected result: subagents inherit the agent's current effective model selection (the same provider/model the parent is actually using for its own requests), or the delegation layer exposes an explicit, documented "subagent default model" that cannot silently diverge from what the user sees.

Evidence (from the affected session export)

Parent session jsonl (every request, from the first): config is bitdeer / deepseek-ai/DeepSeek-V4-Flash.

Sub-agent session jsonl (every child, e.g. subagents/<id>/session.jsonl):

{"type":"request/header","data":{"header":{"config":{"provider":"opencode-go","model":"deepseek-v4-flash","maxTokens":384000},...}}}

Quota error observed in the same sub-agent:

429: {"type":"GoUsageLimitError","message":"Weekly usage limit reached. Resets in 1 day. To continue using this model now, enable usage from your available balance: https://opencode.ai/workspace/<redacted>}"}

Parent-session workflow records: tool-workflow/run-start × 6, tool-workflow/agent-start × 31; the workflow scripts passed only { label, phase } — no provider/model overrides.

Code analysis

1. agent.options is a creation-time snapshot that is never rewritten. dsh-agent-loop constructs the agent with the options passed at creation (prepare(ownerCtx, id, options, session) → new ReactLoopAgent(loopCtx, id, options, session) → this.options = options). Nothing updates this.options when the model is switched.

2. Per-request model is seeded from options, then overridden by a live selection without touching options (dsh-agent-loop, ReactLoopAgent.buildRequest):

   const route = { provider: this.options.provider ?? "", model: this.options.model ?? "" };
   const maxTokens = this.options.maxTokens;
   const seedConfig = ... { ...route, ...(reasoningEffort === undefined ? {} : { reasoningEffort }),
                              ...(maxTokens === undefined ? {} : { maxTokens }) };
   const proposedConfig = await this.dispatch.waterfall("agent/request", {...}, () => Promise.resolve(seedConfig));

   The agent/request waterfall is where installModelSelection (dsh-agent/lib/types/model-selection.js) applies the live per-session selection — so a model switch changes the agent's own requests while this.options stays frozen at the creation-time value.

3. Subagents inherit parent.options and never see step 2's override (dsh-subagent/lib/types/child-agent.js, resolveChildAgentOptions):

   export function resolveChildAgentOptions(parent, requested, childDepth) {
       const parentProvider = parent.options.provider;
       const parentModel = parent.options.model;
       const parentMaxTokens = parent.options.maxTokens;
       return { ...(parentProvider !== undefined ? { provider: parentProvider } : {}),
                ...(parentModel !== undefined ? { model: parentModel } : {}),
                ...(parentMaxTokens !== undefined ? { maxTokens: parentMaxTokens } : {}),
                ...requested, subagentDepth: childDepth };
   }

4. The workflow engine only overrides when the model-facing call explicitly does so (dsh-workflow-worker-thread/lib/index.js, startChild): agentOptions is built only when request.provider or request.model is present; otherwise the child purely inherits step 3.

So the two surfaces — the request-layer selection and the delegation-inherited options — are deliberately decoupled for live switching, but only one of them updates, turning the decoupling into a silent misroute for every delegated child. There is no guard or warning when a child's inherited provider differs from the parent's current request provider.

Suggested fixes (any one prevents the silent divergence)

• At delegation time, resolve the child model from the agent's current effective selection (the same selection installModelSelection applies to the parent's requests), instead of the raw parent.options snapshot.
• When the session/agent selection changes (via /model or agent-default-model), also update agent.options — or otherwise version the stamp — so delegation inheritance tracks the switch.
• Alternatively, expose a first-class, visible "subagent default model" that defaults to the current selection and is surfaced in the UI/session record, and log a warning when a child resolves to a different provider than the parent's current request route.

Notes / secondary observation

In the affected deployment the base composition default agent-default-model is deepseek-official / deepseek-v4-flash, but no llm-deepseek section is configured, so that route is unserved; the bare model id deepseek-v4-flash is offered by opencode-go (a pi-ai built-in provider) while other providers use namespaced ids. This makes a misrouted default land on a specific provider quietly. Consider logging a warning whenever a request's provider is resolved from a bare model id across providers, and/or validating that agent-default-model points at a configured route at creation.

Closing notes

No code patch yet — this is a bug report with reproduction, observed evidence, and code-level analysis. Happy to provide sanitized log excerpts or a minimal repro setup on request.

[argszero]

Verified against v0.1.1-rc.2 source — your diagnosis is correct, and the 43-subagent/429-quota observation makes it the strongest evidence yet for a mechanism that has now been independently reported three times. This is the fifth member of a family I have been tracking; the fix blueprint already exists.

Source confirmation

• resolveChildAgentOptions (packages/subagent/subagent/src/child-agent.ts:68-83) copies parent.options.provider/model/maxTokens and spreads the per-call override. It reads the creation-time snapshot, exactly as you describe.
• installModelSelection (packages/core/agent/src/model-selection.ts:39-78) registers system-prompt/assemble and agent/request waterfall handlers on the parent's scoped ctx. The child is composed on its own ctx via ctx.agents.create(...) (continuation.ts) — it never enters the parent's selections map, so no handler rewrites its route. Your "separate layer only overrides the current agent's own requests" is precisely right.
• Seed timing locks it: buildRequest (agent-loop/src/agent.ts:440-486) seeds the first request/header from this.options when !requestHeaderLogged — the divergence is decided entirely at seed time.

Family (5 reports, same root: creation-time snapshot vs live selection)

• [BUG] Spawned subagents inherit the parent's creation-time model options — stale provider keeps 401ing until server restart #2904 — subagent auth-401: frozen parent.options after a mid-session switch, 100% child dispatch failure with dead credentials.
• subagent 继承 stale 的 agent.options.provider，忽略 Web 模型选择，导致子代理用错 provider 计费 #3552 — subagent billing-misroute: same frozen-options mechanism, independent repro, wrong billing account. Root-cause analysis matched yours; I identified the third-layer gap there: the child ctx has no selection slot installed at all (no agent/request waterfall, so buildRequest always reads frozen options).
• BUG: Spawned subagents inherit `agent.options` stamped at agent creation, not the agent's current model selection #4077 (this report) — same mechanism, now with the quota-exhaustion consequence (429 GoUsageLimitError). Your parent-log-contains-zero-references-to-opencode-go point is the cleanest discriminator for this class.
• [Bug] Manual /compact on a resumed session summarizes through the session's stale routed provider, with zero cache reuse #3565 — compaction summarization: summarizer.ts prefers session.requestHeader()?.config over the configured target, which can be days stale on resumed sessions → zero cache reuse + wrong-provider billing. Same "last routed header as default" heuristic, same freshness problem.
• 到达输出 token 上限时，出现“本轮运行失败invalid pi-ai replay state: block count does not match assistant content” #1627/invalid pi-ai replay state: block count does not match assistant content after truncated output + continue #1703/Truncated turn (stopReason "length") desynchronizes pi-ai replay state; session uncontinuable with INVALID_REPLAY_STATE #2143 — replay-state coherence (truncate/continue mid-tool-call): persisted context vs live metadata diverge, hard-fail the turn.
  Common lesson: any "inherit from the parent/persisted artifact" default is sound only while the source is warm; once it can outlive a model switch or a session resume it needs a freshness guard. Fix shape shared across all members: inject the live source over the persisted snapshot.

Fix blueprint (three tiers, from the earlier analysis)

1. Minimal (one call site): in resolveChildAgentOptions, prefer parent.session.requestHeader()?.config over parent.options — requestHeader() is a public Session API (session/index.ts:670) and the module doc notes both the one-shot driver and the continuation manager compose children through this one function, so one change covers subagent and subagent_fork. There is even a precedent in the same file: childSessionMeta (child-agent.ts:102) already reads parent.session.header for durable metadata.
2. Edge case: a child spawned immediately after the switch, before the parent's next request, still sees a stale folded header (the picker's pending selection is not yet in any request/header). Fixing that needs the child to share the parent's live WebModelSelectionRef (crosses the api-proxy/subagent boundary), or moving the route decision to the child's first agent/request waterfall.
3. Symmetric long-term: in-process children share the parent's selection ref so /model picker switches propagate too — and keep the two sources aligned (child-agent.ts:73 inheritance and agent.ts:440 route construction), otherwise only the descriptor/header first request gets fixed and later steps drift again.

Blind spot worth checking: continuable children on cold resume — does the resume path re-resolve the route from the live default, or keep the stale persisted header until the first request? If the latter, the resume path needs the same freshness guard (this is exactly what bit #3565).

One question for your repro: were the workflow subagents spawned through the in-process provider (continuable) or the fork provider? The fork path re-creates the agent from the live default on resume, which would mask the bug in some scenarios — your 43/43 consistency suggests in-process, but confirming pins the fix surface.

[weijiafu14]

This now has a tested alternative route for users who need to stop silent cross-provider delegation immediately. It does not claim to fix DSH's native spawn provider; it runs stock @tintinweb/pi-subagents as native DSH child sessions through pi2dsh:

dsh plugin --profile <你的-profile> add pi2dsh
dsh plugin --profile <你的-profile> add @tintinweb/pi-subagents

An unpinned child inherits the parent session's last durable real request route, not agent.options stamped at creation. Explicit per-child selection still wins. The provider/model pair is persisted in the child's own request/header, so billing drift is auditable.

Real acceptance: stock dsh-TUI, parent request on the official route, /model switch to an independent gateway, then one unpinned child. Durable logs show the parent on official → work-gw and the child on work-gw only, followed by a real child tool execution. No screen-text inference is involved.

Reproduction and evidence:
https://github.com/weijiafu14/pi2dsh/tree/main/examples/subagents
https://github.com/weijiafu14/pi2dsh/blob/main/community/subagents-acceptance-report.md