Feature Request
Problem
Custom agents (.agent.md) can specify a model: in their own frontmatter, and parent agents can invoke subagents via runSubagent. However, there is no way for a parent agent to override the subagent's model at invocation time. The runSubagent tool accepts prompt, description, and agentName — but no model parameter.
This means that if an orchestrator agent wants to run the same subagent with different models at different stages of a workflow, the only options are:
- Duplicate the agent file with a different
model: in frontmatter (e.g., qa-investigator.agent.md + qa-investigator-gpt5.agent.md with identical bodies)
- Ask the user to manually switch models in the picker between stages
Neither is ideal. Option 1 creates maintenance burden (two identical agent bodies to keep in sync). Option 2 breaks automation flow and requires human intervention mid-workflow.
Use Case: Cross-Model QA Validation
I maintain a multi-agent fix workflow with three custom agents:
- fix-planner — researches and plans the fix
- fix-issue — orchestrates the full lifecycle (plan → implement → QA → PR)
- qa-investigator — read-only edge-case reviewer, invoked as a subagent by fix-issue
The QA phase runs iterative review cycles until the qa-investigator finds zero issues. A significant quality improvement comes from cross-model validation: after the QA loop passes clean with one model (e.g., Claude Opus), re-running the same QA agent with a different model (e.g., GPT-5.4) catches a different class of issues because different models have different blind spots.
Today I have to either duplicate the QA agent file with a hardcoded model, or pause the workflow and ask the user to switch models in the picker. With a model parameter on runSubagent, the orchestrator could do this automatically:
// Pseudocode of desired behavior
runSubagent({ agentName: "qa-investigator", prompt: "...", model: "Claude Opus 4" })
// ... iterate until clean ...
runSubagent({ agentName: "qa-investigator", prompt: "...", model: "GPT-5.4" })
// ... iterate until clean ...
Proposed Solution
Add an optional model parameter to the runSubagent tool that overrides the subagent's frontmatter model (or the inherited picker model) for that single invocation:
runSubagent({
agentName: string,
prompt: string,
description: string,
model?: string // Optional: override the subagent's model for this invocation
})Semantics:
- If
model is provided, use it for this invocation regardless of the subagent's frontmatter or the user's picker selection
- If
model is omitted, current behavior is preserved (subagent uses its frontmatter model, or inherits the picker model)
- The model override applies only to the subagent invocation, not to the parent agent
Alternative Solutions
- Workspace setting mapping agent names to models — less flexible, can't change per-invocation
- A
model-override frontmatter field — static, doesn't solve the "same agent, different models at different stages" problem
- Duplicating agent files with different models — current workaround, works but creates maintenance burden
Prior Art
- #281978 requested per-agent
model: in frontmatter (now supported). This request goes one step further: per-invocation model override.
- GitHub Copilot CLI already supports specifying a model when invoking subagents, allowing orchestrator agents to route different workflow stages to different models without duplicating agent definitions or requiring user intervention.
- Claude Code CLI's
Task tool similarly supports model: as an invocation parameter for subagents.
- The
chat.exploreAgent.defaultModel setting (#297184) shows per-agent model routing is already implemented internally for built-in agents.
The capability exists in both the Copilot CLI and Claude Code CLI — this request is about bringing the same per-invocation model override to the VS Code Copilot Chat extension's runSubagent tool.
Environment
- VS Code Insiders 2026-04-02
- GitHub Copilot Chat 0.43.x
- OS: macOS
Feature Request
Problem
Custom agents (
.agent.md) can specify amodel:in their own frontmatter, and parent agents can invoke subagents viarunSubagent. However, there is no way for a parent agent to override the subagent's model at invocation time. TherunSubagenttool acceptsprompt,description, andagentName— but nomodelparameter.This means that if an orchestrator agent wants to run the same subagent with different models at different stages of a workflow, the only options are:
model:in frontmatter (e.g.,qa-investigator.agent.md+qa-investigator-gpt5.agent.mdwith identical bodies)Neither is ideal. Option 1 creates maintenance burden (two identical agent bodies to keep in sync). Option 2 breaks automation flow and requires human intervention mid-workflow.
Use Case: Cross-Model QA Validation
I maintain a multi-agent fix workflow with three custom agents:
The QA phase runs iterative review cycles until the qa-investigator finds zero issues. A significant quality improvement comes from cross-model validation: after the QA loop passes clean with one model (e.g., Claude Opus), re-running the same QA agent with a different model (e.g., GPT-5.4) catches a different class of issues because different models have different blind spots.
Today I have to either duplicate the QA agent file with a hardcoded model, or pause the workflow and ask the user to switch models in the picker. With a
modelparameter onrunSubagent, the orchestrator could do this automatically:Proposed Solution
Add an optional
modelparameter to therunSubagenttool that overrides the subagent's frontmattermodel(or the inherited picker model) for that single invocation:Semantics:
modelis provided, use it for this invocation regardless of the subagent's frontmatter or the user's picker selectionmodelis omitted, current behavior is preserved (subagent uses its frontmatter model, or inherits the picker model)Alternative Solutions
model-overridefrontmatter field — static, doesn't solve the "same agent, different models at different stages" problemPrior Art
model:in frontmatter (now supported). This request goes one step further: per-invocation model override.Tasktool similarly supportsmodel:as an invocation parameter for subagents.chat.exploreAgent.defaultModelsetting (#297184) shows per-agent model routing is already implemented internally for built-in agents.The capability exists in both the Copilot CLI and Claude Code CLI — this request is about bringing the same per-invocation model override to the VS Code Copilot Chat extension's
runSubagenttool.Environment