If your agent writes and runs code, host it in a sandbox platform that gives each run an isolated machine. If it works through long, multi-step jobs that can fail halfway, host it on a durable execution runtime that picks up after a crash; general compute platforms with sandboxes suit teams that also serve their own models on GPUs.
Two jobs hide under one label
An agent that writes and runs code needs a sandbox: a walled-off machine where whatever the model produced can run without touching your own servers. An agent that works through a long chain of steps, calling tools, waiting on an API or pausing for a person, needs a durable execution runtime that records each step and carries on after a crash. Plenty of teams end up needing both, and that's fine, but they're different products guarding against different failures.
A sandbox protects you from the agent. Code generated by a model is untrusted code by definition: it can loop forever, fill a disk, pull in a package you've never heard of or go looking for secrets it shouldn't see. The sandbox gives it its own file system and processes, and when the job ends you can throw the machine away. Billing follows that shape. It's usually charged per second of active compute, and some runtimes suspend an idle box so the quiet minutes don't count.
A durable runtime protects the agent from the world. Picture an agent that books a meeting, waits two days for a reply and then updates a CRM. Somewhere in those two days it'll meet a deploy, a timeout or a rate limit. Durable execution writes down every completed step, so when the process dies it resumes from the last one instead of starting over and sending the same email twice. You pay per action or per execution, which suits jobs that spend most of their life waiting.
Between the two sits general compute that has added sandboxes, VMs and GPU endpoints with agents in mind. It earns its place when the same team serves its own model and runs the agent's tools, and would rather have one bill. Calls going out to outside model providers are a separate concern again; if you're juggling several, an AI gateway can sit in front of whichever host you choose.
A one-hour trial: deploy one real agent and break it
Choose the type that matches the failure you're most worried about, shortlist two vendors of that type and put the same agent on each. A toy example will pass everywhere, so use the agent you plan to ship, with its real tools and a test account for anything it writes to.
- Deploy it from a clean machine using only the vendor's docs, and stop the clock at fifteen minutes. If you're editing config nobody mentioned by minute ten, every new developer on your team will hit the same wall.
- Give it a task where it runs code it wrote itself, and have that code try to print an environment variable holding a fake secret. If the secret comes back, the box is set up wrong. The usual slip is passing production keys into the sandbox because it was quicker.
- Kill the process halfway through a multi-step job. A durable runtime should resume at the next unfinished step without repeating one that already sent something. A sandbox will usually start the run again, so check your agent won't double-send when that happens.
- Leave everything idle for twenty minutes, then open the usage page. Idle time should be suspended or billed at almost nothing; a meter still ticking on a quiet box is a bill you'll pay every night.
- Make one step wait on something slow, such as a webhook or a human approval, and watch how the platform holds it. Keeping a sandbox alive just to wait means paying by the second for nothing, which is exactly the job durable runtimes were built for.
- Launch ten copies at once and look for cold starts, queueing and any cap on concurrent sandboxes or executions. Write down where it bent, because that limit is what you'll be negotiating later.
- Open the logs for the run you killed and explain, from the trace alone, what the agent did and why it stopped. If you can't, an incident in the middle of the night won't go any better.
Whichever platform comes out ahead in that hour is the one to pilot. If both pass, take the one whose logs you understood fastest, since that's where you'll spend your worst afternoons.
What shifted in agent hosting this year
The lines between the types are blurring. Durable execution vendors have started adding sandboxes of their own, one of them still in beta, and general compute providers now pitch isolated environments for coding agents and untrusted code next to their GPUs. Meanwhile a few names that used to sell agent hosting have moved on to selling finished agents to small businesses, so a shortlist copied from last year's posts will have gaps in it.
Self-running has become a serious fork too. Several durable runtimes here are open source with a hosted cloud on top, one offers bring-your-own-cloud, and one sandbox vendor will deploy into your own VPC. If your data can't leave your network, that narrows the field quickly, and it's worth asking about before the trial rather than after.
Sandboxes and compute where the agent's code runs
E2B
When every agent needs its own isolated cloud machine to work on, this small sandbox service is built around exactly that job.
Daytona
Elastic, security-minded sandbox infrastructure aimed squarely at running code an AI model wrote, which is the risky part of most coding agents.
Blaxel
Autonomous agents that need sandboxes, batch jobs and somewhere to host MCP servers can get all three from this one infrastructure provider.
Runloop
Micro-VM devboxes for building and running agents, with a VPC deploy option for teams who want the environment inside their own network.
Beam
A compute platform pitched at agents, covering sandboxes, full VMs, functions and GPU endpoints under one roof.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
Modal
Teams running production AI workloads here can also spin up isolated environments for coding agents, RL rollouts and untrusted code.
Durable runtimes for long agent jobs
Restate
A durable runtime for agents and backends that you can use as a cloud service, in your own cloud account or as open source.
Inngest
Durable execution and queues for workflows and AI agents, with sandboxes in beta for teams who'd like both halves from one vendor.
Trigger.dev
For background tasks and durable AI agents, this open-source platform can be run on your own servers or used as a hosted service.
Temporal
Open-source durable execution with a hosted cloud, used to add agent steps to existing applications whichever framework you build with.
What hosting an agent costs
The two types bill in different currencies. Sandboxes and compute platforms charge for time: by the second for CPU and memory, by the hour for a GPU, often with a monthly plan that raises your limits and then adds usage on top. Durable runtimes charge per action or per execution, with an allowance on the entry plan and, further up, a rate per million actions.
That's why one range across the whole list would mislead you. Flat monthly plans, where a pricing page shows one, run from around ten dollars to a few hundred dollars a month, often with usage added; the rest quote by the second, the hour or the million actions, which won't turn into a monthly figure until you know your own traffic.
The bills that hurt come from somewhere else: a sandbox left running overnight, a retry loop that re-runs a whole job instead of one step, or a GPU kept warm for traffic that never arrived. The idle test in the trial tells you more about next quarter's spend than any pricing page will.
Do you make agent hosting platforms or sandboxes for AI agents? Tool makers can ask to be considered for a featured place on this list.
Which type to pick
Coding agents, data analysis agents and anything else that executes model-written code belong in a hosted sandbox; pick the one that passed the secret test and cost least while idle. Agents that run for minutes or days, wait on people and touch outside systems belong on a durable runtime, and if they have to stay in-house, start with the open-source ones. If you serve your own models as well, a general compute platform with sandboxes saves you running two vendors. And if you haven't settled how the agent itself is built, compare AI agent frameworks first, because the framework decides what the host has to run.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
