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

[Jamonygr]

I would separate the parent model from the subagent runtime here.

If #runSubagent is being handled by the GitHub Copilot agent host, the delegated subagent may still be executed by Copilot's supported model/runtime path, even when the parent request is using a Microsoft Foundry model through the Foundry Toolkit. In that case the Azure Foundry model is acting as the parent/orchestrator, but the subagent invocation is not necessarily routed back through the same Foundry provider.

A practical way to verify it is to check the Copilot/Foundry Toolkit logs for the actual endpoint and model used during the subagent call. If the extension does not expose a separate provider/model setting for subagents, it is probably a current product limitation rather than a configuration issue.

As a workaround, keep the Foundry model call explicit through a script, MCP/tool call, or your own task endpoint, and let Copilot orchestrate only the parts that do not require that specific Azure model.