Microsoft Foundry models seems to call GitHub copilot subagent instead of Azure model.

[jasonrichdarmawan]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Models

Body

Hi, I am using GitHub Copilot extension on VS Code, and uses Microsoft Foundry models via Foundry Toolkit. The problem is when the model uses #runSubagent, the model actually use GitHub Copilot models.

Is there a way to use #runSubagent with Microsoft Foundry models via Foundry Toolkit?

[P-r-e-m-i-u-m]

This is expected behavior right now, though I get why it's frustrating. Here's what's happening:

When you use Microsoft Foundry models through the Foundry Toolkit, the main chat/completion calls do go to your Azure Foundry endpoint. However, #runSubagent is a Copilot-specific feature — it's handled by GitHub's orchestration layer, not by the model provider itself.

So what happens is:

1. Main request → goes to your Foundry/Azure model ✅
2. Sub-agent tasks (#runSubagent) → get routed through GitHub's Copilot infrastructure, which uses GitHub's own model backend ❌

This is because #runSubagent relies on GitHub's built-in agent framework (the tool-use orchestration, context windowing, parallel task execution) — it's not a raw model call that can simply be forwarded to an external endpoint.

Is there a workaround?

Not really at the moment, unfortunately. The sub-agent is tightly coupled to Copilot's internal pipeline. A couple of things you can do:

1. File a feature request on the GitHub Copilot feedback board — specifically requesting that #runSubagent respect the user's configured model provider. This is a legit use case.

2. Avoid #runSubagent for now if you need everything to stay on Foundry. Instead, break down tasks manually into separate prompts that go directly to your model.

3. Check the Foundry Toolkit settings — there might be updates coming that allow agent-level model selection. The Foundry Toolkit is relatively new so this may change.

Refs:

• GitHub Copilot in VS Code
• Using Copilot Chat

[addy0328p]

No, not directly — and this is a known architectural limitation.

Why it happens

#runSubagent is a GitHub Copilot-native tool. When it spins up a subagent, it uses Copilot's own model routing internally — it doesn't inherit or forward your active Foundry model selection. So even if your main chat session is using a Foundry model, subagents fall back to GitHub Copilot's default models automatically.
What you CAN do right now
The GitHub Copilot SDK's orchestration capabilities can be combined with Foundry Local's on-device inference using a BYOK (Bring Your Own Key) pattern — a single configuration object redirects the entire GitHub Copilot SDK to use on-device inference through Foundry. However, this requires building your own agent outside the #runSubagent abstraction, not through the VS Code chat UI shortcut. Microsoft Community Hub
Foundry Toolkit for VS Code (now GA) lets you create agents from templates or with GitHub Copilot, test and debug locally with full trace visualization, and deploy to Foundry Agent Service — but this is a separate agent execution path from Copilot's built-in #runSubagent. Microsoft
Practical workarounds

Avoid #runSubagent for Foundry workflows — instead use Foundry Toolkit's own agent runner in VS Code, which stays fully within the Foundry model context.
Use BYOK pattern via GitHub Copilot SDK — configure your agent programmatically to point subagent calls at your Foundry endpoint. See → Agentic Code Fixing with GitHub Copilot SDK + Foundry
File a feature request — this gap (Foundry model inheritance in #runSubagent) doesn't appear to have an official fix yet. Worth raising at → github.com/microsoft/vscode