Subagents inherit the parent's creation-time model seed instead of its live route, delegation silently runs on for exmaple openrouter/auto after the default model is switched

[JanTuck]

Summary

When the configured default model is changed (e.g. from Auto Router (openrouter/auto) to a concrete model like stealth/ox-alpha), sessions that were created — or merely resumed — under the old default keep spawning subagents that still route on the old model. The main chat visibly runs the new model, while every delegated child silently answers via the router, which fans out to arbitrary upstream models.

The cause looks like a split-brain between two per-session "model" values: the request route (what the chat actually sends on) and the agent seed options (stamped at create/resume time). Subagent delegation reads the latter.

Environment

• DeepSeek Harness desktop packaging, @deepseek-ai/dsh 0.1.1-rc.2 (dsh-subagent, dsh-host-apiproxy, dsh-agent-default-model all 0.1.1-rc.2)
• Linux x64 (Fedora, kernel 7.1.9), Web GUI at 127.0.0.1:3081
• Provider: openrouter; default model was at some point set to openrouter/auto ("Auto Router"), later switched to stealth/ox-alpha

Evidence

From session logs (.dsh/sessions/...):

Parent session — requests actually running Ox Alpha:

{"type":"request/header","data":{"header":{"config":{"provider":"openrouter","model":"stealth/ox-alpha"}}}}

…yet every child it spawned around that time carried the stale seed:

{"type":"subagent/descriptor","data":{"version":2,"mode":"continuable","provider":"spawn","label":"Add serverbound play interaction packets","agentProvider":"openrouter","agentModel":"openrouter/auto"}}

and the children's own request/header events confirm they really called openrouter/auto.

Root cause walkthrough

1. Web layer seeds options once per create/resume. In dsh-host-apiproxy/src/api-proxy.ts:

   /** The seed model each create/resume declares; re-read so it never goes stale. */
   const agentOptions = () => {
       const { provider, model } = defaults.defaultModelSelection();
       return { provider, model };
   };

   "Never goes stale" only holds across create/resume calls. A session left open across a default change keeps the old seed.

2. Per-session selection is separate and doesn't touch options. selectionFor() resolves the request route as: in-process UI pick → latest logged request/header → live agent-default-model. Switching models in the UI (or changing the default) updates what the chat sends on — but never rewrites agent.options.

