Across my conversations with leaders in government, critical infrastructure and regulated industries, one priority consistently rises to the top: putting technology to work on their most important systems while maintaining the control those systems require.

This challenge is becoming more important as advanced cloud and AI capabilities move into public services, regulated processes and essential operations. Organizations are considering more than where data resides. They also seek to understand who can access and operate their systems, how sensitive digital assets remain protected, which technology dependencies matter most and whether critical services can continue as regulatory, geopolitical, security or network conditions change. Digital sovereignty should give organizations greater control and security over the technology they depend on, while continuing to innovate.

Last year, we introduced Microsoft Sovereign Cloud to give customers more choice in how they address these requirements. Since then, we have continued to turn our commitments into practical capabilities across public cloud and customer-operated environments, while expanding how we enable partners to address sovereignty requirements in their local markets. Today, we are sharing the next stage of that work.

A continuum of control, built around the workload

Our approach to digital sovereignty starts with the workload. Each workload carries different requirements for data, operations, technology dependencies, continuity and risk. Microsoft Sovereign Cloud is designed to make it easier for organizations to apply the appropriate level of control to each workload without forcing every application into the same deployment model.

Those needs can vary widely across organizations. A public-facing digital service may benefit from the scale and pace of innovation in the public cloud. A system supporting essential operations may need to continue running locally if connectivity is disrupted. An AI workload handling highly sensitive data may require models, data and processing to remain within a customer-controlled environment.

Microsoft Sovereign Cloud is designed around this workload-based approach, providing a continuum of management, control and options across Sovereign Public Cloud, Sovereign Private Cloud and the Sovereign Partner Ecosystem. Organizations can apply the level of control appropriate to each workload while maintaining a consistent approach to governance and operations across their digital estate. Sovereign Public Cloud adds capabilities for workloads that require greater control and transparency while continuing to benefit from the scale and innovation of Azure.

Sovereign Private Cloud extends cloud capabilities into customer-operated environments, including connected and disconnected operations. The Sovereign Partner Ecosystem broadens the continuum through independently operated environments, specialized partners, locally relevant expertise and technologies that support customers’ sovereignty requirements.

These are not isolated destinations. Customers can combine public cloud, private cloud and partner capabilities across their digital estate, applying different levels of control to different workloads as their operating needs evolve.

Making control more visible in Sovereign Public Cloud

For many workloads, the public cloud provides a combination of scale, innovation, integrated security and compliance. Organizations can benefit from these capabilities while applying additional sovereignty controls for residency, confidentiality, operator access, policy and continuity. Our work in Sovereign Public Cloud makes these controls easier to understand, apply and demonstrate.

Sovereign Control Panel, entering public preview at Microsoft Ignite, brings these signals together in a unified Azure portal experience. It helps organizations understand their sovereignty posture, apply and manage controls, identify gaps and risks and take action to address them. It also supports business continuity readiness by helping customers understand workload dependencies and assess portability across operating environments when required.

This visibility complements controls across the operator-access lifecycle. Just-in-time Access and Customer Lockbox give customers additional control over access to their environments. For customers in the European Union (EU) and the European Free Trade Association (EFTA), we are rolling out Data Guardian, which adds European-resident oversight by a trusted EU partner for qualifying Microsoft engineer remote access to in-scope production systems. Production Touch Ledger, also launched with phased rollout in the EU and EFTA, creates tamper-evident records of that access and the actions performed.

Azure Key Vault Managed Hardware Security Module (HSM) already gives customers dedicated, single-tenant protection and control over the encryption keys used by supported Azure services. Last year, we committed to extending that control beyond Microsoft infrastructure. External key management with Azure Managed HSM is now generally available, allowing customers to keep the root encryption key in hardware they own and operate on-premises or through a trusted third party. This gives organizations another option for workloads that require physical control of key hardware outside Microsoft infrastructure.

Azure confidential computing helps protect supported data while it is processed in a hardware-based and attested trusted execution environment. We are also increasing transparency into the technologies that underpin that trust. Azure Confidential Clean Rooms, now in limited preview, applies confidential computing to approved multiparty collaboration, allowing participants to analyze shared sensitive data while limiting broader exposure of the underlying information.

Together, these capabilities provide additional technical and operational controls that can support a broader digital sovereignty strategy aligned to an organization’s legal, policy, security, resilience and business requirements.

Designing for resilience and operational independence

For some workloads, digital sovereignty also means maintaining critical operations as connectivity, geopolitical and operating conditions change. Resilience must be designed from the start so essential workloads can continue operating through disruption.

