Microsoft AI Updates: November 6, 2026

1. Foundry Local Tunes Qwen3.8-27B for On-Device Agentic Coding and Plugs It Into GitHub Copilot Through BYOK

Microsoft detailed a Foundry Local inference pipeline optimized for Qwen3.8-27B, which it calls its primary target for local coding and which requires Foundry Local CLI 0.13.0 or later, and showed how to use it as the model behind GitHub Copilot through bring-your-own-key (BYOK). The ONNX Runtime-based stack applies DFlash2 speculative decoding with a lightweight drafter model, CUDA graph fusions and kernels tuned for NVIDIA’s SM121 architecture, plus INT4 weights, KV-cache quantization, embedding memory sharing, CPU offloading, prefix caching and continuous batching. At 4 bits the model is about 18 GB and runs on 24 GB consumer GPUs with up to 64K tokens of context, while GPUs with 32 GB or more can use up to the model’s 262K-token maximum. Microsoft cites published Qwen3.8-27B scores 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, and says that against llama.cpp with the same 4-bit model on an RTX 5090 (32 GB) and a DGX Spark (128 GB unified memory), Foundry Local generated faster at every tested prompt length on a dataset of real GitHub issues, with the gap widening beyond 131K tokens; the post gives the comparison only as charts. Setup is winget install Microsoft.FoundryLocal, foundry model load qwen3.8-27b and foundry server status, then adding Foundry Local as a model provider with that endpoint in the GitHub Copilot app; CUDA and cuDNN must be installed separately. The optimized path targets NVIDIA GPUs for now, with Macs and AMD GPUs planned, and Microsoft notes that local models may reason less well than cloud models on complex tasks. Source

2. Microsoft Foundry Extension for the Azure Developer CLI Reaches 1.0 With Hosted Agent Deploys and Local Testing

Microsoft made the Microsoft Foundry extension bundle (microsoft.foundry) for the Azure Developer CLI generally available at version 1.0, requiring azd 1.37.0 or later. Agent and deployment configuration lives in azure.yaml next to the code; the sample declares a gpt-5.4-mini Global Standard deployment and a Python 3.13 hosted agent with 0.5 CPU and 1 GiB of memory, and teams can eject editable Bicep or Terraform. azd ai agent init scaffolds from a template, azd provision creates resources including missing model deployments, azd ai agent run starts the agent locally with the Agent Inspector, azd deploy uploads source for a remote build with no local container build, and azd deploy --preview, azd ai agent monitor --follow and azd ai agent doctor cover change review, log streaming and diagnostics. A separate Evaluations extension (azure.ai.evaluations) generates test datasets and grading rubrics (azd ai eval generate) and runs evaluations that azd ai agent optimize can reuse as a baseline, and azd pipeline config sets up GitHub Actions or Azure DevOps pipelines that can gate on evaluation thresholds. Microsoft also points coding agents such as GitHub Copilot and Claude Code to a Microsoft Foundry Skill for project scaffolding. Source

3. Copilot Usage Metrics API Adds a Code Review “Addressed Rate” and Flags Users Missing Telemetry

GitHub added a copilot_code_review object to every row of the enterprise and organization repository-level 1-day usage reports. total_comments_evaluated and total_comments_addressed count Copilot code review comments and those developers acted on, whether by applying the suggestion, asking Copilot to fix it, editing the code or replying that the fix will come later, giving a per-repository addressed rate; both are broken down by severity, review tier (lite, balanced, max), comment type (bug, security, custom guidelines) and customization (custom instructions, skills, MCP servers or none). total_merged_no_human_change_request_after_review counts merged pull requests where no person requested changes after Copilot’s first review. Comments are evaluated and counted on the merge day, and comments on bot-opened pull requests, such as those from Copilot cloud agent, are usually not evaluated. A second update adds per-user client_telemetry_present and usage_metrics_requirements (each IDE and Copilot extension marked met, unmet or unknown against minimum versions) plus daily missing_client_telemetry_user_count and below_usage_metrics_minimum_user_count totals, since users without client telemetry still count as active but lack lines-of-code, feature and model breakdowns; GitHub warns against adding the two counts together or summing them across days, and earlier days have no values. Both require the View Copilot Metrics permission and the Copilot usage metrics policy. Source Source

4. Microsoft Pushes Default-On Usage-Based Billing for New Microsoft 365 Copilot Business CSP Purchases to January to March 2027

