Month: October 2026

Choose how proactively Copilot offers inline suggestions.

A helpful suggestion at the wrong moment can still feel like an interruption. When you’re completing a familiar pattern, you may want Copilot to anticipate several changes ahead. When working through delicate logic, you may prefer Copilot to scope its changes to the statement at hand and leave the next decision to you.

Community feedback about inline suggestions made both preferences clear: some developers wanted fewer suggestions, while others wanted Copilot to do more. No single default could satisfy everyone. In earlier posts about training the 3-in-1 inline suggestions model covering Completions, NES, and Long-Distance NES (part one, part two), we explained how developer feedback helped us improve the default experience. This strong default is a great starting point, but developers differ in how much assistance they prefer. We wanted to let them tailor their experience to their own preferences.

Configurable eagerness gives developers more control over how proactively Copilot offers inline suggestions. We trained the inline suggestions model to support three modes: low, medium, and high eagerness. In this post, we’ll explain how we defined and trained those behaviors, what our first approach taught us, and how on-policy distillation (OPD) and reinforcement learning (RL) made the feature easier to carry forward to future models.

Introducing configurable eagerness

We define eagerness along two dimensions: how often the model offers a suggestion and the size of each proposed edit.

These settings guide how Copilot behaves rather than imposing strict limits on suggestion timing or size. Low eagerness still offers complete, useful suggestions; it’s simply more conservative. High eagerness may propose more and larger suggestions, but only when that work is relevant to the user’s current task.

This demo shows a simple example: from the same starting point (class ModelManager:), each setting produces different behavior. Low eagerness proposes five small, incremental suggestions and leaves it to the developer to decide which methods to add and what validation they need. High eagerness proposes three larger suggestions that anticipate follow-on work, such as raising a KeyError when attempting to remove a model that doesn’t exist.

Figure 1. Low, medium, and high eagerness while building a ModelManager class.

To train these behaviors, we needed a measurable definition of eagerness. Because our model outputs suggestions in a diff-based format, we used edit distance (the number of characters changed by a suggestion) as a proxy for eagerness, capturing both edit size and frequency¹.

One model, three modes

We considered training a separate model for each eagerness level, but this approach would have multiplied future deployment and upgrade complexity. Instead, we trained one model to produce all three behaviors (low, medium, and high eagerness), conditioned on a lightweight control tag:

We trained the model to interpret this tag as an eagerness control: it produced more conservative suggestions for low eagerness and more proactive suggestions for high eagerness, while preserving its default behavior for medium.

We started with supervised fine-tuning (SFT). For every training prompt, we sampled responses from variants of the model with varying levels of eagerness, filtered to high-quality responses, and ordered the responses by edit distance to produce examples of low, medium, and high eagerness for each prompt in the dataset.

Figure 2. Supervised fine-tuning for configurable eagerness.

The training dataset is sent to model variants with different eagerness settings, and their responses are filtered by eagerness and quality into low-eagerness responses with prompts, default responses, and high-eagerness responses with prompts. These three groups form the dataset for SFT, followed by RL and evaluation.

This approach fit naturally into our existing reinforcement-learning pipeline. Most of the work happened during supervised fine-tuning, with only minimal changes to the RL setup:

• SFT taught the model the new low-, medium-, and high-eagerness behaviors.
• RL improved overall suggestion quality while preserving those learned behaviors.

Making configurable eagerness portable across models

The SFT approach worked, but it had two limitations that made it difficult to scale: it depended on pre-existing model variants with different eagerness levels and required retraining on responses from those models. Adding the feature to an improved base model would therefore mean training new models and then retraining from scratch. We needed a way to preserve a new model’s default behavior while adding only the low- and high-eagerness modes.

The key insight was that instead of relying on multiple model variants, we could use the production model to generate and compare multiple variants of a suggestion.

To make eagerness portable across future base models, we separated the behavior we wanted to preserve from the behavior we wanted to change. The training objective had two parts:

• For medium eagerness, match the behavior of a reference inline suggestions model.
• For low and high eagerness, move edit distance below or above the reference model’s medium prediction while preserving suggestion quality.

Figure 3. Portable post-training with on-policy distillation for configurable eagerness.