3. Delegation reads the raw seed. In packages/subagent/subagent/src/child-agent.ts:

   export function resolveChildAgentOptions(parent, requested, childDepth): AgentOptions {
     const parentProvider = parent.options.provider
     const parentModel = parent.options.model        // ← stale creation-time seed
     ...

   The continuable descriptor snapshot in SubagentRuntime.startContinuable duplicates the same read:

   const agentProvider = request.agentOptions?.provider ?? parent.options.provider;
   const agentModel = request.agentOptions?.model ?? parent.options.model;

So a session seeded while the default was openrouter/auto keeps delegating children on openrouter/auto indefinitely, even while the parent itself runs a concrete model. The same applies to any long-lived session after any default change — the drift is just most visible (and most costly) with a router model, where you don't control which upstream model answers.

Proposed fix

Make delegation follow the parent's live route, falling back to the seed only before the first request exists. The folded request header is already the exact source selectionFor() uses for sessions without an in-process pick:

/**
 * The parent's LIVE route: the request route its session actually last ran on,
 * falling back to creation-time seed options before the first request.
 */
function parentLiveRoute(parent: Agent) {
  const logged = parent.session?.requestHeader?.()?.config
  return {
    provider: logged?.provider ?? parent.options?.provider,
    model: logged?.model ?? parent.options?.model,
  }
}

export function resolveChildAgentOptions(parent, requested, childDepth): AgentOptions {
  const route = parentLiveRoute(parent)
  return {
    ...route.provider !== undefined ? { provider: route.provider } : {},
    ...route.model !== undefined ? { model: route.model } : {},
    ...parent.options.maxTokens !== undefined ? { maxTokens: parent.options.maxTokens } : {},
    ...requested,                       // explicit per-child overrides still win
    subagentDepth: childDepth,
  }
}

…and use the same helper for the descriptor snapshot in startContinuable (both the bundled copy and types/child-agent.ts).

I've been running exactly this patch locally (verified: stale-seed parent with live Ox Alpha route → child gets stealth/ox-alpha; blank parent → falls back to seed; per-child override → respected). Happy to open a PR if you tell me which repo/branch to target and whether you'd prefer this shape or a different one.

Alternative directions

• Re-seed agent.options when a session's effective selection changes (keeps inheritance semantics but makes the web layer own the sync), or
• Expose the installed per-session selection on the Agent context so the subagent runtime can query it directly instead of folding the log.

Workarounds (until fixed)

• Re-open/resume affected sessions after changing the default model (resume re-declares fresh seed options), and/or
• Explicitly pick the desired model in each session's model picker before delegating.

One caveat users should know: since selectionFor() prefers the latest logged request over the live default, resuming does not reset what an existing session sends on — only what future subagents inherit. Both surfaces have to be checked when chasing "why is my subagent on a different model".

[duoartisan]

We hit this on 0.1.1-rc.2 as well (Web GUI dsh web, llm-pi-ai adapter, Windows), using two providers that share the same logical model under different ids. Independent confirmation of the report:

• The parent session ran 100% of its requests on provider bitdeer (deepseek-ai/DeepSeek-V4-Flash), and the parent log contains zero references to the stale provider.
• All 43 subagents spawned by 6 workflow runs (in-process spawn, one-shot mode) ran on the stale route opencode-go / deepseek-v4-flash, and at least one child exhausted that provider's weekly quota (429 GoUsageLimitError, "Weekly usage limit reached") — so the drift is consequential, not cosmetic.

Representative child request/header while the parent's own concurrent requests were bitdeer:

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

Two small observations that may matter for the fix:

1. Our one-shot spawn descriptor ({"version":2,"mode":"one-shot","provider":"spawn"}) does not carry agentProvider/agentModel like the continuable descriptor in the report — yet the misroute is identical. So the load-bearing fix is resolveChildAgentOptions reading the live route; the descriptor only needs mirroring where it stores the pair. And remember the function exists in two copies (dsh-subagent/lib/index.js bundled + lib/types/child-agent.js) — both must change.
2. Contributing hazard in our setup: provider A serves the namespaced id deepseek-ai/DeepSeek-V4-Flash while another route (opencode-go) owns the bare id deepseek-v4-flash. We suspect the creation-time seed carried the bare id (the id shared by the base default and that route), which is what made the stale seed land on a specific unintended provider. A warning whenever a request is routed on a bare model id across providers — as suggested in the report — would have surfaced this immediately.

The proposed direction (delegation follows the parent's live route — the folded requestHeader — with fallback to the seed only before the first request) matches exactly what we'd expect. We also confirmed the workaround end-to-end: opening a fresh session after switching the default re-stamps the seed, so parent and children agree again (with the report's caveat that merely resuming an existing session does not reset its request route — only what future children inherit).

Happy to share sanitized session excerpts or help test the patch against the pi-ai multi-provider adapter.

[weijiafu14]

This stale-seed case now has a verified alternative path through the Pi plugin ecosystem. It does not patch DSH native subagents; pi2dsh lets stock @tintinweb/pi-subagents create native DSH child sessions:

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

For an unpinned child, route precedence is: explicit Pi child model → the caller session's last durable real request/header route → creation-time options only as fallback. Provider and model travel as one pair.

The acceptance test uses stock dsh-TUI and real model calls: the parent first runs on deepseek-official, /model switches it to an independent work-gw, and then it spawns an unpinned child. Assertions read the durable parent/child JSONL rather than UI text: parent routes are official → work-gw; child routes contain only work-gw; the child also executes a real tool and lands a marker. This specifically falsifies the creation-time-seed failure shape described here.

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