Foundry Local Brings Qwen Coding to 24GB GPUs, with Limits to Test

Microsoft's November 5 announcement brings Qwen3.8-27B coding to Foundry Local with a minimum requirement of a 24GB NVIDIA GPU. The company says the 4-bit weights occupy approximately 18GB. The announced integration uses ONNX Runtime and connects to Copilot through bring-your-own-key configuration.

That gives eligible developers a specific local deployment path to test. It does not establish that a workstation completes useful coding work more cheaply than a hosted alternative. Memory fit is an admission requirement; accepted repository changes are the outcome that matters.

Microsoft also specifies Foundry Local CLI 0.13.0 or later. Mac and AMD support are roadmap items, not shipped options in this announcement. Buyers should evaluate the supported configuration rather than treating an intended platform expansion as a current purchasing option.

The Memory Floor Is Not the Complete Runtime Budget

Approximately 18GB of weights and a 24GB GPU requirement describe different things. The former concerns the model representation; the latter describes the hardware entry point. A buyer should measure the actual process during the target coding workload instead of treating the weight figure as the complete memory requirement.

Context capacity also changes with hardware. Microsoft lists 64K context on 24GB GPUs and up to 262K on configurations with 32GB or more. The larger figure should not be copied into a workstation specification that only meets the smaller memory threshold.

A local evaluation needs to record which files and instructions actually entered the context. A nominal capacity does not establish that every relevant part of a repository will be included or used correctly. Keep the hardware configuration attached to each result so that a successful run on a larger machine does not become an unsupported promise about a smaller one.

Benchmark Scores Describe Particular Evaluations

Microsoft reports Terminal Bench 2.1 at 73.0, SWE-bench Pro at 61.7, NL2Repo at 42.3 and DeepSWE 1.1 at 42.2. Those are vendor-reported benchmark results. They provide reasons to test the model, but they are not observations of performance on your repository.

Keep the benchmark names and versions beside their scores. Combining them into a generic coding-quality number would remove the task boundaries that make the results interpretable. A terminal-task result cannot establish an expected acceptance rate for a particular team's code review process.

For an internal evaluation, define completion before running the agent. An edit that compiles may still fail the requested behavior, and an apparently correct patch may require substantial reviewer work. Those are measurement categories to include, not claims that this model has a particular defect. Preserve rejected patches as well as accepted ones so that the review does not become a collection of favorable demonstrations.

Local Inference Moves Costs Instead of Erasing Them

The announcement does not supply a measured cost per accepted change for your environment. Running inference on owned hardware does not by itself answer that question. Hardware availability and time spent recovering from unsuccessful tasks belong in the comparison alongside the work that passes review.

Avoid manufacturing a financial result from the memory specification. The 24GB requirement says nothing about an organization's acquisition terms or developer time. Use actual local observations and your own accounting inputs if a business case requires money figures, keeping those inputs separate from Microsoft's published claims.

Privacy requires a similar separation. A model executing locally is not proof that every component in the surrounding development workflow avoids network traffic. The announced Copilot BYOK connection should be tested in the intended setup, including telemetry behavior, before an organization promises that all information remains offline.

Deployment Evidence Must Match the Supported Configuration

Foundry Local CLI 0.13.0 or later is part of the stated requirement, not a detail to leave out of the evaluation record. Record the runtime and integration configuration together with the machine. A result without those details is harder to reproduce when another developer attempts the same task.

Roadmap language deserves its own boundary. A team that uses Mac or AMD machines cannot count future support as a present solution to its fleet constraints. It can evaluate the announced NVIDIA path separately while leaving the unshipped platform decision open.

The same discipline applies to context. Compare the workflow at the context setting your hardware supports, then document where missing information affected task completion. That can distinguish a deployment configuration problem from a broader capability question without asserting that either explanation has already been established. Local operation is useful evidence only when the configuration is visible.

What To Do About It

• Inventory eligible machines: Confirm the GPU vendor and available memory before scheduling a local pilot; Microsoft's stated entry point is NVIDIA with 24GB.
• Pin the supported runtime: Record the exact installed version and integration settings in the pilot notes, starting with Foundry Local CLI 0.13.0.
• Match context to hardware: Run repository tasks at the context setting the intended machine supports rather than borrowing results from a larger setup with 32GB.
• Inspect the full workflow: Capture network behavior and reviewer decisions before claiming offline privacy or lower cost, including the connection through Copilot BYOK.

The Bottom Line

Foundry Local makes Qwen3.8-27B a concrete coding option for developers with eligible NVIDIA hardware. The 24GB floor tells a buyer where testing can begin, not what each accepted change will cost. Keep the vendor benchmarks attributed, test the surrounding network behavior and measure completed work on the configuration you intend to use. Roadmap support should remain outside today's deployment promise.