Beyond One-Size-Fits-All: Decision Routing for GitHub Copilot in CLI & VS Code

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