Compare · situations
Start with what the agent has to do. Each situation names the feature pages that decide it, then two or three providers worth a look. Every recommendation carries its catch.
What will your agent do? It should answer whenever I message it.
This is the hardest case, because most providers assume a machine that is used in bursts. You need a machine that does not hit a lifetime deadline, does not sleep when nobody is typing, and wakes if it does sleep. Then you need the idle hour to be cheap enough to leave running.
Idle timers, waking and session limits — An always-available agent depends on three separate settings: a lifetime deadline, an idle timer, and a wake path. Providers bundle them differently, and the difference is most of your bill.
Lifecycle: stop, pause and sleep — Providers use seven words for four behaviours. The only question that matters is what is still running when the machine comes back.
Reaching it: links, ports and who can open them — A machine nobody can reach is not an agent. There are four doors in — an HTTPS link, a raw TCP port, SSH, and the provider's API — and the important difference is who can open each one.
Billing models — The meter decides your bill more than the hourly rate does. Four shapes are in play: flat per size, per vCPU and per GB, a plan fee that returns as credit, and measured CPU.
Auto-sleep is off by default and there is no lifetime cap. Its managed-hosting line is a one-click personal agent with a task board, and the Cloud 4 vCPU / 8 GiB shape is about $10.60 a month with 20 GB of disk.
Catch: The Cloud product needs a terminal or API call, stop loses memory, and disk bills until you delete the instance.
Pause keeps the agent's session and bills storage only, and the dashboard creates the machine and opens a clickable desktop.
Catch: The free plan caps continuous runtime at 8 hours and pauses after 30 idle minutes; public URLs have no password.
persistent: true disables the idle pause, and measured CPU with a 50-millicore floor makes a waiting agent cost about $0.03 an hour in CPU.
Catch: A stopped box still bills storage, there is one US region, and there is no preinstalled agent.
What will your agent do? It runs builds, training runs or multi-hour tasks.
Long jobs fail on timers, not on compute. Look for a hard deadline you can turn off, an idle timer that watches the network rather than the CPU, and a machine that does not lose its work when a connection drops.
Idle timers, waking and session limits — An always-available agent depends on three separate settings: a lifetime deadline, an idle timer, and a wake path. Providers bundle them differently, and the difference is most of your bill.
Lifecycle: stop, pause and sleep — Providers use seven words for four behaviours. The only question that matters is what is still running when the machine comes back.
Isolation: what kind of computer you get — Every provider says “sandbox”. Underneath, it is a container, a gVisor container, a microVM or a full virtual machine, and that decides what your agent can install, run and break.
Sizes, regions and hardware — A size is a bundle of CPU, memory and disk, and the bundle decides what you can run. A region decides how far away it is and whose laws it sits under. Neither is as flexible as the word “cloud” suggests.
A full Ubuntu VM with Docker and 51 GB of disk for $26.28 a month, and no idle detection at all.
Catch: Auto-stop counts from creation and defaults to one hour; turn it off. The disk is deleted 14 days after a stop.
Auto-suspend is off by default and the idle timer counts TCP/UDP traffic in either direction, so a build that polls an API stays awake. Docker, systemd and kernel modules work.
Catch: A purely local compile makes no traffic and hibernates at four hours; set the timer to 0. RAM bills on resident memory.
A Firecracker microVM with a 24-hour continuous limit on Pro and snapshots that keep memory.
Catch: The default timeout is five minutes and kills the sandbox; commands do not reset it. Hobby caps continuous runtime at one hour.
What will your agent do? It sits idle most of the day and answers a few requests.
Here the bill is decided by the idle state, not the busy hour. You want a provider whose sleeping machine is nearly free, and a wake path that does not need a person.
Idle timers, waking and session limits — An always-available agent depends on three separate settings: a lifetime deadline, an idle timer, and a wake path. Providers bundle them differently, and the difference is most of your bill.
Billing models — The meter decides your bill more than the hourly rate does. Four shapes are in play: flat per size, per vCPU and per GB, a plan fee that returns as credit, and measured CPU.
Trials and free tiers — “Free trial” covers four different offers: a time-limited trial that converts, a one-off credit, a free plan that never charges, and a recurring allowance. They differ in what you get and what happens on day eight.
Reaching it: links, ports and who can open them — A machine nobody can reach is not an agent. There are four doors in — an HTTPS link, a raw TCP port, SSH, and the provider's API — and the important difference is who can open each one.
CPU is measured with a 50-millicore floor, so an idle-but-running box costs about $0.03 an hour, and a paused box costs storage only.
Catch: An open terminal or SSH session counts as activity and keeps billing; a stopped box still bills storage.
Stopped time is free and a resume can restore the running processes, so a request can find the session as it was.
Catch: The default TTL is one hour and the trial converts to $20 a month; memory restore needs a matching machine within two minutes.
An idle instance bills disk only at $0.09 per GB-month, and a sleep checkpoint keeps memory at no extra charge.
Catch: Any request to any URL wakes a sleeping instance, and a stop discards the checkpoint.
What will your agent do? It writes code, runs tests and needs a clean environment each time.
This case rewards fast copies and a real Linux machine: Docker, system tools, and a way to snapshot a working environment and start ten more from it. Session limits matter less because each job is short.
Isolation: what kind of computer you get — Every provider says “sandbox”. Underneath, it is a container, a gVisor container, a microVM or a full virtual machine, and that decides what your agent can install, run and break.
Snapshots, forks and templates — Four jobs hide under “snapshot”: a restore point on one machine, a reusable image for new machines, a copy of a running machine, and a backup that survives losing the host. Ask which one you are getting.
Sizes, regions and hardware — A size is a bundle of CPU, memory and disk, and the bundle decides what you can run. A region decides how far away it is and whose laws it sits under. Neither is as flexible as the word “cloud” suggests.
Built-in agents — Some providers ship the machine with coding agents already installed and a way to prompt them. Others ship a computer and expect you to bring the agent.
A live fork copies memory and disk in 100–200 ms, snapshots boot machines already running, and Docker is preinstalled.
Catch: The 4 vCPU size comes with 16 GiB and RAM bills on resident memory, so the bill depends on what the build holds.
Snapshots capture memory and disk and can branch into many running instances, which is built for parallel test fan-out.
Catch: Stop deletes the instance; volumes are S3-compatible object storage, not an attached disk.
Templates can start from any Docker image, and up to 20 forks can be created from a running sandbox.
Catch: Forking pauses the source and drops its connections; the default timeout kills a sandbox after five minutes.
The reasoning behind each pick is on the feature pages, with a source for every claim. Prices are list prices checked on 28 October 2026.