The training dataset branches into default prompts and low- and high-eagerness prompts. Default prompts and the reference model contribute the distillation objective, while low- and high-eagerness prompts contribute quality and eagerness rewards; the combined objective feeds RL and evaluation.

For medium eagerness, we used on-policy distillation (OPD) to preserve the reference model’s default behavior². The model under training generated responses, and the reference model supplied token-level probabilities on those same generated prefixes. Training then minimized the difference between the two models’ predicted token distributions, encouraging the model to behave like the reference. This taught the model to match the reference on its own generated responses at medium eagerness, while low- and high-eagerness modes were learned through their rewards.

For low and high eagerness, we reused the quality graders developed for the 3-in-1 model’s SFT and RL, then added a relative eagerness reward based on the response’s edit distance compared to the reference model’s medium response. Low eagerness was rewarded for proposing a smaller edit than the reference. High eagerness was rewarded for proposing a larger one. In both cases, the quality reward prevented the model from optimizing edit distance at the expense of usefulness.

Mitigating reward hacking

Reward hacking occurs when a model finds a way to increase its measured reward without producing the behavior the model developer intended to encourage. During development, we observed such failure modes in both of the new eagerness settings and added mitigations for each.

High eagerness: An early reward design did not apply the quality grader to the low- and high-eagerness modes. In that training run, the model sometimes proposed unrelated functionality or unnecessary formatting changes while increasing edit distance, as seen in the example below.

We addressed this failure mode by balancing eagerness rewards with rewards from the RL quality grader, plus added instructions to allow legitimately broader edits. Our offline Simulation Tests (STests) caught this issue.

 class SplashStorageService implements ISplashStorageService {
     _serviceBrand: undefined;
+    private _windowSplash: IPartsSplash | undefined;
+
     readonly saveWindowSplash: (splash: IPartsSplash) => Promise<void>;
+    readonly getWindowSplash = (): IPartsSplash | undefined => this._windowSplash;

     constructor(@INativeHostService nativeHostService: INativeHostService) {
-        this.saveWindowSplash = nativeHostService.saveWindowSplash.bind(nativeHostService);
+        this.saveWindowSplash = async (splash: IPartsSplash) => {
+            this._windowSplash = splash;
+            return nativeHostService.saveWindowSplash(splash);
+        };
     }
 }

Figure 4. Example of an over-eager suggestion before mitigation. The model unnecessarily added caching and expanded the service’s API.

Figure 5. Benchmark results before and after mitigating excessive suggestions on the STests benchmark.

The chart plots training steps against the percentage of bad suggestions avoided, on a scale from 60% to 100%. The production baseline stays near 89%; before mitigation, the high-eagerness score falls to about 66% by the final plotted step, while low and medium eagerness remain near the baseline. After mitigation, all three modes stay near the baseline.

Low eagerness: One training run produced smaller measured edits partly by minifying suggestions: removing whitespace and delimiter characters or shortening variable names while maintaining syntactic correctness. This is technically shorter code but is much less desirable! We mitigated this behavior in two ways:

• We normalized whitespace and delimiters before calculating edit distance, which removed any possible advantage from deleting whitespace.
• We added LLM-based grading for less deterministic cases involving variable names and delimiters.

We baked this into our evaluations by adding a deterministic minification check to the training and evaluation pipeline so this failure mode can be screened in subsequent runs.

class ModelManager: # user typed
    # model suggestion
    def __init__(self):self.models=[]
    def add(self,m):self.models.append(m)

def main():
    m=ModelManager()
    m.add("model1")
main()

class ModelManager: # user typed
    # model suggestion
    def __init__(self):
        self.models = []

    def add(self, model):
        self.models.append(model)

def main():
    m = ModelManager()
    m.add("model1")

main()

Figure 6. Example of minification before and after mitigation.

Online results

We evaluated the configurable model in A/B experiments against the production 3-in-1 model. The results below highlight statistically significant changes. No other key metrics changed significantly from the baseline.

These findings indicate that the configurable model behaved as intended: low eagerness was more conservative, high eagerness was more proactive, and medium preserved the default experience.

What we learned

