Velo Workspaces
The problem this solves
Developing an agent, whether a RAG pipeline, a tool-calling loop or anything else that lets a model decide what code runs next, means two things at once. The agent runs generated code, which you don't want touching your real files and credentials while you're still finding its bugs; that's the risk covered in the security deep dive. And it needs a model to call, ideally fast and local, so each iteration doesn't pay cloud latency and fees. The AI Sandbox profile and AI Bridge are built around that split: the agent's code runs in a disposable VM, and the model stays on the Mac at full GPU speed, reached over vsock rather than the internet.
The AI Sandbox profile
The AI Sandbox profile starts at 8 CPU cores, 16 GB of memory and 64 GB of storage, and turns AI Bridge on. That's room for an agent framework and its dependencies (LangChain, a vector store, your tool-calling library) without the model eating into it, because the model runs on the Mac, not in the sandbox. You can change any of it under Advanced Settings when you create the workspace. The quickest way to one is Cloud image › Ubuntu 26.04 LTS, ready about a minute after it downloads.
AI Bridge supports more backends than you'd think
Earlier posts described AI Bridge as "Ollama or MLX". It supports four provider types, each with its own default port:
| Provider | Default port | Setup |
|---|---|---|
| Ollama | 11434 | ollama serve, then ollama pull <model> |
| MLX | 8080 | pip install mlx-lm, then python -m mlx_lm.server --model <model> |
| llama-server | 8080 | Build or install llama.cpp, then llama-server -m <model.gguf> --port 8080 |
| Custom | your choice | Any OpenAI-compatible endpoint already running on the Mac |
For research, that means you can compare the same agent across different serving stacks (Ollama's convenience, MLX's Apple silicon speed, llama.cpp's control over quantization and sampling) without touching the workspace or the agent's code, only the provider setting. Custom opens it further: vLLM, LM Studio, text-generation-webui, or a local proxy in front of a cloud model for cost comparisons, anything speaking the OpenAI-compatible API on a port on the Mac.
A gotcha when switching backends mid-experiment
Switching providers moves AI Bridge's listener on the Mac immediately, with no restart. But the guest side is a socat service, a file on the guest's disk that still names the old port, and restarting the workspace doesn't change it. Run the guest-side setup command from the workspace's AI Bridge tab again after you switch, so the forwarder points at the new port. If a provider switch seems to do nothing, this is almost certainly why.
Built-in status, so you know whether it's the bridge or your code
AI Bridge reports its own health as one of five states (disabled, preparing, ready, degraded or failed), with a readable reason for the last two, shown in the workspace. That saves time in agent work: when a run fails, a glance at the bridge's status rules out "the endpoint isn't reachable" before you start debugging your prompt or tool-calling logic.
Why disposability matters here
An agent under development is exactly what the security deep dive is about: code you don't fully trust yet, running shell commands and writing files based on what a model decides. A bad run, an agent that goes off-script, installs the wrong thing or wrecks its working directory, costs nothing in a disposable workspace. Close it, clone a fresh one from your saved base image, and try again from the same starting point. It's the disposable-workspace pattern from QA and DevOps, applied to a research loop where "did that fail because of my prompt or because the environment drifted?" is the question you most want to rule out.
Related reading: the architecture behind AI Bridge, the inference benchmark with MLX, the MLX setup guide, what leaves your Mac when the Custom provider points at a URL, and Continue in VS Code over the same bridge for an editor-based alternative. Or download Velo Workspaces and try it yourself.