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

1. Introduction: The Security vs. Performance Dilemma

Running autonomous AI coding agents natively on your primary macOS machine introduces severe security liabilities. Modern agents execute terminal commands, install unverified dependencies via pip and npm, modify arbitrary files, and can be coerced through prompt injection attacks into exfiltrating environment variables, dotfiles, or macOS Keychain secrets.

The standard industry remedy is sandboxing agents inside a Linux virtual machine or container. On Apple Silicon, however, this immediately collides with a hypervisor-level barrier:

• No Compute Passthrough: Apple's native Virtualization.framework does not expose the host Metal GPU to Linux guests. Linux VMs receive only a 2D paravirtualized framebuffer (virtio-gpu).
• The "Virtualization Tax": Attempting to run an LLM directly inside a Linux VM forces model inference onto virtualized CPU cores. Generation speeds crater by 80%+, making multi-turn agentic loops unusable.
• Containers Share the Same Limitation: Docker Desktop, OrbStack, and Colima run atop Linux guest kernels and face the exact same GPU compute void.

The Decoupled Solution: Velo Workspaces AI Bridge

Velo Workspaces resolves this trade-off by separating the agent execution environment from the model inference engine:

1. Model on the Host: An inference server — Ollama or Apple MLX — runs natively on macOS, retaining full access to unified memory bandwidth and Metal GPU acceleration.
2. Agent in the VM: The agent framework executes inside an isolated Ubuntu Linux guest, restricting all file modifications and terminal execution to a sandboxed filesystem.
3. VirtIO-vsock Transport: Traffic travels across hypervisor memory buffers via vsock rather than a traditional virtualized NAT network stack, reducing bridge overhead to single-digit milliseconds.

This guide covers both engines side by side. Pick one in Section 5 — everything downstream (VM setup, the vsock bridge, agent configuration) works identically either way, substituting the port your chosen engine listens on.

2. Architecture Topology

Network Flow Breakdown

• Inference Path: The agent sends standard OpenAI-compatible HTTP requests to 127.0.0.1:<PORT> inside the VM — 8080 for MLX, 11434 for Ollama. The local socat proxy routes this payload across vsock to the host. The Swift AI Bridge receives the connection and relays it to whichever engine you selected as the workspace's Host Provider.
• Host UI Access: The host browser connects directly to the guest's virtual interface via http://<VM_IP>:4096 over the standard hypervisor bridge.
• External LAN Access: Because external machines cannot route directly to the VM's private virtual subnet, the host forwards an external port (8081) to the guest's Web UI port (4096). Port 8081 is used to avoid colliding with whichever inference port (8080 or 11434) the host is already using.

3. Choose Your Model (Purpose and Host RAM Requirements)

Both engines use macOS Unified Memory dynamically. Because the OS, display compositor, and the model's KV cache share this pool, reserve at least 20–25% of total host RAM for operating overhead.

Model identifiers below are verified as of this writing — always confirm current availability and exact tags at huggingface.co/models?library=mlx-lm (MLX) or ollama.com/library (Ollama) before pulling, since libraries change.

* Very recent (2026) or very large releases — check the library link for the exact current tag/quantization before pulling; MLX and Ollama conversions can lag a new release by days to weeks.

4. VM Sizing Guidelines

Because the heavy LLM weights and KV caches stay in macOS unified memory, the Linux VM only needs enough resources to execute the code generated by the agent.

Important (Session Longevity): Long-running autonomous sessions gradually leak resources. Agents continuously generate temporary files, compile dependencies, bloat pip/npm caches, and retain execution logs. Allocate extra memory buffers for long-lived environments to keep the Linux Out-Of-Memory (OOM) killer from terminating tasks.

5. Install the Inference Engine on the macOS Host

Pick one engine. All steps in this section run in the macOS Terminal on the host.

5.1 Option A — MLX

Install the official Apple MLX language model package using Python (3.10+):

# 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

Launch the server bound to loopback (127.0.0.1) on port 8080. It downloads the model from Hugging Face automatically on first run. mlx-community/Qwen2.5-Coder-7B-Instruct-4bit below is just an example — swap in whichever tag you picked for your RAM tier 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 macOS terminal, verify it's responding to 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 brew install ollama). qwen2.5-coder:7b below is just an example — pull whichever tag you picked for your RAM tier in Section 3 instead:

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. Verify it's responding:

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

6. Create a VM in Velo Workspaces

1. Launch Velo Workspaces on macOS.
2. Choose AI Workspace in the sidebar, click + in the upper right.
3. Pick an image source: download an official image, choose a local OS image file, or boot from an existing virtual disk. Let's pick Ubuntu 26.04 LTS (Server or Desktop).
4. Choose the AI Sandbox profile, click "Show Advanced Settings".
5. Assign hardware parameters based on the sizing guidelines in Section 4 (e.g., 4 vCPUs, 6 GB RAM, 40 GB Disk). Ensure AI Bridge is checked and Host Provider matches whichever engine you started in Section 5 — MLX or Ollama.

Click Continue, install the guest OS, then start the virtual machine and log in.

7. Install and Configure AI Agents inside the VM

All steps in this section run in the Ubuntu Linux Terminal inside the VM. Throughout, <PORT> is 8080 for MLX or 11434 for Ollama — whichever you picked in Section 5.

7.1 Establish the Guest Vsock Proxy

Rather than typing this by hand, open the running workspace's AI Bridge tab in Velo Workspaces — it shows your exact port already filled in, with a Copy button on each command block. Run step 1, then either step 2 (forwards for the life of this terminal session — simplest, good for a quick test) or step 3 (installs it as a systemd service that survives reboots — better for anything you'll come back to):

# 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

Then, either way, verify guest-to-host connectivity across the vsock boundary:

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

If that returns your model's info, the bridge is live — every agent below points at http://127.0.0.1:<PORT>/v1, and each one configures that itself in the next section, so there's no separate global environment-variable setup needed here.

7.2 Configure Agent Frameworks

Agent Option A: OpenCode (CLI & Web UI)

OpenCode provides both an automated 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, substituting <PORT> and the model name for your chosen engine (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 in non-interactive CLI mode — --auto auto-approves tool execution inside the sandbox:

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

4. Or launch the interactive TUI, then connect via its wizard instead of (or in addition to) the config file:

   opencode

   Inside the TUI, type /connect, select Local Server, and when prompted for an API key, type anything (e.g. local) — the local server doesn't check it.
5. Or run the web interface, bound to 0.0.0.0 so it's reachable across the hypervisor network:

   opencode web --port 4096 --hostname 0.0.0.0

   From your Mac's browser: http://<VM_IP>:4096.

Accessing the Web UI from another PC on your LAN: external machines can't route directly into the VM's private subnet, so forward a port on the host. On the macOS host:

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

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

Agent Option B: Open Interpreter

Open Interpreter provides a direct terminal agent loop designed for code execution.

1. Install:

   pip install open-interpreter

2. Launch against the local endpoint — -y auto-approves code execution without a confirmation prompt each time:

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

Agent Option C: Aider

Aider is designed specifically for Git-integrated pair programming and repository modifications. It reads the endpoint from environment variables rather than dedicated CLI flags, and needs the openai/ prefix on the model name so it routes through its OpenAI-compatible path:

1. Install:

   python3 -m pip install aider-chat

2. Run 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>

Agent Option D: Goose

Goose is an extensible open-source autonomous agent developed by 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. Configure 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 autonomous run:

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

---

Related reading: the architecture behind AI Bridge, and a benchmark of what it actually costs in inference speed. Or just download Velo Workspaces and try it yourself.