Bug: Subagents inherit the parent session's creation-time model snapshot instead of the model the session actually uses

[zhujiang611]

Bug Report: Subagents inherit the parent session's creation-time model snapshot instead of the model the session actually uses

Status: Needs maintainer confirmation (behavior contradicts documented intent)
Severity: Medium — functional inconsistency, no crash
Affected packages: @deepseek-ai/dsh-subagent (0.1.0-rc.6), @deepseek-ai/dsh-host-apiproxy (0.1.0-rc.6), @deepseek-ai/dsh-agent-loop (0.1.0-rc.6), @deepseek-ai/dsh-session (0.1.0-rc.6)
Environment: dsh 0.1.0-rc.6, hybrid deployment — DeepSeek official API + local llama.cpp models (reproduced via the dsh web session.* API)
Date: 2026-08-15
Labels: bug / subagent / model-selection / inheritance

Summary

After switching the model of a session via the web UI, subagents spawned from that session still run on the model that was the global default when the session was created, instead of the model the parent session is actually using. Switching a model updates both the in-session selection and the global default (settings.yaml), but the subagent inheritance logic reads a one-time creation snapshot (parent.options) that is never updated, so the two diverge.

Steps to reproduce

1. Prerequisite: global default model is deepseek-official / deepseek-v4-flash (agent-default-model in settings.yaml).
2. Create a new session S (its creation snapshot is therefore deepseek-v4-flash).
3. In the browser UI, switch session S to a local model local-aeonb / 27B-AEON-Q5 (invokes session.selectModel).
4. Confirm S is now actually talking to the local model (works as expected).
5. Spawn a subagent from S via the subagent tool.
6. Observed: the subagent session's request/header event carries config.provider = "deepseek-official", config.model = "deepseek-v4-flash", maxTokens = 256000 (DeepSeek official provider defaults), not the local model's local-aeonb / 27B-AEON-Q5 / 65536.

Expected behavior

The subagent should inherit the model the parent session is currently using (local-aeonb / 27B-AEON-Q5), because:

• resolveChildAgentOptions's own doc comment states the child "inherits the parent's provider/model route";
• DSH's model-selection machinery treats the session request header as the authoritative source of the session's current model.

Actual behavior

The subagent uses the model snapshot taken when the parent session was created, even though the parent switched models afterwards and has been running on the new model.

Observed evidence

Scenario	Global default at parent creation	Parent actually uses (after switch)	Subagent request header
Old session (created while default = deepseek)	deepseek-v4-flash	local-aeonb (switched manually)	deepseek-v4-flash ❌
New session (created while default = local-aeonb)	local-aeonb	local-aeonb	local-aeonb ✅

Two-way reproduction via the dsh web session.* API (2026-08-15)

Reproduction A (creation = local → switch to flash → subagent still local)

Step	Action	Result
1	Create a new session (global default = local-aeonb)	Session session-020f3838, default model = local-aeonb
2	session.selectModel to deepseek-v4-flash	Parent request header = deepseek-official / deepseek-v4-flash / 256000 (switch took effect)
3	Spawn a subagent from the parent (session.prompt)	Subagent request header = local-aeonb / 27B-AEON-Q5 / 65536 ❌ does not follow the switch

Reproduction B (creation = flash → switch to local → subagent still flash; the original user scenario)

Step	Action	Result
1	Set global default to flash, create a new session	Session session-f4284b40, default model = deepseek-v4-flash
2	session.selectModel to local-aeonb	Parent request header = local-aeonb / 27B-AEON-Q5 / 65536 (switch took effect)
3	Spawn a subagent from the parent (session.prompt)	Subagent request header = deepseek-official / deepseek-v4-flash / 256000 ❌ does not follow the switch

Side-effect observed: every session.selectModel call also writes the selected model into agent-default-model in settings.yaml (switching a model changes the global default); settings.yaml changed in real time during reproduction and was restored to local-aeonb afterwards.

Root cause

1. Subagent inheritance source: a static creation snapshot

@deepseek-ai/dsh-subagent/lib/index.js:501-512

function resolveChildAgentOptions(parent, requested, childDepth) {
    const parentProvider = parent.options.provider;  // set once at creation, never updated
    const parentModel = parent.options.model;
    const parentMaxTokens = parent.options.maxTokens;
    return {
        ...parentProvider !== void 0 ? { provider: parentProvider } : {},
        ...parentModel !== void 0 ? { model: parentModel } : {},
        ...parentMaxTokens !== void 0 ? { maxTokens: parentMaxTokens } : {},
        ...requested,
        subagentDepth: childDepth
    };
}

