Every "where should my agent run" guide compares these on the wrong axis. They benchmark cold starts and quote per-second GPU rates, as if an agent were a web server that needs to answer fast. It isn't.

A long-running agent spends almost all of its life waiting. It fires a tool call and waits for the API. It kicks off a job and waits for the webhook. It asks a human for approval and waits, sometimes for a day. In between those waits it computes for a few seconds. So the backend question that actually decides your bill and your reliability is: what happens during the idle, and what does the idle cost?

Read Modal, Cloudflare Containers, and Fly Machines through that lens and they stop looking like competitors. They're three different answers to how an agent should sit still.

Modal is Python-native serverless. You decorate a function, and Modal runs it across zero-to-hundreds of containers on demand, billing per second only while it runs. Cold starts are sub-second for CPU and a few seconds for a typical GPU model. It also ships Sandboxes — isolated environments purpose-built for running untrusted or agent-generated code.

Its idle model is the purest: between calls, there's nothing running, so there's nothing to pay for. That's ideal for the compute bursts — the GPU inference, the parallel fan-out, the heavy transform. It's a worse fit for the waiting part, because a serverless function isn't a place to park a single stateful process that must stay alive across a multi-hour wait. Reach for Modal when your agent's hard part is GPU or bursty parallelism and you live in Python.

Cloudflare Containers — idle at the edge, tied to a Worker#

Cloudflare Containers run at the edge, started and routed to by a Worker. They bill only while active — metered per 10ms — and go to sleep after an inactivity window you set with a sleepAfter parameter. They require the Workers Paid plan at $5/month.

Their idle story is "sleep, and the Worker wakes you." That's a great fit when your agent is mostly glue around the Cloudflare stack: Workers for the loop, Durable Objects for state, KV/Queues for the plumbing, and a Container for the occasional job that needs a real Linux process. You get global placement and almost no ops. The cost of that is platform commitment — you're building inside Cloudflare's model — and the edge is not where you want a long, CPU-heavy grind.

The three backends barely overlap. Modal scales the compute to zero; Fly freezes the process and thaws it; Cloudflare sleeps a container and lets a Worker wake it. Pick the idle you want.

Fly Machines — freeze the whole process, resume it intact#

Fly Machines are fast-booting micro-VMs with autostop/autostart and, the part that matters for agents, suspend/resume. A stopped or suspended Machine bills nothing for CPU and RAM — you pay only a few cents per GB-month for the parked root filesystem. A suspended Machine keeps its memory, so it comes back mid-run without re-warming anything.

That's the most agent-shaped idle of the three: your orchestration loop is a single stateful long-lived process, and Fly lets you freeze it while it waits and thaw it when the next event arrives — without the "reconstruct the whole run from a checkpoint" dance. The tradeoff is that you're closer to operating a VM than calling a function; you own more of the lifecycle. Reach for Fly when the durable, mostly-idle heart of your agent is a process you want to suspend and resume.

So which one#

BackendIdle behaviorBills you whenReach for it when
ModalScales to zero between callsPer-second while runningGPU / bursty compute, Python-first, agent-code Sandboxes
Cloudflare ContainersSleeps after sleepAfterPer 10ms active (Workers Paid $5/mo)Glue around Workers/DO/KV; global, near-zero ops
Fly MachinesAutostop, or suspend with RAM intactPer-second running; parked ≈ $0.15/GB-mo diskStateful process you freeze mid-run and resume

And you don't have to choose only one. A common mature shape: a Fly Machine or Cloudflare Container holds the long-lived, mostly-idle loop, and it calls out to Modal for the rare GPU-heavy step. The comparison here is about where the long-lived part lives — the process that has to survive the waits.

Whichever you pick, remember what you're actually optimizing. Not requests per second. The hours your agent spends doing nothing, correctly, cheaply — and waking up intact when the world finally answers. And if the wait you're pricing is a durable runtime's steps, note that some of those idle waits are now billed as steps too.