Velo Workspaces
The actual problem this solves
Developing an agent — a RAG pipeline, a tool-calling loop, anything that lets an LLM decide what code to run next — means two things are true at once. The agent needs to execute generated code, which you don't want happening against your real filesystem and credentials while you're still finding its bugs; that's the exact risk profile covered in this blog's own security deep dive. And it needs a model to actually call, ideally fast and local, so an iteration loop isn't paying cloud API latency and cost on every single test run. The AI Sandbox profile and AI Bridge are built around exactly that split: the agent's code runs isolated inside a disposable VM, while the model stays on the host, at full native GPU speed, reached over a vsock channel rather than an internet round trip.
The AI Sandbox profile, concretely
Worth citing exact numbers rather than "sized appropriately": the AI Sandbox profile provisions 8 CPU cores, 16 GB of RAM, and 64 GB of storage — enough headroom for an agent framework and its dependencies (LangChain, a vector store, whatever tool-calling library you're using) to run comfortably alongside the guest side of the AI Bridge connection, without the model itself eating into that budget, since the model process lives on the host, not inside the sandbox.
AI Bridge supports more backends than you'd think
Earlier posts on this blog described AI Bridge as "Ollama or MLX, your choice." That undersold it. AI Bridge actually supports four provider types, each with its own default port and setup path:
| 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 | Point AI Bridge at any OpenAI-compatible endpoint already running on the host |
The practical value for research specifically: you can A/B the same agent against genuinely different serving stacks — Ollama's convenience, MLX's native Apple Silicon speed, llama.cpp's low-level control over quantization and sampling — without touching the workspace or the agent code at all, just the provider setting. And Custom means AI Bridge isn't limited to those three named options: point it at vLLM, LM Studio, text-generation-webui, or a local proxy in front of a cloud model for cost comparison, anything speaking the OpenAI-compatible API on a host port.
A real gotcha when switching backends mid-experiment
Worth knowing before it costs you a confusing debugging session: switching providers re-points AI Bridge's host-side listener on a running workspace immediately, no restart needed on the host. But the guest side is a socat forwarder unit, a file on the guest's own disk that still names the old port. A plain workspace restart doesn't fix this — the forwarder unit doesn't re-read anything on restart, since nothing about a restart touches that file. The fix is re-running the guest-side setup command again after switching providers, the same one you ran the first time, so the forwarder actually points at the new port. If a provider switch appears to do nothing, this is very likely why.
Built-in status, so you know if it's the bridge or your code
AI Bridge tracks its own connection health as one of five states — disabled, preparing, ready, degraded, or failed — with a human-readable reason for the last two, surfaced directly in the workspace UI. That matters more for agent development than it sounds: when a test run fails, checking AI Bridge's status first rules out "the endpoint itself isn't reachable" before you spend time debugging your agent's prompt or tool-calling logic instead of the actual problem.
Why disposability matters here specifically
An agent you're actively developing is exactly the thing the security deep dive is about: code whose behavior you don't fully trust yet, potentially executing shell commands or writing files based on what a model decides to do. A bad run — an agent that goes off-script, installs the wrong thing, corrupts its own working directory — costs nothing in a disposable AI Sandbox workspace. Close it, clone a fresh one from your sealed base image, and try again with the same starting state every time. That's the same disposable-workspace pattern covered for QA and DevOps, applied to a research loop where "did that fail because of my prompt or because the environment drifted" is exactly the ambiguity worth eliminating.
Related reading: the architecture behind AI Bridge, the full inference benchmark against MLX, the step-by-step MLX setup guide this post's provider table extends, what actually leaves your Mac when the Custom provider is pointed at a URL, and, for a GUI alternative to all four CLI agents above, running Continue inside VS Code Remote against the same bridge. Or download Velo Workspaces and try it yourself.