parent.options is assigned once in the Agent constructor (@deepseek-ai/dsh-agent-loop/lib/index.js:354: this.options = options) and no code updates it afterwards.

2. What the creation snapshot contains: the global default at that moment

@deepseek-ai/dsh-host-apiproxy/lib/index.js:1708-1714

const agentOptions = () => {
    const { provider, model } = defaults.defaultModelSelection();  // reads agent-default-model from settings.yaml
    return { provider, model };
};

(invoked on session create/resume, lines 2164 and 2152).

3. Switching a model updates two things, but never parent.options

@deepseek-ai/dsh-host-apiproxy/lib/index.js:2694-2706 (session.selectModel)

selectionFor(found.agent).current = selected;          // ① in-memory selection for this session
await defaults.saveDefaultModelSelection?.(selected);  // ② global default (writes settings.yaml)
// parent.options is NOT updated

4. Documented intent contradicts the implementation

selectionFor in @deepseek-ai/dsh-host-apiproxy/lib/index.js:1741-1750 documents the intended precedence:

"Precedence, resolved on EVERY read rather than seeded once: a selection made in this process, else the session's own latest logged request/header, else the live Agent default."

i.e. the design philosophy is dynamic-first: the authoritative source of a session's current model is its latest request header (parent.session.requestHeader()?.config). But resolveChildAgentOptions reads the static parent.options instead, so the same codebase maintains two inconsistent notions of "current model":

• parent session request header: local-aeonb / 27B-AEON-Q5 (the model actually in use)
• subagent inheritance source: parent.options = creation snapshot = deepseek-v4-flash

Impact

• Subagents spawned after a model switch do not follow the new model; behavior diverges from what the UI shows.
• Especially visible in multi-model / multi-provider setups (session A on a local model, session B on the official API — subagents may all fall back to the creation-time default).
• Users must create a new session to get subagents on the desired model, which is confusing (this report comes from real user feedback).
• The fact that selectModel also overwrites the global default amplifies the confusion: after a switch, new sessions follow the switched model while subagents still follow the old snapshot.

Real-world consequences in hybrid deployments (official API + local models)

This report comes from a hybrid deployment (DeepSeek official API coexisting with local llama.cpp models). In this scenario the bug causes:

1. Hidden API billing: local models are free; the official API is metered. When a subagent wrongly inherits the creation-time official default, users believe the subagent runs locally while every subagent request actually hits the official API (measured subagent request header: deepseek-official / deepseek-v4-flash / maxTokens 256000), incurring unexpected cost. In the reported usage, large batches of subagent tasks (e.g. multi-chapter novel generation) all consumed official quota.
2. Content-behavior divergence (moderation differences): local models (e.g. uncensored fine-tunes) and the official API apply different moderation/filtering policies. Content the parent (local, permissive) can produce may be refused, rewritten, or endlessly retried by the subagent (official, moderated), splitting output style and usability within one task. Real user feedback: "the subagent is a moderated model; the same model in OpenCode can generate it" — caused by this bug.
3. Subagent connection failures: if the local model is not running (e.g. the user stopped the service to free VRAM) while a subagent wrongly inherits the local snapshot, every subagent request fails to connect; conversely if the subagent inherits the official default while the user is offline it also fails. In hybrid deployments the "is the model online" state and the "model the subagent actually picked" are misaligned, making failures hard to diagnose.
4. Default-model drift amplifies cost: because selectModel writes the global default on every switch, combined with the subagent snapshot mismatch, new sessions and subagents can end up on different lines (local vs official) as the user switches between sessions; cost and behavior become unpredictable and cannot be corrected intuitively from the UI (a new session is required).

Suggested fix

Option A (recommended): prefer the parent's actually-used model, fall back to the creation snapshot

Modify resolveChildAgentOptions (@deepseek-ai/dsh-subagent/lib/index.js:501-512).

⚠️ Important: an earlier draft used parent.options.provider ?? logged?.provider, which does NOT fix this bug

?? only falls back when parent.options is empty, but the bug scenario is precisely when parent.options holds a stale value (e.g. flash), so ?? always resolves to the stale value. The request header (actually-used model) must take precedence, with the snapshot as fallback — not the other way around:

