Zero-Tax Virtualization: Running AI Agents Safely in Velo Workspaces

1. The problem: safety or speed

Running an autonomous AI coding agent directly on your Mac is a real risk. Agents run terminal commands, install unvetted packages with pip and npm, change files anywhere they can reach, and can be steered by prompt injection into sending off environment variables, dotfiles or Keychain secrets. These aren't hypotheticals; dated 2026 incidents cover each one.

The usual remedy is to run the agent in a Linux VM or container. On Apple silicon that runs straight into a platform limit:

• No GPU for Linux guests. Apple's Virtualization framework doesn't give Linux guests the Mac's Metal GPU, only a paravirtualized display (virtio-gpu).
• The "virtualization tax". Run the model inside the VM and inference falls back to CPU cores. Published CPU-versus-GPU benchmarks commonly show a 12× to 47× slowdown for the same model, mostly because CPU memory bandwidth is far below the GPU's. That's not slower; it's unusable for a responsive agent loop.
• Containers have the same limit. Docker Desktop, OrbStack and Colima all run on a Linux guest kernel with the same missing GPU.

The fix: split the agent from the model

Velo Workspaces' AI Bridge separates the place the agent runs from the engine that runs the model:

1. The model stays on the Mac. An inference server, Ollama or Apple MLX, runs natively on macOS with full unified memory bandwidth and Metal acceleration.
2. The agent runs in the VM. Its file changes and commands are confined to an isolated Ubuntu guest.
3. vsock carries the traffic. Requests cross the VM boundary over a virtio socket rather than a virtual network stack. Kernel-level vsock benchmarks put the core transport path at roughly 8 to 23 microseconds. The end-to-end cost on real inference requests is measured in the benchmark and the sandboxing-cost comparison: single-digit percent.

This guide covers both engines. Pick one in section 5; everything after that (the VM, the bridge, the agents) works the same, with the port your engine listens on.

Since Ollama 0.19 (March 2026), Ollama itself runs on MLX on Macs with 32 GB or more of unified memory, so on that hardware the two are less separate than they used to be.

2. How the pieces connect

Click to enlarge

The three network paths

• Inference: the agent sends standard OpenAI-compatible HTTP requests to 127.0.0.1:<PORT> inside the VM (8080 for MLX, 11434 for Ollama). A small socat proxy carries them over vsock to the Mac, where AI Bridge relays them to the engine you picked as the workspace's Host Provider.
• Web UI from your Mac: the Mac's browser connects straight to the guest at http://<VM_IP>:4096.
• Web UI from another computer: other machines can't route into the VM's private subnet, so the Mac forwards port 8081 to the guest's 4096. 8081 avoids clashing with the inference port the Mac is already using.

3. Choose a model for your Mac's memory

Just want to run a model on its own first, with no VM or agent? The basics are covered separately. This section assumes you're heading for the full setup.

Both engines draw on macOS's unified memory. The OS, the display and the model's KV cache share that pool, so keep at least 20 to 25% of the Mac's RAM free for everything else. How much RAM you need goes deeper.

The model names below were checked when this was written. Libraries change, so confirm the current tag at huggingface.co/models?library=mlx-lm (MLX) or ollama.com/library (Ollama) before pulling.

* Very recent or very large releases. Check the library for the exact current tag and quantization before pulling; MLX and Ollama conversions can lag a new release by days or weeks.

4. Size the VM

The model's weights and KV cache stay in the Mac's memory, so the Linux VM only needs enough to run the code the agent produces.

For long sessions: autonomous sessions slowly pile things up: temporary files, compiled dependencies, growing pip and npm caches, logs. Give long-lived workspaces extra memory so the Linux out-of-memory killer doesn't end a task halfway.

5. Install the inference engine on the Mac

Pick one engine. Everything in this section runs in Terminal on your Mac.

5.1 Option A: MLX

Install Apple's MLX language model package with Python 3.10 or later:

# Create and activate an isolated virtual environment
python3 -m venv ~/.mlx-env
source ~/.mlx-env/bin/activate

# Install the MLX LM server package
pip install --upgrade mlx-lm

Start the server on the loopback address, 127.0.0.1, port 8080. It downloads the model from Hugging Face on first run. mlx-community/Qwen2.5-Coder-7B-Instruct-4bit is only an example; use the tag you chose in section 3:

mlx_lm.server \
  --model mlx-community/Qwen2.5-Coder-7B-Instruct-4bit \
  --host 127.0.0.1 \
  --port 8080

In a second Terminal window, check that it answers OpenAI-compatible requests:

curl -s http://127.0.0.1:8080/v1/models | grep "id"

5.2 Option B: Ollama

Install Ollama from ollama.com or with Homebrew. qwen2.5-coder:7b is only an example; pull the tag you chose in section 3:

brew install ollama
ollama serve &          # or just launch the Ollama app — it runs this for you
ollama pull qwen2.5-coder:7b

Ollama listens on 127.0.0.1:11434 by default. Check that it answers:

curl -s http://127.0.0.1:11434/v1/models | grep "id"

6. Create the workspace in Velo Workspaces

1. Open Velo Workspaces, choose AI Workspace in the sidebar, and click + in the upper right.
2. Choose Cloud image and pick Ubuntu 26.04 LTS. It's ready about a minute after it downloads, with no installer to click through. (Prefer a desktop? Choose Installer image and Ubuntu Desktop with Automatic installation on.)
3. On the Configure step, choose the AI Sandbox profile and open Show Advanced Settings. Set CPUs, memory and disk from section 4 (for example 4 vCPUs, 6 GB of memory and a 40 GB disk). Make sure AI Bridge is on and Host Provider matches the engine you started in section 5, MLX or Ollama.
4. Enter a username and password for the workspace, check the summary, and click Create Workspace.