To help customers prepare for these scenarios, we are publishing new sovereign business continuity guidance and architecture patterns. These resources help organizations translate resilience requirements into architectures they can plan, implement and test before they are needed.

For many workloads, the scale and geographic reach of the public cloud provide a strong foundation for resilience across locations and operating conditions. For workloads that require greater operational independence, Sovereign Private Cloud extends that continuum into customer-operated environments. It supports connected and disconnected operating models. The ability to transition workloads from connected to disconnected operations is entering public preview, giving organizations greater flexibility to sustain critical services as connectivity and operating requirements change.

Bringing more of the application lifecycle under local control

Operational independence requires more than infrastructure. Increasingly, organizations need data, development tools, model capabilities and productivity services their applications depend on to operate within the same customer-controlled environment.

Sovereign Private Cloud, built on Azure Local, extends Microsoft cloud capabilities into environments that customers operate and control. SQL Server on Azure Local is already generally available for connected and disconnected deployments. DocumentDB and Blob Storage on Azure Local are both entering public preview, giving organizations more choice in how they run and manage critical data within customer-controlled environments.

GitHub Enterprise Local will become generally available at Microsoft Ignite as a validated GitHub Enterprise Server appliance on Azure Local, helping organizations keep repositories, code and development artifacts under local control. Developers can also use GitHub Copilot with locally hosted models for inference, bringing AI-assisted development closer to their code and data within the environments they control.

The local application environment is expanding with Foundry Local. At Ignite, Foundry Local will become generally available for connected and disconnected operations on Azure Local, with an expanded model catalog that includes Microsoft, partner, open-weight and open-source models. Local inference and agentic retrieval will also enable users to interact with local enterprise data using natural language and receive responses grounded in that data. Integration with Microsoft 365 Local, available in preview for approved customers, extends this functionality to locally operated Microsoft SharePoint and Exchange servers.

Confidential virtual machines on Azure Local are generally available, extending confidential computing capabilities to customer-controlled infrastructure. Hardware-encrypted memory and hardware-based isolation help protect sensitive data while it is being processed. Workload attestation adds assurance before sensitive data or keys are released. For regulated, sensitive and mission-critical workloads, these safeguards provide another layer of protection while giving organizations greater control over where their data and applications run.

Azure Local will support multitenancy, allowing organizations to separate resources, governance and management across multiple tenants while sharing the underlying infrastructure. This significantly expands what customers with distinct business units or security boundaries can achieve with Sovereign Private Cloud. Multitenancy also creates new opportunities for local operators and service providers to deliver differentiated sovereign cloud services on Azure Local infrastructure.

These additions bring more of the application lifecycle under local control, spanning data, development, productivity, AI and operations. Organizations can determine what runs locally based on the requirements of each workload.

Extending the continuum through partners

Navigating sovereignty is increasingly complex. Regulatory, security, operational and business requirements vary across countries, industries and workloads. Organizations must translate these needs into technology and operating models that work in their local context. Meeting these needs often requires a combination of technology, local operating authority, sector expertise and specialized solutions.

The Sovereign Partner Ecosystem broadens the ways customers can address these requirements. National Partner Clouds, including Bleu in France, provide independently operated environments for customers that require a different ownership and operating model. Software partners can enhance Azure Local environments with capabilities across security, identity, observability, backup and recovery, migration, data, networking and applications. Digital sovereignty specialized partners combine Microsoft technologies with local knowledge and implementation expertise. Platform co-innovation partners expand infrastructure choice from datacenter to the edge.

This ecosystem gives customers the flexibility to combine technology, operating models and trusted expertise based on the requirements of each workload.

The next chapter of digital sovereignty

AI is amplifying both the opportunity and the impact of technology choices. As AI systems and agents interact with sensitive data, business processes and essential infrastructure, they also expand the security considerations organizations need to manage. Organizations need clear control over where these systems run, who can operate them, what actions they can take and how critical services continue when conditions change.

Microsoft Sovereign Cloud brings these choices together as a continuum of control across the public cloud, customer-operated environments and our partner ecosystem. It gives organizations the flexibility to apply the appropriate level of control to each workload while continuing to benefit from cloud capabilities and ongoing innovation.

We will continue to expand this continuum so organizations can innovate with cloud and AI while maintaining the control, confidentiality, resilience and operational authority their most important workloads require.

Douglas Phillips leads global engineering efforts for Microsoft’s specialized, sovereign and private clouds. He is responsible for Microsoft’s global strategy, products and operations that bring Microsoft’s industry-leading solutions, including Azure, our adaptive cloud portfolio and Microsoft 365 collaboration suite, to customers with additional sovereignty, security, edge and compliance requirements.

