# reachpad vs an agent sandbox API

> These get compared to us constantly and they should not be. A sandbox API is infrastructure your product calls; a reachpad workspace is somewhere a person and their agent work. The confusion is understandable and the choice is usually obvious once it is named.

Part of the reachpad comparisons: https://reachpad.dev/compare. Rendered page: https://reachpad.dev/compare/agent-sandbox-apis. Last checked 2026-08-12.

## Side by side

|  | A sandbox API | reachpad |
| --- | --- | --- |
| Who creates the machine | Your application, over an SDK, once per task | You, once, and you keep it |
| Who is inside it | Nobody. Code runs and the result is returned | You and your agents, in a terminal |
| Expected lifetime | Seconds to hours; ephemeral by design | As long as you want it; sealed and resumed when idle |
| What it optimises | Cold start and isolation, measured in milliseconds | Continuity: the workspace you left is the one you get back |
| Who it is sold to | The engineer building an AI product | The engineer whose agent is doing their work |

## When a sandbox API is the right answer

When your product runs code your users wrote, or code a model wrote for your users, and you need it contained, fast to start and gone afterwards. That is a genuinely hard problem and the companies above are good at it. Nothing about reachpad competes with it: we do not sell an SDK that spawns a machine per request, and building a consumer product on top of one workspace per customer would be the wrong shape.

Reach for reachpad when the machine is not an implementation detail. If a person attaches to it, if it accumulates state worth keeping, if closing the laptop should not end anything, that is this product.

> Note: Isolation is not the axis. A reachpad workspace is an isolated Linux VM and takes that as seriously as a sandbox vendor does; the question separating the two products is not whether the machine is contained, it is whether anyone is sitting inside it.