function resolveChildAgentOptions(parent, requested, childDepth) {
    // The model the parent session actually uses (authoritative): latest request header
    const logged = parent.session.requestHeader()?.config;
    // Follow the actual usage; only fall back to the creation snapshot when the
    // session has never issued a request (no request header yet)
    const parentProvider = logged?.provider ?? parent.options.provider;
    const parentModel = logged?.model ?? parent.options.model;
    const parentMaxTokens = logged?.maxTokens ?? parent.options.maxTokens;
    return {
        ...parentProvider !== void 0 ? { provider: parentProvider } : {},
        ...parentModel !== void 0 ? { model: parentModel } : {},
        ...parentMaxTokens !== void 0 ? { maxTokens: parentMaxTokens } : {},
        ...requested,
        subagentDepth: childDepth
    };
}

Key points:

• logged (request header) takes precedence: after the parent switches models and actually uses the new one, subagents follow the switched model;
• parent.options (creation snapshot) only serves as a fallback when the session has never issued a request;
• maxTokens follows the request header too, avoiding mismatches (e.g. flash 256000 vs local 65536);
• parent.session.requestHeader() is a public API of @deepseek-ai/dsh-session (Session.requestHeader()); parent is an Agent (with .session), so it is directly usable;
• ...requested is still spread last, so explicit provider/model overrides from the caller keep their precedence.

Option B (alternative): update parent.options inside selectModel

In session.selectModel (dsh-host-apiproxy/lib/index.js:2701), besides updating selectionFor(...).current and the global default, also update found.agent.options.provider/model/maxTokens.

Note: options.provider/model is also read by system-prompt variables (dsh-agent-loop/lib/index.js:1001-1002: ctx.systemPrompt.variable("provider"/"model")); updating it will also change the model name in the system prompt (likely desired), but making options mutable conflicts with the "creation snapshot" semantics and other paths reading parent.options need evaluation.

Verification after the fix

Re-run both API reproductions above (Reproduction A / B); after the fix the expected results are reversed:

• Reproduction A (created local → switched flash → spawn subagent): subagent = flash ✅ (was local ❌ before)
• Reproduction B (created flash → switched local → spawn subagent): subagent = local ✅ (was flash ❌ before)

Notes