Learn more

• Microsoft Sovereign Cloud
• Sovereign Landing Zone architecture guidance
• Sovereign Public Cloud Tech Community blog
• Sovereign Private Cloud Tech Community blog

The post Advancing digital sovereignty with greater control and choice appeared first on The Official Microsoft Blog.

Recorded at OpenAI Dev Day 2026, Ryan sits down with Andrew Ambrosino, member of the technical staff at OpenAI, for a conversation on OpenAI's strategy for merging ChatGPT and Codex into a unified experience, the advantages of localized computer access in their successful desktop application, and the technical hurdles of constructing ChatGPT Spaces to support real-time multi-agent collaboration.

 

Auto-labeling policies are how most organizations label the backlog of files at rest, and with the tenant ceiling now up to 500,000 files a day, more teams run them at scale. When a policy doesn't label what you expect, the cause is almost always a missing prerequisite, simulation behavior or the label-precedence rules. I've put the field fixes in one place: run the checklist, find your symptoms, apply the fix. Scope: SharePoint and OneDrive, with Exchange differences called out.

How service-side auto-labeling works

Auto-labeling policies run in the service, not in Office apps. A policy (label + rules + scope) must complete at least one simulation; once it's on, SharePoint and OneDrive label matching files at rest, up to the tenant's daily maximum.

 

                                                         Figure 1. Service-side auto-labeling lifecycle and where to look when it stalls

Pre-flight checklist

Missing any one of these typically makes a policy run without labeling anything, and without an error.

Limits that matter (October 2026)

 Also rolling out: editing an active policy without returning to simulation, Site Template filtering, detected-SIT summaries and a 30-day files-processed chart (MC1469958), the per-policy coverage report (MC1456609), and library default labels for existing files (MC1477181). If your tenant still shows the older values, the rollout hasn't reached it yet.

Symptom-to-fix triage

Reading Labeling Failure Codes

PowerShell toolkit

Error “Failed to create job. Please close the current PowerShell session and open a new session using Connect-IPPSSession with the -EnableSearchOnlySession flag. This requires using ExchangeOnlineManagement v3.9.0 or higher.” (it may appear only after a timeout) means this case.

Before you open a support case

Open it promptly, because diagnostic data is retained only for a limited time. Include:

 Good to know - Auto-labeling doesn't change existing Modified, Modified By or date values, in simulation or when labels are applied.

Learn more

• Automatically apply a sensitivity label to Microsoft 365 data — https://learn.microsoft.com/en-us/purview/apply-sensitivity-label-automatically
• Resolve auto-labeling failures in SharePoint and OneDrive files — https://learn.microsoft.com/en-us/troubleshoot/microsoft-365/purview/sensitivity-labels/auto-labeling-failures-sharepoint-onedrive
• Review simulation results for auto-labeling policies — https://learn.microsoft.com/en-us/purview/auto-label-simulation-results
• Use the Insights tab to analyze auto-labeling policies — https://learn.microsoft.com/en-us/purview/auto-label-insights-tab
• Enable sensitivity labels for files in SharePoint and OneDrive — https://learn.microsoft.com/en-us/purview/sensitivity-labels-sharepoint-onedrive-files
• Configure a default sensitivity label for a SharePoint document library — https://learn.microsoft.com/en-us/purview/sensitivity-labels-sharepoint-default-label
• Set-AutoSensitivityLabelPolicy — https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-autosensitivitylabelpolicy

This week's Model Mondays edition highlights three Hugging Face models newly available in Microsoft Foundry, giving developers more open-weight options for enterprise coding and agentic work: Meta's Muse Spark Open, NVIDIA's Nemotron 3.5 Super VL, and Reflection's Beam 1.0.

Models of the week

Meta: Muse-Spark-Open-816B-A42B-NVFP4

Model Specs

• Parameters / size: 816B total / 42B active; Mixture of Experts, which activates a subset of parameters for each token; NVIDIA's 4-bit floating-point format (NVFP4).
• Context length: 1,048,576 tokens in the Foundry deployment.
• Primary task: Multimodal reasoning, multi-step reasoning, coding, and agentic task completion.

 

Why it's interesting

