Skip to content

fix: inherit parent instance's active model in subagents#210

Open
ravshansbox wants to merge 1 commit into
nicobailon:mainfrom
ravshansbox:fix/inherit-active-model-in-subagents
Open

fix: inherit parent instance's active model in subagents#210
ravshansbox wants to merge 1 commit into
nicobailon:mainfrom
ravshansbox:fix/inherit-active-model-in-subagents

Conversation

@ravshansbox
Copy link
Copy Markdown

Fixes #209

Problem

When multiple Pi instances run simultaneously with different models, subagents always fall back to settings.json (shared on disk). Whichever instance last changed its model wins — not the instance that spawned the subagent.

The parent's active model (ctx.model?.fullId) was available but only used for provider disambiguation, never forwarded to the child.

Fix

Add ctx.model?.fullId as a final fallback in all four resolveModelCandidate call sites (single, async single, parallel, chain) in subagent-executor.ts:

// Before
resolveModelCandidate(task.model ?? agentConfig.model, availableModels, currentProvider)

// After
resolveModelCandidate(task.model ?? agentConfig.model ?? ctx.model?.fullId, availableModels, currentProvider)

Priority order after fix

  1. Explicit model in subagent call params
  2. model: in agent frontmatter
  3. Current instance's active model ← new
  4. Nothing → child reads settings.json

Since ctx.model?.fullId is already fully qualified (e.g. anthropic/claude-sonnet-4), it passes through resolveModelCandidate unchanged via the existing model.includes("/") early return.

Testing

Pre-existing test suite: 415 pass, 9 fail — identical before and after (failures are due to missing peer dependency in test environment, unrelated to this change).

When a subagent has no explicit model set (either via params or agent
frontmatter), the spawned child pi process receives no --model flag and
falls back to reading settings.json. This means whichever pi instance
last wrote to settings.json determines the model, not the instance that
spawned the subagent.

Fix by passing ctx.model?.fullId as a final fallback in all four
resolveModelCandidate call sites (single, async single, parallel, chain).
The fully-qualified model id (e.g. anthropic/claude-sonnet-4) passes
through resolveModelCandidate unchanged since it already contains a
provider prefix.

Priority is now:
1. Explicit model in subagent call params
2. model: field in agent frontmatter
3. Current instance's active model (ctx.model?.fullId)
4. Nothing → child pi reads settings.json
@nicobailon nicobailon added bug Something isn't working ready-for-human Needs human implementation or product/design judgment priority: high Important user-facing bug or high-value maintenance item labels May 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working priority: high Important user-facing bug or high-value maintenance item ready-for-human Needs human implementation or product/design judgment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Subagents use wrong model when multiple Pi instances are running

2 participants