Click to enlarge

When the workspace shows it's ready, open its Access tab. With Pro, Open Terminal signs you in over SSH with no password. You can also copy the ssh command into Terminal, which uses your own SSH key (add your public key under SSH Public Keys when you create the workspace), or sign in at the console.

7. Set up the agents inside the VM

Everything in this section runs in the Ubuntu terminal inside the VM. Throughout, <PORT> is 8080 for MLX or 11434 for Ollama, whichever you chose in section 5.

7.1 Start the vsock proxy in the guest

You don't need to type this out. Open the running workspace's AI Bridge tab in Velo Workspaces: it shows these commands with your port filled in and a Copy button on each. Run step 1, then either step 2 (forwards for as long as that terminal is open; simplest for a quick test) or step 3 (installs a systemd service that survives reboots; better for anything you'll come back to):

Click to enlarge

# 1. Install socat
sudo apt-get install -y socat

# 2. Forward the port for this session
socat -d -d TCP-LISTEN:<PORT>,fork,reuseaddr,bind=127.0.0.1,nodelay VSOCK-CONNECT:2:<PORT>

Or, to keep it running across reboots:

# 3. Install as a systemd service instead of step 2
sudo tee /etc/systemd/system/velo-ai-bridge.service >/dev/null <<'EOF'
[Unit]
Description=Velo Workspaces AI Bridge (127.0.0.1:<PORT> to the host over the high speed channel)
After=network.target

[Service]
ExecStart=/usr/bin/socat TCP-LISTEN:<PORT>,fork,reuseaddr,bind=127.0.0.1,nodelay VSOCK-CONNECT:2:<PORT>
Restart=always
RestartSec=2

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable velo-ai-bridge
sudo systemctl restart velo-ai-bridge

Either way, check that the guest can reach the Mac across vsock:

# 4. Check it from inside the workspace
curl -sS http://127.0.0.1:<PORT>/v1/models

If that returns your model, the bridge is live. Every agent below points at http://127.0.0.1:<PORT>/v1 and sets that up itself, so there are no global environment variables to set here.

7.2 Configure an agent

Option A: OpenCode (CLI and web UI)

OpenCode offers both a CLI agent and an interactive web workspace.

1. Install OpenCode and its build dependencies:

   sudo apt install -y curl git build-essential
   curl -fsSL https://opencode.ai/install | bash
   source ~/.bashrc

2. Register your inference engine as a provider. Create ~/.config/opencode/opencode.json:

   mkdir -p ~/.config/opencode
   nano ~/.config/opencode/opencode.json

   Paste this, with your <PORT> and the model name from section 3:

   {
     "$schema": "https://opencode.ai/config.json",
     "provider": {
       "local": {
         "npm": "@ai-sdk/openai-compatible",
         "name": "Local Server",
         "options": {
           "baseURL": "http://127.0.0.1:<PORT>/v1"
         },
         "models": {
           "<model-name>": {
             "name": "<Display Name>"
           }
         }
       }
     },
     "model": "local/<model-name>"
   }

3. Run it non-interactively. --auto approves tool use inside the sandbox:

   opencode run --auto "Write a python script to benchmark disk I/O, execute it, and print the results."

4. Or open the interactive TUI and connect through its wizard instead of, or as well as, the config file:

   opencode

   In the TUI, type /connect and select Local Server. When it asks for an API key, type anything (for example local); the local server doesn't check it.
5. Or run the web interface, bound to 0.0.0.0 so your Mac can reach it:

   opencode web --port 4096 --hostname 0.0.0.0

   Then open http://<VM_IP>:4096 in your Mac's browser.

Opening the web UI from another computer on your LAN: other machines can't route into the VM's private subnet, so forward a port on the Mac:

brew install caddy
caddy reverse-proxy --from :8081 --to <VM_IP>:4096

Any machine on the LAN can then open http://<HOST_IP>:8081.

Option B: Open Interpreter

Open Interpreter is a terminal agent loop built for running code.

1. Install:

   pip install open-interpreter

2. Launch it against the local endpoint. -y runs code without asking each time:

   interpreter \
     --api_base http://127.0.0.1:<PORT>/v1 \
     --model <model-name> \
     --api_key local \
     -y

Option C: Aider

Aider is built for Git-aware pair programming. It reads the endpoint from environment variables rather than flags, and needs the openai/ prefix on the model name so it uses its OpenAI-compatible path:

1. Install:

   python3 -m pip install aider-chat

2. Run it inside a Git repository:

   cd /path/to/project
   export OPENAI_API_BASE=http://127.0.0.1:<PORT>/v1
   export OPENAI_API_KEY=local
   aider --model openai/<model-name>

Option D: Goose

Goose is an extensible open-source agent from Block.

1. Install:

   curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash
   export PATH="$HOME/.local/bin:$PATH"

2. Add a custom OpenAI-compatible provider:

   goose configure
   # Select: Add Provider → Custom / OpenAI-compatible
   # Base URL: http://127.0.0.1:<PORT>/v1
   # API Key:  local
   # Model:    <model-name>

3. Start a one-shot run:

   goose run --text "Audit this directory, find security misconfigurations in JSON files, and correct them."

8. Keep it disposable

Once the agent works the way you like, stop the workspace and save it as a base image (Pro). From then on, start each agent task in a disposable workspace cloned from it: the agent gets a clean system every time, and closing the workspace deletes whatever it did. The safe agent environment checklist covers the rest.

---

Related reading: the architecture behind AI Bridge, a benchmark of what it costs in inference speed, and, if you'd rather not use a terminal agent, the same setup with VS Code Remote and the Continue extension. Or just download Velo Workspaces and try it yourself.