• Published agent and coding evaluations: Meta reports scores of 89.2 on MCP-Atlas, which evaluates tool use through the Model Context Protocol (MCP), and 76.4 on Terminal-Bench 2.1, using the Terminus 2 agent. These are Muse Spark Open results at xhigh reasoning effort; the benchmark table does not identify them as NVFP4-specific measurements.
• Adjust reasoning effort to the task: The model supports planning, sequential tool calls, and recovery from tool failures. Its reasoning_effort setting offers low, medium, high, and xhigh; Meta recommends the higher settings for complex coding and agentic work. See the model card.
• Bring visual and conversational evidence into the same workflow: Muse Spark is natively multimodal. It can interpret screenshots, documents, and recordings alongside text. For developers building a product support agent, that opens up end-to-end agentic task completion.

 

Hardware and deployment configuration:

Muse Spark's NVFP4 deployment on Azure Foundry has a 1M-context deployment template on NVIDIA H200, intended for long-context reasoning, coding, agentic tasks, and multimodal workloads. Eight GPUs jointly serve one model instance, with both the model tensors and its experts distributed across them.

 

 

This preset retains the model's full native context window, allowing prompts, media, tool results, and generated output to share a single extended context.

 

NVIDIA: NVIDIA-Nemotron-3.5-Super-VL-120B-A12B-BF16

Model Specs

• Parameters / size: 120B total / 12B active; hybrid MoE architecture; Brain Floating Point 16 (BF16) weights.
• Context length: Up to 1M tokens natively; 524,288 tokens in the current Foundry deployment presets.
• Primary task: Vision-language reasoning, document and video understanding, coding, and tool use; text, image, and video input, with text output.

 

Why it's interesting

• Visual understanding alongside reasoning. A vision encoder connects images and video frames to a language backbone combining Mamba-2 state-space layers, attention, and sparse experts. Developers can use the model to interpret document layouts, charts, and application screens in the same workflow as textual instructions.
• Reasoning that can be switched on or off. The model supports configurable thinking, giving applications a way to distinguish straightforward extraction from questions that require several reasoning steps.
• Document and chart evaluation results. NVIDIA reports 62.82 on MMLongBench-Doc, 65.08 on OCR-Reasoning (optical character recognition with reasoning), and 80.82 on CharXiv reasoning, which tests understanding of scientific charts. These are publisher-reported results for the BF16 model; see the benchmark table and evaluation methodology.

 

Hardware and deployment configurations:

Nemotron's BF16 deployment on Azure Foundry is available on NVIDIA A100 and H100 templates, both configured for 512K context. Each uses four GPUs per model instance. The main configuration difference is the attention cache, which stores information from earlier tokens: the A100 preset retains BF16 precision, while the H100 preset uses 8-bit floating point (FP8) to reduce cache memory.

 

 

Choose A100 for cache precision; choose H100 for response speed. The template descriptions position H100 as the faster option for generation and long-prompt processing, using a lower-precision cache while keeping the model weights in BF16. Both presets offer the same context window and active sequence cap, so this choice is about cache precision and performance rather than additional context capacity.

Both templates enable tool calling, reasoning, and reuse of cached prompt prefixes. They accept text plus up to one image and one video per prompt; video sampling is configured at two frames per second, with a maximum of 256 sampled frames. Both also enable speculative decoding with three proposed tokens per step, using the model's ability to predict multiple upcoming tokens to accelerate generation.

Reflection: Beam-1.0-501B-A23B

Model Specs

• Parameters / size: 501.3B total / 23.4B active; sparse MoE; available with BF16, FP8, and NVFP4 weights.
• Context length: 1,048,576 tokens natively; 524,288 tokens in the Foundry BF16 preset and 262,144 tokens in the FP8 and NVFP4 presets.
• Primary task: Text generation for software engineering, reasoning, and agentic tool use; developed predominantly for English.

 

Why it's interesting

• Built around software engineering workflows. Beam is designed to work with repositories, terminal environments, and tools across extended tasks. Its text-only interface fits coding agent workflows.
• Reasoning efficiency is an explicit training objective. Reflection describes training with a length penalty that discourages unnecessary generated tokens while rewarding successful solutions. Its launch post explains the trade-off between reasoning effort and task performance.
• BF16 coding and tool-use results. The release model card reports 81.6% on SWE-bench Verified, 80.1% on Terminal Bench v2.1, and 80.8% on MCP Atlas for BF16. These cover repository issue resolution, terminal tasks, and tool use respectively.

 

Hardware and deployment configurations:

The same Beam model is available in three weight precisions: BF16, FP8, and NVFP4. All retain the same parameter count and text, reasoning, and tool-calling capabilities. The lower-precision releases reduce the memory needed for weights, opening up A100 and H100 deployment options.

 

 

All five templates use an FP8 attention cache, support tool calling with automatic tool selection and reasoning, enable reuse of cached prompt prefixes and processing long prompts in chunks, and set a 90-second request timeout.

