Allow runSubagent tool to specify a language model

[digitarald]

Problem

When the LLM invokes the runSubagent built-in tool, the subagent always inherits the parent agent's model (or the custom agent's configured model). There is no way for the LLM to explicitly choose a different model for a subagent invocation, even when the user asks for it (e.g. "use Claude to research this").

Why:

• Multi-model consensus-based review, multiple models running in different subagents; has a growing fanbase
• Picking a faster model for quick research tasks

Proposal

Add an optional model parameter to the runSubagent tool schema that accepts a qualified model name in "Model Name (Vendor)" format. The schema should dynamically enumerate available agent-mode-suitable models so the LLM knows which values are valid.

Model resolution priority

1. Explicit model parameter — if provided and resolved
2. Agent-configured model — from the custom agent's .agent.md file
3. Main model — the model running the parent agent

[Dhakra92]

The settings from 'agent.md' are also not always evaluated correctly. There seems to be a bug here too! In over 50% of cases, the "parent model" always seems to be used, regardless of what is in the subagents. It also seems to depend somewhat on the "parent modal"; Opus seems to be able to spawn the subagent cleanly more often than, for example, Sonnet or GPT5.3-Codex.

"name: SubArchitect"
"model: Claude Opus 4.6 (copilot)"

[aeschli]

The agent currently has no list of known, valid models. Also, having such a list, how would it make a selection?
What if it picks the most expensive 30x model?

[Dhakra92]

Unfortunately, I don't understand your point. What exactly do you mean? You can define one model or, in the latest version, even several models. The agent doesn't need to "decide" what to take, but only needs to adhere to the specifications in "*.agent.md."

https://code.visualstudio.com/docs/copilot/agents/subagents

[aeschli]

@Dhakra92 I was responding to the original request which is about adding a model parameter to the runSubagent tool. That model would override model in the subagent's *.agent.md.
I was wonding how the called of tool would know about models as we don't provide a list of currently valid models

[heguro]

@Dhakra92

The settings from 'agent.md' are also not always evaluated correctly

Slightly off-topic, but this is likely not a bug, see #295053 (comment) . Subagents silently fall back to the parent's model when they would be more expensive.
(Personally, I'd like to see this relaxed, even if it means consuming extra requests to cover the cost.)