Yes, VS Code extensions can connect your editor to GPU-accelerated applications, and we can build our own extension. NPU integration is also possible when the processor, driver, runtime, and model are compatible. The extension supplies the editor experience; the inference runtime does the hardware work.

That distinction makes the project manageable. We can start with a useful command, connect it to an existing local service, and measure the result. This article describes a design and development path; it does not report a completed extension or a successful hardware test.

What the reference laptop offers

Our reference ASUS ROG Flow X13 GV302XI configuration combines a Ryzen 9 7940HS, Radeon 780M integrated graphics, and an RTX 4070 Laptop GPU with 8 GB of dedicated VRAM. These details are specification-based and should be confirmed on the individual machine. ASUS specifications.

AMD lists the Ryzen 9 7940HS AI engine at up to 10 TOPS. This processor belongs to the Phoenix generation. That generation matters more than the presence of an NPU label when choosing compatible software. AMD processor specifications.

How an extension uses an accelerator

Installing an AI extension does not automatically move inference to your laptop. It may contact a cloud model, a local service using the CPU, or a local service using an accelerator. The selected provider and runtime determine where computation happens.

For our first version, use this architecture:

1. The developer selects code and invokes a VS Code command.
2. The extension prepares a bounded request and sends it to a configured local endpoint.
3. The model service runs inference using its supported hardware backend.
4. The extension displays the response and allows the developer to cancel the request.

Keep model loading and inference in the service. This keeps the editor-facing code small and lets us change backends without rewriting the workflow. Extensions can run in local, web, or remote hosts; a desktop or WSL extension needs an endpoint reachable from the host where its code actually runs. VS Code extension hosts.

What we can use before creating an extension

Ollama's VS Code extension makes its models available in VS Code Chat. Its current documentation requires VS Code 1.127 or newer and a running Ollama service. Choose a local model explicitly: Ollama can also expose cloud models. This is a practical way to test editor-based chat before designing a custom interface. Ollama integration guide.

Continue documents an Ollama-backed path for local autocomplete. This is a separate task from chat: completions need low latency and a model suitable for filling in code. Its documentation includes small Qwen2.5-Coder models as starting options. Test whether suggestions are useful in your own PHP, Twig, or JavaScript files. Continue autocomplete guide.

VS Code also documents locally hosted language models in its chat experience. However, adding a local chat provider does not automatically provide every built-in completion or embedding feature; those integrations have their own requirements. VS Code model configuration.

Check actual model placement while processing a request. For Ollama, ollama ps distinguishes GPU, CPU, and mixed placement. Keep context and concurrency modest on an 8 GB card. Hardware acceleration must be demonstrated by the runtime and workload, not inferred from an extension's name. Ollama memory guidance.

The NPU has a narrower path on this processor

Support checked on September 30, 2026 gives us a specific constraint. AMD's Ryzen AI Software 1.8 compatibility table lists INT8 convolutional neural networks for Phoenix and Hawk Point, while its BF16 NLP and ONNX Runtime GenAI LLM flows are listed for newer Strix and Krackan platforms. AMD compatibility table.

Consequently, we should not promise NPU-powered coding chat or document embeddings on this reference processor through those flows. An extension cannot remove a runtime's hardware restrictions.

A better NPU experiment is classifying a selected Drupal media image using a compatible INT8 convolutional model. First prove that model on the NPU in a standalone service. Then let the extension request a prediction and display its labels. Model preparation, supported operators, and driver validation come before editor integration.

AMD's current Linux installation guide lists Strix and Krackan support. It does not establish that the same package supports this Phoenix NPU on Linux. Keep that distinction in the migration decision. AMD Linux support.

Design our first extension around one command

A realistic first feature is Workstation Helper: Explain Selection. Select a short function or configuration fragment, invoke the command, and receive an explanation from a local model. It is a small workflow we can evaluate before adding chat, autocomplete, or repository indexing.

• Input: selected text, language identifier, and a short instruction.
• Backend: a configured local Ollama service using a small coding model.
• Output: an explanation in an output channel or editor document.
• Controls: cancellation, request timeout, input-size limit, and one active request.
• Behavior when unavailable: report a connection or model error clearly; leave the selected file unchanged.

Ollama documents a chat endpoint at /api/chat. Our command can use that service directly. The first prototype should send only the selected text and necessary context, giving the developer a predictable scope. Chat API.

How we would build it

Begin with Microsoft's extension generator and choose a TypeScript extension. The documented scaffolding command is:

npx --package yo --package generator-code -- yo code

This command creates a development scaffold; it does not enable GPU or NPU support. Declare the command in package.json, register its handler in src/extension.ts, and add the request and response handling. Use the Extension Development Host to debug it. First-extension tutorial.

1. Verify the local model service independently of VS Code.
2. Implement the selection command and a clear output view.
3. Add cancellation and handle service failures without freezing the editor.
4. Compare responses against code examples whose behavior you understand.
5. Measure responsiveness and resource use with your usual tools open.

If we later want the model in VS Code's model picker, the Language Model Chat Provider API offers a provider integration. It requires model discovery, request handling, response streaming, and token counting. This is an additional layer of editor integration; the backend still controls hardware use. Provider API.

Measure usefulness as well as hardware activity

For the GPU feature, record response time, peak VRAM, available system RAM, cancellation behavior, and whether explanations are correct. For autocomplete, also measure how often suggestions are accepted or corrected. Editor responsiveness should remain part of the result.

For the NPU feature, compare classification quality and latency with a CPU baseline. Inspect backend logs or profiling to confirm which model operations ran on the NPU; merely loading a runtime is insufficient. Claim an efficiency benefit only after measuring it under comparable conditions.

In WSL or a container, test endpoint access from the extension host. A loopback address refers to that environment, and access to a Windows-hosted service depends on the networking configuration. The endpoint setting must match where the service actually runs.

A practical development sequence

First, test local editor chat or autocomplete with the RTX. Next, create the selection-based helper for a workflow your team uses often. Then explore document retrieval or a compatible NPU image classifier as separate features.

This approach lets us build our own extension while keeping its value measurable. We can improve a specific development task, understand which processor performs the work, and expand the design as the hardware and software support justify it.