Getting started

You can deploy these Hugging Face models in Microsoft Foundry by browsing the Hugging Face collection in the Foundry model catalog and selecting a managed endpoint deployment.

• Read Hugging Face on Azure docs
• Explore models in Microsoft Foundry

 

The most powerful moments in a presentation are when you and your audience can explore an idea together.

We're continuing to expand how PowerPoint helps you turn ideas, data, and institutional knowledge into compelling narratives with interactive slides so you can communicate ideas more effectively, with slides you can explore.

Bring your ideas to life with interactive storytelling 

With the create interactive slide skill, Copilot generates interactive slides from a simple prompt or existing content. Whether you're highlighting insights from a dashboard, explaining a business process, walking through a timeline, or comparing options, interactive slides help make information accessible and more memorable. 

Now, presenters and audiences are invited to explore content and uncover insights and engage with visuals that make concepts easier to understand. 

What can you create?

Presentations often contain information-dense slides that can overwhelm audiences. Interactive slides help presenters reveal information progressively, guide attention to key takeaways, and create a more engaging experience.

By combining Copilot's content intelligence with interactive visual storytelling, presenters can communicate ideas more clearly while spending less time building complex experiences from scratch.

Interactive slides are ideal for:

• Creating a dashboard based on a snapshot of your data including grounding from Work IQ
• Creating interactive timelines and process flows
• Summarizing or explaining complex concepts through visual exploration
• Comparing products, scenarios, or strategies

Try it out

Getting started is simple. Select Interactive Slide from the PowerPoint ribbon and describe the slide you want to create. You can reference the content in the presentation or from other files and context like an Excel workbook or a Word document. 

 

You can also access Create interactive slide from the Skills picker in Copilot alongside other PowerPoint skills.

 

Availability

The Create interactive slide skill and ribbon button are rolling out now.

• Rollout is underway for PowerPoint for Windows and Mac for Current Channel and Monthly Enterprise Channel and is expected to complete by end of October 2026. 
• Rollout is underway for PowerPoint for the web and is expected to complete by end of October 2026. 

 

Learn more about the skill including latest updates at https://support.microsoft.com/en-us/powerpoint/copilot/create-interactive-slides-with-copilot-in-powerpoint

And to learn more about other Copilot skills in PowerPoint that help users create, refine, and deliver compelling presentations faster.

https://support.microsoft.com/en-us/powerpoint/edit-with-copilot-in-powerpoint

As developer tools move into the age of agentic AI, it is easy to fall into a familiar habit: when a task matters, choose the strongest—and usually most expensive—model available.

Real software work is more varied than that. Explaining a function, editing a README, adding a boundary test, debugging a cross-module race condition and reviewing authentication logic demand very different levels of reasoning, context, tool use and reliability. A fixed model for every turn either wastes latency and budget or leaves difficult tasks underpowered.

That is the motivation behind decision-ghc-router: GitHub Copilot continues to execute, while a Decision Router selects a sufficiently reliable and economically sensible model at the start of each new user turn. (The design also draws on gargpratyush/jev-router, especially its per-turn routing, native CLI preservation and model pinning across tool continuations.)

The goal is not to build another agent outside Copilot or replace the native developer experience with a custom chat UI. GitHub Copilot CLI and the VS Code GitHub Copilot extension should keep their existing authentication, model catalog, tools, permissions, sessions and streaming behavior. The router adds one short, explicit decision step—and then gets out of the way.

1. Start with the distinction: a Decision Model is not a Model Router

Before discussing implementation, two frequently conflated concepts need to be separated.

A Decision Model makes bounded, structured judgments

A Decision Model is not prompted with “write an article.” It receives:

• a current state, expressed as text or JSON;
• one or more bounded questions;
• explicit options or grading criteria.

It returns typed results and probabilities that software can act on immediately, rather than free-form prose. For example:

• noul: Does this tool call touch production data? Return a probability between 0 and 1.
• choice: Should this task use the Fast, Balanced or Strong tier? Return the selected option and a probability for every option.
• score: How risky is this code change? Return an ordered score and its probability distribution.

A Decision Model is therefore a fast, calibratable judgment primitive. Its uses extend beyond model selection to classification, ranking, prioritization, validation, agent control, safety screening and AI judging.

A Model Router turns judgment into execution

A Model Router is a system pattern, not a single model. A production-ready router must typically:

