August 13, 2026 ยท 09:53 UTC 9 min read

Next Edit Suggestions Built for Any Model

Next Edit Suggestions Built for Any Model

Reading the Intent Behind a Keystroke

Every keystroke carries an intention, and the editor reads that intention the moment a rename lands on the cursor line, so a single Tab pushes the same change outward through every stale reference across the file while the developer stays in control.

Ghost text appears on the cursor line for an instant apply, while a jump hint guides the caret toward the next edit down the file.

Model choice stays with the developer, whether that model sits on a local endpoint for privacy or on a hosted gateway for scale.

Note

Open source on GitHub at NeaByteLab/Autocompletion-VSCode, it is MIT licensed and installed by hand since it relies on a proposed editor API, ships against any OpenAI compatible endpoint, and runs the same loop on a local runtime or a hosted gateway.

Focused Models Over Giant Ones

Research behind this build argues that focused and lightweight models serve people better than giant ones, since a small model reaches a modest laptop while a heavy model locks the same help behind costly hardware, so this extension carries that idea straight into the daily editing loop where prediction runs on whatever endpoint a developer already has within reach.

Intelligence here leans on the model a developer already trusts, and it speaks to any OpenAI compatible responses endpoint, so a private local runtime and a hosted gateway both drive the same loop while the choice of model stays with the person.

Ghost text suggestion appearing inline on the cursor line inside the editor

Context matters more than raw size, so the document, the cursor, the nearby diagnostics, and a short history of recent edits travel to the model on each request, and the answer streams back as diff hunks where every hunk becomes a single suggestion.

Compute Walls and Stale Guesses

Most editing helpers assume abundant compute and a fixed provider, so a developer on a modest machine or a private endpoint gets left behind, and a rename touching ten spots across a single file still turns into ten manual passes through the tree.

Plain completions arrive as raw text with no idea what just changed, so the guess ignores a rename and offers something stale.

Refused suggestions tend to come back again and again, because the tool forgets what a developer already turned down, so that repetition wears on trust while the caret keeps fighting the same unwanted edit over the same line for no clear reason.

Where the Loop Should Land

  • Keeping the prediction loop tied to any OpenAI compatible responses endpoint.
  • Chaining one accepted edit into the next until every stale reference matches.
  • Learning from a refusal so a declined suggestion stays out of the way for good.
  • Trimming each suggestion down to the token that genuinely changed on the line.

Watching, Prompting, Propagating

Watching the document while typing anchors the strategy, and a rolling record of recent edits rides alongside it, so the file, the cursor, the diagnostics, and that record reach the model as one prompt describing the current intent behind the caret.

Intent on the cursor line reads as the truth, so the model pushes that change out toward the stale references and leaves it alone.

Diff hunks stream back from the model as the reply forms, and a parser designed for surgical spans turns each hunk into a tight edit, trimming a rename down to the single token that changed so the suggestion reads as a finished thought rather than a whole rewritten block that would bury the real change under a pile of unrelated noise nobody actually wants to read.

Inline edit further down the file with a jump hint prompting a second Tab

Streaming Hunks Into Tab Presses

Streaming drives the loop, so text flows from the endpoint token by token while a parser reads the diff hunks as they arrive, and a suggestion can surface before the full response lands, which keeps the whole loop quick even on a modest local model.

Hunks on the cursor line render as ghost text for a one Tab apply, while a hunk further down the file renders as an inline edit that carries a jump hint, so the first Tab moves the caret over there and a second Tab writes the change into its place.

Acceptance triggers the next round, so one rename chains across the whole file as each Tab lands, and a session layer prunes suggestions that no longer match the document while it remembers each one a developer already refused during the run.

What the Build Delivers

CapabilityDelivered
EndpointsAny OpenAI compatible responses API, local or hosted
SuggestionsGhost text on the cursor line and inline edits with a jump
ChainingOne accepted edit triggers the next round across the file
MemoryRecent edits guide the model and refusals steer it away
PrecisionSurgical spans trim each hunk to the token that changed

Any OpenAI compatible responses endpoint now drives the build, from a local runtime on a laptop to a hosted gateway, so the same editing experience reaches modest hardware and premium models on truly equal footing across the whole board right now.

Renames now chain through an entire file with a steady rhythm of Tab presses, and each accepted edit triggers the next round, so a wide refactor moves from a slow manual sweep into a short guided sequence where the developer stays in control of every single change that lands on disk, from the first token on the cursor line to the last stale reference far below it.

Declined ideas stay declined, since the refused list travels right back into the prompt and steers the model away from repeating them, so the loop grows much quieter and more accurate the longer a single focused coding session keeps on running along.

Lessons the Loop Taught

Openness on model choice taught the most, because tying prediction to any endpoint meant a private local runtime and a hosted service both worked without special cases, and that freedom mattered more than raw model size for the daily editing loop that a developer truly lives inside from the first coffee of the early morning through to the last commit late at night.

Sending diff hunks as they form rather than waiting on a whole response kept the loop responsive even when a slow model ran there.

Treating a refusal as data rather than noise turned the declined list into a quiet honest teacher, and trimming each hunk down to the token that actually changed kept every suggestion tight, so the edit landed as a precise fix instead of a bulky rewrite that nobody ever asked for and that everybody would surely end up rejecting anyway on the very first quick sight.

One Tab Away From the Next

What began as a way to predict the next edit grew into a loop that respects the developer, running on any model the person already trusts and chaining a single intent across a whole file through nothing more than a steady rhythm of quick Tab presses.

Suggestions stay close to the work, private on a local endpoint or fast on a hosted one, and the model sharpens on every refusal.

Distance between one edit and the next shrinks to a single quick Tab, and the research behind it holds truer in practice, since a focused and lightweight approach puts real editing help within reach of anyone with an editor and a modest machine rather than a costly rig locked away behind a tall wall of expensive dedicated hardware that only a few can ever afford.

Share
On this page
No results found.