Microsoft said in a Microsoft Foundry Blog post on 5 November 2026 that Foundry Local can run Qwen3.8-27B on developer machines and connect it to GitHub Copilot through Bring Your Own Key. The change gives teams a local option for coding-agent work when repository context should not leave the device, connectivity is unavailable or cloud inference cost is a concern.
What Microsoft changed
Foundry Local is the on-device runtime used here for model inference. In this update, Microsoft has optimised Qwen3.8-27B for local agentic coding and shows how to route GitHub Copilot requests to a local Foundry Local endpoint through Bring Your Own Key, or BYOK.
Qwen3.8-27B is Microsoft’s primary optimisation target for this scenario. With 4-bit quantisation, the model size can be reduced to approximately 18 GB, which Microsoft says allows it to run well on consumer GPUs with 24 GB or more of VRAM.
Microsoft lists published benchmark scores for Qwen3.8-27B of 73.0 on Terminal Bench 2.1, 61.7 on SWE-bench Pro, 42.3 on NL2Repo-Bench and 42.2 on DeepSWE 1.1. Those benchmarks cover agentic terminal tasks, software engineering, repository-level code generation and agentic coding.
Runtime optimisation
The local serving stack uses ONNX Runtime and is tuned for NVIDIA GPUs. Microsoft says the optimisation work covers prefill, decoding, memory management, long-context processing and concurrent requests.
The decoding path uses DFlash2 speculative decoding, which uses a smaller drafter model to predict multiple tokens at once. The stack also uses CUDA graph fusions and kernel optimisations tuned for the NVIDIA SM121 GPU architecture.
Memory work includes INT4 weight handling, KV-cache quantisation, embedding memory sharing and CPU offloading. Prefix caching reuses previously computed context, while continuous batching is used to handle concurrent workloads.
Hardware and setup constraints
The documented setup requires an NVIDIA GPU with at least 24 GB of VRAM and Foundry Local CLI 0.13.0 or later. For NVIDIA GPU execution, developers must install the required CUDA and compatible cuDNN runtimes separately, because Foundry Local does not download those dependencies.
The setup flow installs the Foundry Local CLI with WinGet, loads the qwen3.8-27b model and retrieves the local API endpoint from Foundry Local. In the GitHub Copilot app, the developer adds Foundry Local as a model provider, enters that endpoint as the Base URL, adds Qwen3.8-27B from the catalogue and selects it in the model picker.
Microsoft did not announce separate pricing for this setup. The cost argument is framed around running inference on local hardware rather than depending only on cloud-hosted model calls.
Performance and limits
In Microsoft’s comparison with llama.cpp, both systems used the 4-bit Qwen3.8-27B model and a dataset of real GitHub issues. The test systems were an NVIDIA GeForce RTX 5090 with 32 GB of VRAM and an NVIDIA DGX Spark with 128 GB of unified memory.
Microsoft says Foundry Local delivered higher generation speed at every tested prompt length. The advantage widened beyond 131K tokens, which is the range Microsoft highlights for repository-scale coding work.
Microsoft also states that local models may have limited reasoning capability compared with larger cloud models because of their smaller size. It describes local models as suitable for everyday coding and targeted subtasks, while cloud models remain a choice for complex, high-reasoning tasks.
What remains open
Microsoft plans to expand Qwen3.8-27B support to more devices, including Macs and AMD GPUs. It also plans to add more coding-optimised local models and deepen the integration between Foundry Local and GitHub Copilot.
No date was given for Mac or AMD GPU support. Teams evaluating the feature now should treat the initial path as NVIDIA-focused and check the Foundry Local CLI version, GPU memory and runtime dependencies before testing it against real repositories.
Deciding when a repository can be sent to a cloud coding model, when it must stay local and what model quality is acceptable is the agentic AI trade-off ECS's Core AI topic deals with, alongside Azure AI Foundry, the EU AI Act and responsible AI. Sessions and workshops give attendees product context and practitioner experience on model selection, local and cloud execution, and controls around agents. Bring the coding-agent scenarios where privacy, hardware and model capability are still unsettled.
This article was written by the ECS editorial team with the assistance of Amal Agent, run.events' AI assistant, which supported the research, drafting and proofreading.