1. discover models actually available to the signed-in account;
2. reject candidates that are unavailable, unpriced, context-insufficient or API-incompatible;
3. build a minimal routing state;
4. invoke a scorer—which might be rules, a benchmark table, an LLM classifier or a Decision Model;
5. apply confidence, cost, latency, safety and organizational policy;
6. select a concrete model and start native execution;
7. pin that model across tool continuations;
8. emit decisions, estimates and failures for audit and tuning.

In short:

The Decision Model judges what is most suitable. The Model Router makes that judgment usable, compliant, executable, observable and recoverable.

A Decision Router does not replace the larger routing system. It gives that system a specialized, fast and threshold-friendly scoring engine.

Decision Model versus Model Router

2. Microsoft-Decision-1: why it fits developer-tool routing

Microsoft introduced Microsoft-Decision-1 in October 2026 as a specialized model for fast decision scoring, available through Microsoft Foundry. Unlike a generative LLM, it does not produce an essay or a written chain of reasoning. It makes a focused judgment about text or JSON and returns typed numerical decisions.

Microsoft describes the model as a post-trained Qwen3.5-9B designed for single-pass scoring over fixed options. It reports the highest accuracy in a 36-benchmark comparison spanning nearly 150,000 questions kept blind from training, P50 latency roughly 35 times faster than GPT-6 Sol, and an average 1.3% decision-flip rate across eight perturbation types. At launch, Microsoft listed input at US$0.042 per million tokens with no output-token charge; pricing is dynamic, so a deployment should use the current Microsoft Foundry listing. Those are Microsoft-published benchmark results, not a substitute for evaluation on a team’s own development workload.

Microsoft-Decision-1 exposes three question types that map naturally to an AI control plane:

• noul for binary gates such as “May this command run automatically?”
• choice for bounded routing such as “Which model tier should handle this turn?”
• score for ordered grading such as “How severe is the change risk?”

Why not use a small LLM classifier?

That is a valid architecture. Many model routers ask a lightweight LLM to emit easy, medium or hard. GitHub Agentic Workflows’ experimental model routing also classifies a task before ranking allowed model-and-effort combinations through precompiled routing tables.

A dedicated Decision Model, however, offers four useful properties for developer tools:

1. Bounded output. A router needs a label and probabilities, not persuasive prose.
2. Predictable latency. Agent workflows amplify the cost of every sequential control-plane call.
3. Policy-ready confidence. If the top probability is below 0.65, a local policy can avoid downgrading, keep the current model or request manual selection.
4. Composable governance. One structured request can score model tier, operational risk and the need for human review.

A conceptual choice request for Copilot routing

The following is simplified pseudodata—not repository source—and omits deployment and authentication details:

{ "state": { "task": "Fix intermittent failures in the authentication integration tests", "estimatedContextTokens": 18000, "toolUseExpected": true, "workspaceScope": "multi-file", "latencyPreference": "balanced" }, "questions": { "model_tier": { "type": "choice", "instructions": "Choose the least expensive tier likely to complete the task reliably in one pass.", "criteria": { "fast": "Simple explanation, formatting, lookup, or small deterministic edit", "balanced": "Normal coding, tests, debugging, or limited multi-file work", "strong": "Ambiguous architecture, security, difficult debugging, or broad multi-file reasoning" } } } }

The response identifies a tier and assigns a probability to every tier. The router then maps the abstract choice to a concrete model that is truly available to the current GitHub account.

That separation matters: a Decision Model should not assume that a user owns or can access a particular model. The account catalog is the source of truth.

3. The decision-ghc-router scenario and reference architecture

The architecture has two hosts but one consistent decision model.

3.1 GitHub Copilot CLI: put the router in native /model

In the public predecessor implementation, a user-level extension adds a router entry to GitHub Copilot CLI’s native /model menu. The user can select the router or choose a concrete model directly:

• Select Decision Router: route every new user turn.
• Select a concrete model: bypass routing and return to native fixed-model behavior.
• Continue a tool call: keep the model chosen for that turn; do not classify again.
• Explicitly request a model: the explicit request should win.

The CLI path uses a random-port 127.0.0.1 proxy to expose the router as a temporary provider while preserving Copilot authentication, sessions, tools, permissions and streaming. GitHub credentials should remain in memory and be used only for HTTPS requests to GitHub. The local proxy uses separate random credentials; GitHub credentials must not be written to logs or sent to the Decision API.

This is the design principle I care about most:

The router changes which model is selected, not how Copilot works.

3.2 VS Code and VS Code Insiders: enter the Chat Model Picker

The editor integration is a separate extension. It registers decision-router in VS Code Chat’s model picker and uses the public Language Model API to discover Copilot models available to the account signed into that editor.

The privacy boundary is intentional:

