An agent that writes code needs somewhere to run it. The usual answer is "give it a server," and for a lot of agents that's more machine than the job needs. The opposite mistake is just as common: someone builds an always-on bot inside a sandbox, then wonders why it vanished overnight.
We sell both, so we see both mistakes. Here's how we'd decide.
What each one actually is
A sandbox is a Firecracker microVM. It starts in about a second, comes with Python 3.12, Node.js 22, bash and git, has outbound internet, and has no inbound ports and no SSH. You talk to it through the API, the SDK or MCP: run a command, upload a file, read the output. A single command can run up to 55 seconds; longer work runs as a background task. An ephemeral sandbox lives up to 24 hours and goes away by itself when idle.
A VPS is a regular virtual server. Root over SSH, a disk that stays, and it runs until you cancel it. On plans with their own IPv4, every inbound port is yours. On NAT plans you get one forwarded port for SSH and full outbound.
Same balance, same account, same MCP server. The difference is lifetime and reachability.
Three questions
1. Does it need to be running when nobody is asking? A Telegram bot, a trading loop, a scraper on a schedule, an agent that wakes up every ten minutes to check something. All of that is a VPS. A sandbox that sits idle deletes itself, and a persistent one billed by the hour for a whole month costs several times a small VPS.
2. Does anything need to connect to it? Webhooks, an API, an MCP server for your team, a dashboard you open in a browser. Sandboxes can't accept inbound connections at all. That's a VPS, and in practice one with its own IPv4: from $8 a month for Nano-IP.
3. Is the code something you haven't read? Output from a model, a package an agent decided to install, a pull request from a stranger. This is where a sandbox earns its keep. If the code does something nasty, it does it inside a machine that's deleted a minute later, with none of your keys inside it. Running the same thing on the VPS that also holds your bot's tokens is the bet you don't want to make.
If you answered "no, no, yes", use a sandbox. "Yes" to either of the first two means a VPS. Plenty of agents land on "yes, maybe, yes", and those should use both.
Where the money crosses over
Sandboxes are billed per second of allocated vCPU and RAM, with a 60-second minimum. VPS plans are flat monthly prices. With current prices:
| Sandbox tariff | Per hour | Comparable VPS | Monthly | Break-even |
|---|---|---|---|---|
| small (0.5 vCPU, 1 GB) | $0.033 | Nano (2 vCPU, 1 GB, NAT) | $3 | ~91 h |
| standard (1 vCPU, 2 GB) | $0.066 | Micro (2 vCPU, 2 GB, NAT) | $5 | ~76 h |
| plus (2 vCPU, 4 GB) | $0.132 | Small (4 vCPU, 4 GB, NAT) | $8 | ~61 h |
So if your agent's code runs a few minutes per task, even hundreds of tasks a month cost cents in sandboxes. Once the total climbs past about three hours a day, the VPS is cheaper, and it's a lot cheaper at 24/7: a standard sandbox kept persistent for a full month is capped at $36.14, against $5 for Micro.
The rows aren't exact twins: the VPS has more vCPU and a bigger disk, and the NAT plans can't take inbound connections. For "where does my code run," which is the question here, it's a fair comparison.
The setup we'd actually recommend
For an agent that does real work, both:
- A VPS as the agent's home. It runs the agent loop, holds its memory and its API keys, and exposes whatever needs exposing. Nano at $3 is enough for an agent that calls a hosted model; anything doing local inference needs much more.
- A sandbox per untrusted task. The agent writes code, sends it to a fresh microVM, reads the result and throws the machine away. A sandbox gets no secrets it doesn't need.
Both are reachable from the same MCP connection, so the agent decides per task. Set a sandbox spending cap before you let it loose. A loop that spawns sandboxes forever gets refused at the cap instead of draining the balance.
When this advice is wrong
If you already run untrusted code inside containers on your own server and you're happy with that boundary, a separate sandbox may feel redundant. It depends on how much you trust the code. Our comparison of isolation levels goes into what a container does and doesn't stop.
If the agent writes whole apps rather than snippets, a third option sits between the two: a VPS that turns each branch it pushes into a preview with its own URL.
And if the agent only ever calls APIs and never executes anything it wrote, you need neither a sandbox nor much of a server. A $3 VPS running the loop is plenty.
Next steps: sandboxes start at $0.0165 an hour (a new account with a confirmed email gets a one-time $1 credit for its first sandbox, valid 14 days), and VPS plans start at $3 a month. If the agent will manage its own server, read what it does after the order.
Comments
No comments yet. Be the first.