• Pluggable features simplify development and deployment. The key was separating what should change (eagerness) from what should remain stable (base-model quality). Instead of embedding eagerness in the full SFT recipe, the post-training approach starts from the production model, preserves its default behavior through the reference objective, and adds targeted objectives for low and high eagerness. That separation lets us carry the feature forward without rebuilding the entire training recipe.
• Reliable offline-to-online alignment accelerates iteration. Our offline benchmarks track online outcomes closely. They revealed that optimizing high eagerness for edit distance alone could reduce quality and helped us quickly develop a reward that balanced eagerness and quality.
• Dogfooding findings should become regression tests. As with the Qualitative Must-Haves benchmark, internal use surfaced issues that offline examples alone could miss because timing, cached suggestions, and surrounding tools all affect the experience. For example, several examples of reward hacking were caught during dogfooding. We turned those findings into repeatable checks and used them to monitor the final model’s quality.

What’s next

Configurable eagerness is a first step toward inline suggestions that adapt to each developer and task. We’re exploring two directions:

• Automatic eagerness: Adjust how proactively Copilot offers suggestions based on the current context, while keeping developers in control of the experience.
• Learning from experience: Use signals from rejected, modified, or corrected suggestions to reduce repeated errors and better align future suggestions with a developer’s intent.

The goal isn’t simply to suggest more or less code. It’s to provide the right level of assistance for the moment, and improve that fit over time.

Try it out

Configurable eagerness is available to paid GitHub Copilot subscribers in VS Code. Update to the latest version of VS Code, confirm that Next Edit Suggestions are enabled (they are on by default), then open the Copilot settings menu and choose an Eagerness setting. Try each mode to find the level of assistance that works best for you, and please share your feedback in the VS Code repository.

Help shape what’s next

We’re constantly working to improve the model, and your feedback can help. Sign up to participate in our user studies and help shape future improvements.

Join a user study

Acknowledgments

Thank you to the developer community for your ongoing feedback that shaped configurable eagerness, and to the combined teams of researchers, engineers, PMs, and designers across VS Code, GitHub Copilot, and Microsoft for their contributions, testing, and support throughout development.

Special thanks to Alexandru Dima, Julia Gong, Satarupa Guha, Yu Hu, Ben Liggett, Shengjie Ma, Gaurav Mittal, Elsie Nallipogu, Vedha Ranganathan, and Nick Trogh for their insightful feedback on this blog post.

Happy coding! 💙

When we gathered at GitHub Universe in October 2025, working with agents in VS Code was still relatively new. A year later, working with agents has become the new normal. A single developer can put several agents to work on different problems, keep coding while those tasks move forward, and check back in to review the results. Work can continue on another machine, in another app, or in the cloud after your laptop closes. The editor that helps you write code is also becoming the place where you coordinate much more of the work it takes to ship software.

Imagine handing off a feature to Copilot, while an agent using the Claude harness investigates a bug, then opening the running app in a browser that both you and the agent can see and control. Project instructions and tools give those agents the context to work, and the Agents window brings their progress and changes together for review.

When you hand a task to an agent, it shouldn’t matter which app you’re using to launch the task. When you switch to another tool, the task should continue running. Over the last releases, we’ve worked to make these connected, continuous experiences across VS Code and other Copilot apps become reality.

In this blog post, we’re zooming into how far VS Code has come since the last Universe, and what you can do with it today.

Agents that keep working

Developers can hand off more of the work without handing over the decisions that matter. We built on our Language Server Protocol and Debug Adapter Protocol experience to create the Agent Host Protocol (AHP), which just went 1.0.

Just as a language server makes code completion and Go to Definition available to different editors, an Agent Host brings agent functionality into an independent process. It manages sessions and provides access to multiple harnesses, models, files, and terminals.

AHP lets clients connect to those sessions and stay in sync. Cloud sessions run on GitHub’s infrastructure, so closing your laptop doesn’t stop them. You can continue the same session in VS Code, the GitHub Copilot app, GitHub Mobile, github.com, or Copilot CLI. And because the protocol is open, anyone can build a client that works with the same live sessions as VS Code.

Choosing your agent

The agent harness is what coordinates the agent loop and connects the language model to context and tools.
We combined our Local VS Code harness with the Copilot CLI harness to create the new Copilot harness, now the default for new sessions in both the editor and Agents window. Built on the Microsoft Copilot SDK developed by GitHub, it brings more consistent agent behavior across VS Code, Copilot CLI, and the GitHub Copilot app. This also means that you can reuse your agent customizations across different Copilot experiences without modifications.