• The Decision Model receives an unambiguously extracted task or a routing-only summary entered by the user.
• If the task cannot be reliably isolated from editor context, the extension should not automatically upload attachments, source files or the full conversation.
• The selected Copilot model still receives the full conversation, tool definitions and workspace context.
• VS Code invokes native tools, while tool-call IDs maintain model consistency.

The short version is: minimize data for decision; maximize context for execution.

3.3 The seven-step loop for each new user turn

1. Receive the task through native Copilot CLI or VS Code Chat.
2. Discover candidates from account models, prices, context capabilities and API compatibility.
3. Build routing state with the minimum sufficient task summary and bounded choices.
4. Call Microsoft-Decision-1 and receive choice probabilities.
5. Apply local policy for confidence, cost, compatibility and manual overrides.
6. Execute natively with the selected model, existing tools, permissions, session and streaming.
7. Pin and trace the model for tool continuations while recording the decision and estimate.

3.4 Why not reroute every tool continuation?

Imagine a model runs tests, reads the failure output and then edits code. If the router chooses a new model after every tool result:

• prompt-cache benefits may disappear, increasing total cost;
• the new model may interpret earlier tool calls differently;
• the debugging chain becomes harder to reproduce and audit.

I therefore retain one of jev-router’s strongest ideas: make one decision at the start of a new user turn, then pin that model for the resulting tool chain. Main conversations and sub-agents should be pinned independently.

4. Main technologies and frameworks

Based on mechanisms verifiable in the public predecessor and the Microsoft-Decision-1 evolution described here, the project separates into the following layers.

Node.js and ESM modules

The core router uses Node.js and .mjs modules to handle:

• CLI startup and argument forwarding;
• model catalog and price adaptation;
• the local HTTP proxy;
• configuration and environment variables;
• Decision API calls;
• policy, errors and telemetry.

The public predecessor requires Node.js 22.16 or later and uses Microsoft’s npm package source for relevant dependencies.

GitHub Copilot CLI extension interfaces

The CLI integration relies on experimental extension interfaces to register the router as a native model entry. It explicitly enables the provider-endpoint interface and obtains the model catalog, runtime inference endpoint and authentication from the active session.

Three rules are essential:

1. Do not modify the user’s global default model.
2. Do not automatically grant shell or other tool permissions.
3. If initialization fails, report a clear error instead of pretending routing succeeded.

Local loopback proxy

The loopback proxy is the adapter that preserves the native CLI:

• listen only on 127.0.0.1;
• use a random port and random local credentials;
• map the router’s selection to a real Copilot execution model;
• preserve streaming, tool calls, sessions and permission prompts;
• never create a second hidden agent loop.

VS Code Extension API

The editor extension discovers current candidates through:

vscode.lm.selectChatModels({ vendor: "copilot" })

and is packaged as a VSIX. The CLI and editor are independent hosts and may use different GitHub accounts with different entitlements. Candidate discovery must therefore be host-specific, session-specific and dynamic—not a hardcoded list of model IDs.

Microsoft Foundry and the Decision API

Microsoft-Decision-1 can be deployed in Microsoft Foundry through GlobalStandard or, in selected regions, DataZoneStandard. Authentication can use Microsoft Entra ID (recommended) or an API key.

In this architecture, the Decision API only scores choices:

• Input: minimal task state, bounded candidates and explicit criteria.
• Output: selected option, option probabilities and usage.
• Not its responsibility: GitHub credentials, developer tools, full workspace access or code execution.

That separation makes the decision plane and execution plane independently governable.

Model catalog, pricing and capability adapters

The public predecessor discovers models from the signed-in account instead of hardcoding them. Before scoring, a router should exclude:

• auto, hidden, disabled or unconfigured entries;
• models without usable price information;
• candidates with insufficient input context;
• models incompatible with the host’s wire API;
• models restricted by administrator policy.

Cost estimation supports ranking and user feedback; it is not a final bill. Promotions, cache discounts, hidden context, retries and later tool rounds all affect the result. GitHub Billing remains authoritative.

5. What I borrow from jev-router—and what changes

The value of gargpratyush/jev-router is not merely “use a small model for easy tasks.” It embeds routing into familiar CLIs without taking away their native behavior.

The ideas I retain include:

• one routing decision per new user turn;
• a router sentinel in the native model picker;
• concrete-model selection pauses routing;
• abstract Fast, Balanced, Strong and Long tiers map to host-specific models;
• tool continuations keep the tier selected at the start of the turn;
• explicit model requests win;
• low confidence should not trigger an aggressive downgrade;
• large conversations must account for cache and migration cost;
• explanation data should show why a tier was selected.

