Pimp My IDE / garage dispatch
Back to garage
September 29, 2026 | inline suggestions / editor timing

The suggestion is only good when the timing is.

GitHub and VS Code rebuilt three code-suggestion jobs as one system. Their account of the work has a sharper lesson than the model launch. The client decides whether a useful edit feels helpful or keeps getting in the way.

Measure the model, the request path, the renderer, and what happens after the developer says no.

One edit can arrive in several shapes.

VS Code documents two visible kinds of Copilot inline suggestion. Ghost text continues code at the cursor. Next edit suggestions predict another edit and its location. The new unified system can choose current-line text, a nearby rewrite, a farther edit, or no suggestion.[1]

GitHub and Microsoft say they trained one model to cover completion, next-edit, and longer-distance edit behavior. A shared diff-patch format lets one response carry several ordered edits. The client can cache later patches and present them after the developer accepts the first change.[2]

The model proposes an edit. The editor decides when, where, and whether that edit deserves attention.

A client rule moved the dismissal result.

The team's second technical post describes an inherited client behavior. Ignored ghost text could return as a next edit after the cursor moved. The system treated those as different views. The developer saw the same unwanted suggestion twice.

In the reported A/B test, removing that behavior changed the dismissal comparison by 26 percentage points. The reported result moved from a 15.9 percent increase to a 10.1 percent decrease against the production setup. This is a first-party experiment on GitHub's product. It does not predict results in another editor or codebase.[3]

Fast can still interrupt.

The team also tested speculative decoding, cache delay, debounce timing, progressive reveal, and diff-based rendering. Their chosen setup speculated the current-line completion to reduce latency. It delayed some cached suggestions so they matched the developer's typing rhythm. Longer ghost text appeared in stages rather than as one large block.

Those choices expose the real control problem. A suggestion can be correct and still arrive too early, cover too much code, or repeat after dismissal. Test interruption cost beside acceptance. Record reverts, repeated rejects, retained code, latency, and the cases where silence was the best response.

Give people a brake.

VS Code lets users collapse next edits, disable suggestions by language, and snooze all inline suggestions in five-minute steps. A metered connection blocks new automatic requests while keeping explicit requests available.[1] These are product controls, not decoration. They let a developer reclaim attention without uninstalling the feature.

Start with one workflow and one week of evidence. Keep a short set of must-not-repeat failures. Test the same model with the actual renderer and timing rules. If rejected text returns in another shape, count that as one repeated interruption.

Interactive makeover / suggestion timing rig

Tune attention before output

Traditional purpose replaced: a single on/off switch for every inline suggestion. Better version: set a workload-specific eagerness policy, close four client-behavior checks, preview the interruption, and copy a test plan. This is a teaching tool, not a VS Code setting or live product measurement.

Set the intervention

The range chooses a demo policy. The checkboxes name client behaviors to test. No model request leaves this page.

ON PAUSE
ManualEvery chance
Client checks
Timing plan draft1 of 4 checks selected
Physical selector

Interruption carriage

timing-policy.jswait for pause
const next = current.map(normalize)
ATTENTION LOADON PAUSE / PLAN ONLY

Wait for a pause.

The cursor check is selected. Dismissal memory, progressive reveal, and the brake path remain open.

What this component proves. It creates a timing test plan and previews four eagerness policies. It does not call Copilot, change an editor setting, measure latency, run an A/B test, or approve a suggestion system.

Sources and limits

Open the source log
  1. Visual Studio Code documentation, "Inline suggestions from GitHub Copilot in VS Code", read September 29, 2026. It documents ghost text, next edit suggestions, partial acceptance, collapsed edits, per-language controls, snooze behavior, metered connections, model selection, and timing settings.
  2. Visual Studio Code blog, "Building the new GitHub Copilot Inline Suggestions Model: Part One", September 16, 2026. This first-party engineering post describes the unified diff-patch format, multi-patch caching, data construction, evaluation stages, and reported 2-in-1 results.
  3. Visual Studio Code blog, "Building the new GitHub Copilot Inline Suggestions Model: Part Two", September 23, 2026. This first-party engineering post describes the 3-in-1 model, dismissal-memory bug, client ablation, speculative decoding, progressive reveal, rendering, cache delay, and reported online results.
  4. GitHub Docs, "GitHub Copilot code suggestions in your IDE", read September 29, 2026. It distinguishes ghost text from next edit suggestions and documents the separate model-selection scope for ghost text.

Evidence boundary. The measurements here are GitHub and Microsoft's first-party training and product experiments. Pimp My IDE did not receive the datasets, model weights, client telemetry, or experiment assignments. The timing rig creates a test template. It does not reproduce those results or measure a live editor.