comparison
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.
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.
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.
Checked against published documentation on 12 August 2026. Something out of date or unfair? The other comparisons, or this page as raw markdown: /compare/agent-sandbox-apis.md