The decision-ghc-router evolution replaces the external JEV/System One scorer with Microsoft-Decision-1 and emphasizes five changes:

1. Probability is a first-class signal. Policy can threshold the decision instead of accepting a label blindly.
2. Bounded choices come from the real catalog. Decision-1 only chooses among already eligible candidates.
3. Local policy owns the final answer. Organizational rules, compatibility and manual overrides remain deterministic.
4. The Decision Model is reusable. A single structured call can also score operational risk and the need for human review.
5. Local and cloud responsibilities are explicit. Cloud scoring is isolated from credentials and execution.

6. Representative use cases

A. Fast explanation and small edits

“Explain this regular expression,” “turn this note into a table,” or “add a null-value test to an existing function.”

The router can often select the Fast tier. The objective is not the weakest model; it is the least expensive model likely to complete the task reliably in one pass.

B. Normal development and debugging

“Fix the failing test,” “refactor this module without changing its API,” or “use the stack trace to locate the bug.”

These tasks require code reading, tool use and moderate reasoning, so they often land in Balanced.

C. Security, architecture and broad multi-file reasoning

“Review this OAuth callback for state confusion,” “design cross-region failover,” or “find a race condition across services.”

The router should choose Strong even when it costs more. Routing optimization means “economical subject to reliable completion,” not “always cheaper.”

D. Long context and large repositories

If a candidate cannot hold the estimated input, it must be removed before scoring. For an already large conversation, the router should also avoid downgrading when lost cache work or context migration would cost more than the model-price saving.

E. Organizational policy and risk gates

The same Decision API request can include additional noul or score questions:

• Does the task involve production data?
• Is the proposed command destructive?
• What is the security risk level of the change?
• Should execution be handed to a human reviewer?

At that point the router grows from a cost optimizer into a lightweight control plane for agents.

7. Policies I would keep for production

Filter deterministically before scoring

Entitlement, API compatibility, context limits and administrator restrictions are facts. The Decision Model should not be asked to guess them.

Do not automatically downgrade on low confidence

When the top probability falls below a calibrated threshold, the router can:

• keep the current model;
• cap automatic movement at Balanced;
• request manual selection;
• send high-risk tasks to Strong or human review.

The threshold must be calibrated on labeled tasks from the target environment, not copied from an example.

Explicit intent beats automatic routing

If the user says “use the Strong model” or selects a concrete entry in the picker, the router should step aside immediately.

Never substitute silently

Missing credentials, Decision API timeouts, unknown pricing and insufficient context should produce an explicit state. Whether to fail open, fail closed or keep the current model must be an intentional host or organizational policy.

Record decisions without logging every prompt by default

Useful telemetry includes:

• anonymized session and turn IDs;
• candidates and exclusion reasons;
• selected tier, probabilities and policy overrides;
• estimated input/output and one-turn cost;
• completion, retry and manual-reselection outcomes.

Full prompts, source code and tool results should be excluded by default or governed by explicit retention and data-handling policy.

Evaluate the router on task success, not the cheapest request

Better metrics include:

• first-pass completion rate;
• total time to completion;
• total cost including retries and tool rounds;
• manual model-change rate;
• low-confidence and misrouting rates;
• safety and policy violations.

8. Why this matters beyond one repository

From a developer-advocacy perspective, the Decision Router is not simply a token-saving utility. It illustrates a clearer division of responsibilities in agent engineering:

• Generative models understand, reason, write code and call tools.
• Decision Models make fast, structured and probabilistic judgments.
• Routers and policy engines place those judgments inside real account, budget, compatibility and governance constraints.
• Developer-tool hosts retain identity, permission, context and execution control.

Future AI developer tools will not be tied to one “default large model.” They will manage a portfolio of models with different speed, cost, context and capability profiles. The differentiator will no longer be merely which model a product connects to, but:

Can it select the right model at the right moment, in an explainable and governable way, without breaking the developer experience?

That is why I am adding a Decision Router to GitHub Copilot CLI and the VS Code GitHub Copilot extension.

GitHub Copilot keeps executing. Microsoft-Decision-1 makes the fast judgment. The local router turns that judgment into a usable engineering decision.

References

1. decision-ghc-router
2. jev-ghc-router
3. gargpratyush/jev-router
4. Microsoft-Decision-1: Our model for fast decision-making
5. Deploy and use Microsoft-Decision-1 in Microsoft Foundry
6. GitHub Agentic Workflows — Model Routing
7. GitHub Copilot model billing and pricing