Offline VS Code AI on Windows: Local Qwen Autocomplete with LM Studio and Continue

For years, the promise of running local large language models (LLMs) on consumer hardware has been pitched as the ultimate emancipation from cloud subscriptions. Yet anyone who has actually tried to replace a frontier cloud model with a small local model on a laptop knows the sobering truth: consumer hardware is tight on memory, and small models simply cannot match massive datacenter clusters for complex reasoning or multi-file agentic orchestration.

However, as Anurag Singh recently detailed at XDA-Developers, treating a local LLM as a drop-in rival for every cloud feature is the wrong way to look at the problem. By pairing the open-source Continue extension in VS Code with local models served through LM Studio—and, crucially, splitting the workload between two different-sized Qwen 2.5 Coder models—Singh built an offline coding workflow that kept inline completions snappy and code edits available without an internet connection.

For Windows developers, system administrators writing PowerShell or Python on the road, and privacy-conscious engineers, this architecture highlights an important distinction in how VS Code handles local AI today—and why picking the right model role matters much more than chasing the biggest parameter count your GPU or NPU can barely swallow.

Why Built-In VS Code Local Models Still Leave an Autocomplete Gap​

If you have been following Microsoft’s rapid updates to Visual Studio Code, you might wonder why a third-party extension is even necessary. After all, VS Code natively supports Bring Your Own Key (BYOK) and local language models right inside its built-in chat interface.

According to Microsoft’s official Visual Studio Code documentation on AI language models, developers can use the Chat: Manage Language Models command to connect local providers (such as the Ollama extension or custom OpenAI-compatible endpoints) directly to VS Code Chat without signing into a GitHub account or holding a paid Copilot plan. You can even point the chat.utilityModel setting to a local model so background chores like generating commit messages and session titles work completely offline.

Here is the catch that trips up many developers: Microsoft’s documentation explicitly states that BYOK and built-in local model connections apply only to the chat experience and utility tasks. Inline code completions—the real-time ghost text that finishes your lines as you type—along with semantic workspace search and embedding-dependent features, still require the cloud-backed GitHub Copilot service unless an extension steps in via VS Code's InlineCompletionItemProvider API.

That architectural boundary is exactly why Singh turned to the Continue extension. While VS Code’s native chat can talk to a local server offline, Continue bridges the inline completion gap by registering its own autocomplete provider alongside chat and targeted code-edit tools, routing all of them to a local model runner.

Section Summary​

• Native VS Code BYOK: Supports offline local models for conversational chat, code explanations, and background utility tasks without a Copilot subscription.
• The Inline Limitation: Native VS Code local model configuration does not currently support local inline code completions (autocomplete).
• The Extension Workaround: Installing Continue inside VS Code provides an independent inline completion provider, allowing both chat and real-time autocomplete to run against a local endpoint.

The Two-Model Strategy: Why Size Matters for Latency​

The biggest mistake developers make when configuring local AI in an IDE is loading the largest general-purpose chat model their VRAM or unified memory can hold and assigning it to every task. When you type a line of code, you have milliseconds before a delayed suggestion shifts from helpful to infuriating.

If you point an inline autocomplete hook at a hefty 14-billion or 32-billion parameter model—or worse, a "thinking" or reasoning model that burns tokens deliberating in a hidden chain of thought before emitting a single character—your cursor will outrun the model every single time. Furthermore, keeping a massive model resident in memory alongside VS Code, a local build toolchain, Docker containers, or a browser will quickly starve a standard laptop.

In the workflow reported by XDA-Developers, the solution is a deliberate split-role architecture using Alibaba’s Qwen 2.5 Coder family:

Fill-in-the-Middle (FIM): The Secret Behind Tiny Autocomplete Models​

Why can a tiny 1.5-billion parameter model perform useful work inside an editor when it would struggle in an open-ended brainstorming session? The answer comes down to training format and context.

As documented in Continue’s official guide on the Autocomplete model role, inline completion models are trained specifically for Fill-in-the-Middle (FIM). Instead of receiving a conversational prompt, an FIM model is fed the prefix (the code above your cursor) and the suffix (the code below your cursor) using specialized tokens, and is tasked solely with predicting the missing middle segment.

Because your file already contains the variable names, function signatures, imports, and structural patterns, the model does not need encyclopedic world knowledge—it only needs strong pattern recognition and FIM formatting support. Continue’s official documentation specifically lists QwenCoder2.5 (1.5B) and QwenCoder2.5 (7B) among its top recommended open models for the autocomplete role, noting that large general-purpose chat models often perform poorly at inline completion even with heavy prompting.

When Singh needed deeper assistance—such as highlighting an existing function to ask how it works or requesting a rewrite with proper error handling—that request went to Qwen 2.5 Coder 7B through Continue’s chat and edit roles, where waiting a couple of seconds for a response does not break typing rhythm.

Section Summary​

• Autocomplete Role (Qwen 2.5 Coder 1.5B): Prioritizes speed and low memory usage; leverages Fill-in-the-Middle (FIM) tokens to predict code between the text before and after the cursor.
• Chat and Edit Roles (Qwen 2.5 Coder 7B): Handles explicit developer requests like refactoring and error-handling improvements where slightly higher latency is acceptable.
• Avoid Reasoning Models for Inline Tasks: Models that "think" before answering introduce too much delay for real-time line completions.

Step-by-Step: Wiring LM Studio and Continue Into VS Code​

Whether you are running Windows 11 on an x64 workstation with an NVIDIA or AMD GPU, a Copilot+ PC, or macOS (as in Singh’s test setup ), the configuration pipeline between LM Studio, Continue, and VS Code follows the same local server mechanics.