• Findings based on source reading plus real-environment testing (subagent request/header events as direct evidence).
• Measured subagent request headers: {"provider": "deepseek-official", "model": "deepseek-v4-flash", "maxTokens": 256000} (old-session spawn) vs {"provider": "local-aeonb", "model": "27B-AEON-Q5", "maxTokens": 65536} (new-session spawn).
• If maintainers consider this behavior intentional (e.g. deliberately pinning subagents to the parent's birth identity), please close with a rationale; otherwise Option A is suggested.
• We kindly ask maintainers to reproduce and fix this precisely: this report provides complete reproduction steps, two-way API reproduction data, and a precise fix suggestion. Because provider/model setups differ across deployments (this report is based on DeepSeek official API + local llama.cpp hybrid deployment), we suggest maintainers run the two-way reproduction in their official test environment following the "Steps to reproduce" and "Verification after the fix" sections, confirm the root cause, and land Option A or a more appropriate implementation. If the reproduction differs from this report, feedback with additional information is welcome.

[zhujiang611]

Additional evidence: same root cause reported independently by other users

This bug has been hit independently by at least three users in the community, all pointing to the same mechanism:

1. Discussion 子代理BUG #117 (localhosts-A): with a third-party API, subagent calls fail with llm-deepseek: no API key for provider route "deepseek-official" — the subagent falls back to the creation-time default route (deepseek-official) instead of following the session's actual provider.
2. Discussion 子代理BUG #117 (DRAG0NM): already located the root cause independently — "父代理创建时 agentOptions 固化为默认模型选择，子代理继承的只是 parent.options（创建时默认路由），因此会话内切到第三方 provider 时，子代理仍按默认路由" — matching the analysis in this report.
3. Discussion 子代理BUG #117 (GaaHoi): session running deepseek-v4-flash, but the 9 subagents spawned by the workflow tool all ran deepseek-v4-pro — another instance of the creation-time snapshot not following the session's actual model.

This confirms the report is not an edge case: in any multi-provider deployment, subagents can silently run on a different (and possibly metered) model than the parent session actually uses. Please consider fixing per Option A (request-header precedence) or an equivalent approach.

Related: #117

[yha9806]

I reproduced this against current master 47f9438 and prepared a tested patch:

• Branch: https://github.com/yha9806/deepseek-harness/tree/codex/fix-subagent-live-route
• Commit: yha9806@f302da9

The patch gives the latest logged Session request/header precedence for provider and model, with parent.options as the fallback before the first parent request. Explicit child agentOptions still have final precedence.

One important refinement to the suggested Option A is maxTokens ownership. If request/header marks maxTokens through adapterDefaults.maxTokens, copying that value into child AgentOptions promotes a route-specific adapter default into an explicit cap. The patch therefore inherits an explicit effective maxTokens but omits an adapter-owned default so the selected child adapter can materialize its own value.

Continuable creation resolves the child configuration once before its first await. Initial materialization and the durable descriptor receive provider/model from the same value, so cold resume cannot drift back to the creation-time route if the parent changes later.

Verification completed:

• real one-shot in-process route-switch regression plus adapter-default ownership regression
• continuable initial execution, durable descriptor, and cold-resume regression
• keyless assembled headless snapshot using the switched parent route
• 59 related test files and 1121 tests passed
• exact coverage for child-agent.ts and continuation.ts: 100 percent statements, branches, functions, and lines
• 28 documentation gates passed; full lint, typecheck, and pre-push typecheck passed

[zhujiang611]

@yha9806 Excellent work — thank you for reproducing and landing this fix! 🎉

I reviewed your patch (f302da9) and it matches the intended design in the report precisely:

• Latest request/header precedence with parent.options as pre-first-request fallback ✅
• maxTokens refinement is a genuinely important catch: promoting an adapter-owned default into an explicit child option would freeze the old route's output budget. Omission so the child adapter rematerializes its own default is the right call.
• Continuable cold-resume consistency (one resolution feeding both initial creation and the durable descriptor) closes a gap the report did not cover — nice addition.

The two new regression tests (route-switch inheritance + cold-resume snapshot) cover exactly the failure modes from the two-way reproduction in the report.

Hoping the maintainers pick this up for the next release. 🙏

[zhujiang611]

Real-world production incident confirming Impact #3 (connection failures)

A production incident occurred today on the same hybrid deployment (Feishu/Lark channel → DSH → local llama.cpp):

• The Feishu session was running on the local model local-aeonb / 27B-AEON-Q5 (port 8004).
• The local model service had been stopped the previous evening (to free VRAM); nothing restarted it.
• Turn 56 of the session failed with: {"message":"Connection error.","code":"TRANSPORT"} — the session froze at that point.

Root cause chain: agent-default-model points at the local AEON Q5 (8004) → service down → every model call from the channel fails with an opaque TRANSPORT error → the session stalls with no actionable message.

This is exactly Impact #3 from the report, with two aggravating factors this bug contributes:

1. No escape hatch without the fix: with the creation-snapshot inheritance, even if the user switches the parent session to a working model (e.g. the official API), any subagent spawned afterwards still inherits the dead local route (parent.options snapshot) and keeps failing — the user cannot route around the outage from the UI. The proposed Option A (request-header precedence) gives a working escape path: switch the parent → subagents follow.
2. Opaque failure surface: TRANSPORT says nothing about "the local model service is not running", making diagnosis slow in hybrid deployments where the model backend is a separate process the user controls.

Also relevant beyond this bug: pointing the deployment-wide default (agent-default-model) at a local model service that can be stopped independently makes the whole channel a single point of failure. Consider documenting this operational risk (default to an always-on route, switch to local models per-session via /model use).

[zhujiang611]

Correction to my previous comment — clarifying the relationship precisely

My earlier comment ("Real-world production incident confirming Impact #3") was imprecise. To be accurate:

The incident itself is NOT caused by this bug. The Feishu session was directly calling the local model service (local-aeonb, port 8004) which had been stopped — any call to an offline backend fails with a transport error ({"message":"Connection error.","code":"TRANSPORT"}) regardless of subagent inheritance. That part is expected behavior for an offline service, and no inheritance change affects it.

What this bug does add (the accurate scope): with creation-snapshot inheritance, after the parent escapes to a working route (e.g. switching to the official API), any subagent spawned still inherits the dead local route from parent.options and keeps failing — the outage silently extends to subagents even after the parent has moved on. Option A (request-header precedence) gives the clean escape path: switch the parent → subagents follow.

Separate operational note (not this bug): pointing agent-default-model at a locally-hosted model service that can be stopped independently makes every channel a single point of failure. Consider defaulting to an always-on route and switching to local models per-session (/model use).