You can also use the Claude and Codex harnesses in VS Code through the Agent Host. Each runs on its provider’s own agent harness, with its own runtime and capabilities. VS Code brings their sessions together in one place, where you can manage work across agents without requiring every agent to work the same way.

Choosing your model

Access to multiple models remains one of Copilot’s pillars. The model picker lets you select from Copilot and bring your own key models. You can specify options like reasoning effort and context size to optimize the model configuration for the task.

As newer and more capable models become available, choosing the right model for the task is becoming more and more difficult. Maybe one model is not the best for each part of the task.
Copilot Fusion autonomously chooses one model or orchestrates a set of models to solve the task at hand. In the Agents Window, you can also use the Compare Models feature in Preview to run different models and harnesses on the same task, review results side by side, and combine the best ideas. Together, these options help you balance speed, cost, and quality.

Managing parallel work

The work we started with Agent HQ in VS Code has grown into the Agents Window, a dedicated space to manage agents across all your workspaces and environments. Run agent sessions in parallel, follow progress, and review changes from a single interface. Seamlessly switch between the editor and the Agents window without starting over. Both views stay in sync with the same live Copilot session. For recurring tasks, use automations, either locally or in the cloud. To avoid conflicts, worktrees help you keep changes isolated between agents.

And when you need to dive into the code or run a debugging session, you can switch to the editor and back to the Agents window at any time. Your active sessions remain running uninterrupted.

The Agent Host is a separate process that lets the Agents window connect to multiple agent sessions at once, including those on remote machines over SSH or dev tunnels, or sessions running in the cloud. Remote agents use that machine’s code, tools, and dependencies and keep working after you disconnect, as long as the machine and host stay running.

Shaping your agents

Instructions, skills, hooks, custom agents, and plugins help agents understand your project conventions and workflows. Projects already customized for the Claude Code or OpenAI Codex developer tools can use that setup with their respective harnesses, without rebuilding it for VS Code.

Support for the Model Context Protocol, including MCP Apps, connects agents to your tools and services. Extension authors can contribute agent tools and MCP servers through the Marketplace.

Copilot connectors, now in preview, bring context from services such as Slack, Notion, and Microsoft Learn into your agent sessions without requiring you to install or manage an MCP server. Connect once and reuse the connection across supported Copilot clients signed in with the same account. Connectors work with the Copilot harness and are available on all Copilot plans. For Business and Enterprise plans, administrators must allow editor preview features.

For organizations, managed settings apply policies across teams, while sandboxing can restrict agent access to files and network resources.

Beyond the chat

The integrated browser gives you and your agent a shared view of a page, so you can both see and interact with it without leaving VS Code. Your agent can use Playwright to test a workflow, check the results of its changes, and help identify web accessibility issues.

Some workflows are easier to navigate visually than through a conversation. Canvases, now in preview, let you create interactive interfaces for working with your agent and its context, such as a task board for tracking a project. You can also choose from readily available canvases. The Markdown editor lets you edit a rendered plan or document directly and leave comments for your agent to act on, rather than describing every revision in chat.

Completing a task might mean working with a desktop application that doesn’t have an MCP server or another tool integration. Experimental computer use lets your agent interact with those applications on macOS and Windows by clicking controls and editing text. You control application access, and organizations can disable it through policy.

With models that support image generation, you can create visual assets for your project alongside the code, whether you’re exploring a design idea or building a prototype.

For a little fun, there’s Blobby, the VS Code pet who reacts as you work with agents, with achievements to unlock along the way.

Still your editor

We remain just as committed to the editor you rely on every day. Precision editing, code completion, navigation, refactoring, and debugging remain at the heart of VS Code. Next edit suggestions continue to improve with new models and are available to Copilot Free users.

The extension ecosystem remains central to making VS Code your own, from language support to AI extensions like Claude Code and Codex. And it has never been easier to build your own extension.

Last, but not least, our UI modernization work brings shared design choices to the editor and Agents window for a clearer, more consistent experience that preserves your customization and familiar workflows.

Feedback and ideas from the VS Code community have shaped how the product has evolved over the past year. Please keep sharing what is working and what could be better in VS Code GitHub issues!

Happy coding! 💙