How to Run an AI Agent in a VM While Keeping the Model on the Host GPU: A Setup with Strata

An agent that installs packages, runs scripts and edits files on its own saves hours. But in effect you are giving an intern admin rights on your own laptop. One hallucination in a cleanup script, or one postinstall hook in an unfamiliar repository, and you will feel the consequences on your main system.

The obvious answer is a virtual machine. The problem is that you usually can't pass a GPU through to it, and a local model without a graphics card runs painfully slowly. A Habr write-up proposes separating the "brain" from the "hands."

How the setup works

There are three components.

The host handles inference. It runs the Strata desktop app, which exposes an OpenAI-compatible API (the default port is 47831). Untrusted code never reaches or runs on this machine.

The virtual machine in NAT mode is the sandbox. It holds VS Code and the Cline plugin, and it's where archives get unpacked, dependencies get installed and questionable scripts get run. If something goes wrong, the VM rolls back from a snapshot in about five seconds.

The network gateway forces all of the hypervisor's traffic on the host into a SOCKS proxy through Proxifier. If the code under inspection contains telemetry or a reverse connection, only the proxy's IP leaves the machine, not your home network's.

A simple example: you want to quickly examine an unknown repository from GitHub. You clone it into the VM and ask the agent to build the project and run the tests. The model does its thinking on the host's GPU, while everything is executed inside the sandbox.

Where it breaks

The most interesting part here is not the idea itself but two network traps.

First: local model servers (Strata, Ollama, LM Studio) listen only on 127.0.0.1 by default. The VM can't see them, even through the 10.0.2.2 gateway. The author solves this with Windows' built-in portproxy. A single netsh interface portproxy command forwards the port, and a firewall rule opens it. The check is simple: curl.exe 10.0.2.2:47831/v1/models run from inside the VM should return JSON with a list of models. The exact id field from that response is what you will need in Cline.

The second trap is not obvious. When the VM connects to 10.0.2.2, the packet ends up handled by the system process svchost.exe. Proxifier intercepts it and tries to send it to a local address through the remote SOCKS server. The connection hangs. The fix is an exception rule: applications — Any (precisely because the traffic goes through svchost), hosts — 10.0.2.2, 127.0.0.1, localhost and local subnets, port — 47831, action — Direct. The rule must sit above the general rule for the hypervisor. Because the port is fixed, the VM's remaining internet traffic still goes only through the proxy.

In Cline, the settings are as follows: provider OpenAI Compatible, Base URL 10.0.2.2:47831/v1, key — any non-empty word, Model ID — the name from the server's response. It makes sense to disable separate models for Plan and Act modes so you don't duplicate the config.

What to consider in practice

The isolation depends on discipline. Shared folders and the two-way clipboard are disabled in the VM, otherwise the sandbox loses its point. Never log in to personal accounts or keep real keys and tokens there: Auto-approve in Cline lets the agent do everything that is available inside the machine.

There is also a weak spot that the article doesn't cover. The portproxy command uses listenaddress=0.0.0.0, which means the port listens on all of the host's interfaces, and the firewall rule in the example does not restrict the source. If you are on a shared Wi-Fi network, it makes sense to narrow the rule to the VM's subnet with the remoteip parameter, or to bind listenaddress to the virtual adapter's address. This is our conclusion, not the author's recommendation. In addition, a VM does not offer an absolute guarantee: a hypervisor escape is rare but possible, and you will have to keep refreshing the snapshot.

The takeaway for developers: you don't need a "smart" agent, you need an agent in a cage. The setup comes together in an evening on free software and suits auditing someone else's code, examining suspicious packages and experimenting with autonomous mode. Export your Proxifier profile, and take a clean snapshot right after you verify the external IP.