feat: add model parameter to Task tool for dynamic subagent model selection

[albahrani]

Issue for this PR

Closes #6651

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Adds an optional model parameter to the Task tool so callers can specify which model a subagent runs on at invocation time, instead of relying solely on static agent config or parent session fallback.

The resolution order becomes: params.model > agent.model > parent session model. Existing behavior is unchanged when the parameter is omitted.

This is needed for orchestrator workflows (e.g. gsd-opencode) where different subagents should use different model tiers based on their role, determined dynamically at call time.

How did you verify your code works?

Built from source on Windows, replaced the installed binary, and tested three scenarios:

Test	model param	Agent frontmatter	Expected	Actual
Dynamic override to Haiku	github-copilot/claude-haiku-4.5	(none)	Haiku	Haiku
Dynamic override to Sonnet	github-copilot/claude-sonnet-4.6	(none)	Sonnet	Sonnet
No param, no frontmatter	(none)	(none)	Opus (parent)	Opus

Verified by spawning subagents and checking the model ID in their system prompt.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found the following potentially related PRs:

Related PRs:

1. PR feat(agent): implement model tier selection with variant support for subagents #11377 - feat(agent): implement model tier selection with variant support for subagents

   • feat(agent): implement model tier selection with variant support for subagents #11377
   • This PR also addresses dynamic model selection for subagents, which is closely related to the current PR's goal of allowing different subagents to use different model tiers.

2. PR feat(task): pass variant to subagent so it inherits parent's thinking level #12567 - feat(task): pass variant to subagent so it inherits parent's thinking level

   • feat(task): pass variant to subagent so it inherits parent's thinking level #12567
   • This PR deals with passing configuration parameters to subagents, which is similar in scope to passing the model parameter.

3. PR feat: add variant support for subagents (#7138) [alt of #7140] #7156 - feat: add variant support for subagents (#7138) [alt of #7140]

   • feat: add variant support for subagents (#7138) [alt of #7140] #7156
   • This PR also addresses passing parameters/variants to subagents for dynamic behavior.

These PRs appear to be related efforts in enabling dynamic subagent configuration. You may want to review them to ensure there's no overlap in implementation or to see if this PR should be coordinated with existing variant/model selection mechanisms.

[albahrani]

Thanks for flagging the related PRs. Here's how this one fits in:

• feat(agent): implement model tier selection with variant support for subagents #11377 (model tiers) — Adds model_tier enum (quick/standard/advanced) with configurable tier-to-model mappings. Our PR adds the lower-level raw model parameter. These are complementary — tiers are a user-friendly abstraction, the raw parameter covers cases where the caller already knows the exact model ID (e.g. orchestrator frameworks that resolve models from their own config).

• feat(task): pass variant to subagent so it inherits parent's thinking level #12567 (variant inheritance) — Passes the parent's thinking variant to subagents. Orthogonal to model selection — variant controls reasoning depth, model controls which LLM runs. No overlap.

• feat: add variant support for subagents (#7138) [alt of #7140] #7156 (static agent variant) — Adds a variant field to agent config. Also orthogonal — deals with variants, not model selection.

This PR is intentionally minimal (9 lines, 2 files) to provide the foundational mechanism. It doesn't conflict with any of the above and could serve as a building block for #11377's tier resolution.