1. Load Your Models and Start the LM Studio Local Server​

Download and install LM Studio, then search for and download both your lightweight FIM-capable autocomplete model (such as Qwen 2.5 Coder 1.5B) and your slightly larger chat/edit model (such as Qwen 2.5 Coder 7B).

According to LM Studio’s developer documentation, you can expose your models through an OpenAI-compatible local REST API in two ways:

• Open the Developer tab inside the LM Studio application and toggle the local server on.
• Or, from your terminal (PowerShell, Command Prompt, or Git Bash on Windows), use the LM Studio CLI command:
  lms server start

By default, LM Studio serves its OpenAI-compatible endpoint at [url]http://localhost:1234/v1[/url].

2. Verify Your Local Security Boundary​

One of the primary attractions of local inference is keeping proprietary code on your own machine. However, local server settings deserve a quick sanity check. According to LM Studio’s CLI documentation for lms server start, the server binds to 127.0.0.1 (localhost) by default, meaning requests never leave your computer.

LM Studio warns that changing the --bind flag to 0.0.0.0 (or setting the LMS_SERVER_HOST environment variable) exposes the inference server to your wider local network—a risky move on airport, hotel, or shared office Wi-Fi unless authentication is configured. Similarly, leave --cors disabled unless a specific web tool requires it. Keeping the default 127.0.0.1 binding ensures your local coding traffic stays strictly loopback-only. (Keep in mind that while LM Studio inference stays local, you should still review your broader VS Code and extension telemetry settings if you work in a strict compliance environment.)

3. Configure Continue in Visual Studio Code​

Install the Continue extension from the Visual Studio Marketplace. Once added, Continue exposes its configuration in config.yaml.

According to Continue’s official LM Studio provider documentation, Continue natively recognizes provider: lmstudio and defaults to [url]http://localhost:1234/v1[/url] as its apiBase (meaning you only need to specify apiBase if you changed the port or are connecting to another box). You can structure your configuration to separate the roles:

name: Local Offline Coding Config
version: 0.0.1
schema: v1
models:
  - name: Qwen 2.5 Coder 7B (Chat & Edit)
    provider: lmstudio
    model: <EXACT_7B_MODEL_ID_FROM_LM_STUDIO>
    roles:
      - chat
      - edit
  - name: Qwen 2.5 Coder 1.5B (Autocomplete)
    provider: lmstudio
    model: <EXACT_1.5B_MODEL_ID_FROM_LM_STUDIO>
    roles:
      - autocomplete

Crucial Troubleshooting Tip: As Singh pointed out in his setup notes, the model identifier entered in Continue’s configuration must match the exact model string exposed by LM Studio’s server. If you have downloaded multiple quantizations (for instance, Q4_K_M versus Q8_0) or instruct versus base variants, check the Developer tab in LM Studio to copy the exact identifier string.

4. Disable Competing Copilot Inline Suggestions​

If you normally keep GitHub Copilot installed for when you are back on fast broadband, running both Copilot and Continue simultaneously will cause two different completion engines to fight over your cursor. Disable GitHub Copilot’s inline completions (via the Copilot status bar icon at the bottom right of VS Code) while using Continue’s local autocomplete so you only get one set of ghost-text suggestions.

Section Summary​

• Endpoint Setup: Start LM Studio's server via the Developer tab or lms server start; it defaults to [url]http://localhost:1234/v1[/url].
• Network Hygiene: Ensure LM Studio stays bound to 127.0.0.1 so local code prompts are not broadcast over public networks.
• Role Mapping: Map the 1.5B model to autocomplete and the 7B model to chat and edit in Continue, ensuring the model IDs match LM Studio's exact strings.

The Honest Verdict: Offline Convenience vs. Cloud Muscle​

Does replacing GitHub Copilot with a 1.5B and 7B local pairing mean local AI has conquered the cloud? Not quite—and any honest technical assessment has to separate workflow responsiveness from raw intelligence.

When Singh reported that his offline coding "got faster," that came down to two practical factors: deliberately dropping down to a 1.5B FIM model so inline suggestions appeared without local hardware lag, and being able to keep coding during flights instead of stalling out waiting for internet access. Notably, the XDA report did not publish synthetic token-per-second benchmarks or specify the exact Mac hardware configuration used, and Singh openly acknowledged that GitHub Copilot remains superior at generating complex code, offering richer suggestions, and running multi-step agentic workflows. Continue’s own documentation echoes this reality, noting that small local models have limited tool-calling and reasoning depth that make full agent modes difficult to pull off.

Where the local LM Studio and Continue combo genuinely shines is scoping:

1. Uninterrupted Travel & Dead-Zone Productivity: Whether you are on a plane refusing to pay for sluggish in-flight Wi-Fi or commuting by train, having a responsive 1.5B FIM model complete boilerplate loops while a 7B model helps add try/catch error handling or clean up repetitive functions keeps momentum going.
2. Breaking Down Maintenance Tasks: Small local models falter when asked to architect an entire microservice from scratch, but they excel when you highlight a single 40-line function and ask for a targeted refactor or explanation.
3. Zero Rate Limits or Subscription Dependencies: Once the model weights are cached on your SSD, your local inference server works identically at 3:00 PM on a Tuesday or 3:00 AM over the Atlantic Ocean.

If you have a machine with a capable GPU or unified memory architecture gathering dust between builds, setting up LM Studio and Continue in VS Code takes less than fifteen minutes. You do not have to cancel your cloud tools permanently to appreciate having a fast, private, offline co-pilot ready to take the controls the moment your Wi-Fi icon drops out.