Microsoft revised the timeline for turning on usage-based billing by default for new Microsoft 365 Copilot Business purchases through the Cloud Solution Provider (CSP) program, including standalone offers and bundles. An editor’s note dated November 5 on the partner blog post that accompanied the September Copilot relaunch says rollout is now planned to begin during Microsoft’s fiscal 2027 third quarter (January to March 2027), replacing the previously announced December 1, 2026 date, and points to a Partner Center announcement for details. Under the commercial model announced in September, per-user subscriptions cover everyday Copilot use while usage-based billing covers frontier models and long-running agentic work in Cowork, Code and Autopilot; Microsoft lists Copilot Cowork, Work IQ APIs and the GitHub Copilot Harness in Copilot Studio among the experiences that default-on billing makes easier to activate. Source

5. Microsoft Research’s PDD Kit Uses Verus Proofs to Hold Coding Agents to an Approved Spec

Microsoft Research, with GitHub Next and the Research in Software Engineering group, described PDD Kit, a research prototype for what it calls proof-driven development: a coding agent turns a developer’s intent into a formal specification in Verus, a proof language for Rust, writes the implementation and its proof, and falls back to labeled tests where a proof cannot reach. It runs inside Chopin, GitHub Next’s multiplayer planning environment, through three workflows: pdd-plan asks clarifying questions and builds a plain-language intent artifact, pdd-prove builds a task graph in which a coding agent writes code and proofs, Verus checks them and an LLM verifier looks for requirements with neither a proof nor a passing check, and pdd-ship adds the Verus check to CI and prunes tests that only re-check proved behavior. To catch specs that verify but constrain nothing, which the authors call “vibe verification,” two reviewer agents critique the spec and a mutation check plants one bug per ensures clause that Verus must reject. On Pet Store, a roughly 5,000-line Rust web app (Axum, SQLite and a Leptos WebAssembly storefront), a two-sentence login requirement became eight ensures clauses on a new login_flow function; six trusted pieces, including the database lookups, bcrypt verification, token signing and the clock, were explicitly accepted by the developer and covered by tests, and the authors say Verus uncovered existing bugs. PDD Kit verifies only Rust, the guarantees are only as strong as the trusted wrappers, and the post does not say whether or when it will be released. Source

6. Microsoft Finds 15 Agent Problems in Five Passing Dev Proxy Runs by Reading Trajectories

Microsoft’s Waldek Mastykarz reported that when GitHub Copilot Chat with Claude Sonnet 5.5 and no extensions was asked five times to write a CI script that uses the Dev Proxy API to record which GitHub APIs a Node.js tool calls, all five scripts worked, but the trajectories showed 15 problems, with each run taking 29 to 39 requests and up to 1.2 million tokens. Four runs first fetched a guessed documentation URL that returned 404 (eight 404 fetches across four runs), one run tried pem, crt, cer and der because an error message did not list valid formats, all five read the plugin DLL as raw bytes to find class names because no command lists plugins, and four polled the output folder for up to 30 seconds because report completion is not signaled. Search snippets indexed before v3.3.1 showed API calls without the now-required token, and because the --as-system-proxy help text reads like an opt-in, three runs never noticed that Dev Proxy reroutes all of the machine’s traffic by default, while the LLM judge wrongly failed the one run that turned it off. The post recommends fixing product behavior, help text and docs before shipping an agent skill, and points to the ATIF Preview extension for viewing trajectories in VS Code. Source

7. Microsoft Defender’s Discovery of Local AI Agents and Their MCP Configurations Is Generally Available on Windows and macOS

Microsoft said in its November Microsoft Security roundup that Microsoft Defender’s discovery of supported local AI agents and their configured Model Context Protocol (MCP) servers is now generally available on Windows and macOS endpoints. Defender identifies more than 50 supported local AI agents by observing their activity and brings together the agent, device, account and configured MCP context, so security teams can see which local agents run in their environment and what they are connected to. The roundup does not list the supported agents or give pricing or licensing details. The same post restates that Microsoft Execution Containers, the operating system-enforced containment layer for local agents, is generally available, with Intune, Entra and Agent 365 integration still described as upcoming, and describes Dynamic Permissions, which scopes an agent’s authority to its current task while Dynamic Agent Risk and Dynamic Conditional Access narrow access or require human approval as risk changes. Source