Computers Compared · Fly

Open main menu

Computers Compared

C.S. Peirce said: "Truth is the opinion fated to be agreed on by all who investigate", and we can reasonably assume his agent didn't come up with that for him.

Over the past year or so, Mr Peirce's sentiment has pretty much defined the agent infra space. We were all using the tools we know and putting agents in environments that conventional wisdom told us were appropriate for the work they had to do and the security threats they represented. Ephemeral was fine.

But deep down, we knew it wasn't. With every hour we spent tinkering with agent plumbing instead of using them, the feeling began to compound. We could see the unprecedented capabilities of agents and the opportunities they represented, but only in brief windows. Because sandboxes were never right for agents.

Agents need computers.

Fly.io first shared our opinion on the matter with the release of Sprites in early '26. In the last six months, the whole industry seems to have converged on "computers for agents" and when that happens, it's usually an attempt to get a word to do all the work that a product should.

That's not the case here though. In the space as we see it today, there are several divergent and entirely defensible engineering approaches to building computers for agents. Trying to identify one as correct or "better" than any other is marketing drivel at this point. So rather than trying to dress this up like a totally objective comparison that we somehow inevitably win, this post has 3 objectives:

Explain what we think computers for agents should be

Explain what our competitors think they should be

Explain why our opinion is our opinion

A definition

At its foundation, we believe a computer for an agent must do four boring things. We're going to hold every platform mentioned here against these:

A computer keeps your files

A computer keeps running your programs

A computer answers at an address

A computer can log into things on your behalf without handing over your keys

A computer keeps your files

Obviously. Which is why everyone does it now. Progress! Two years ago the entire category was stateless and proud of it.

E2B preserves the filesystem and the memory on pause, keeps paused sandboxes indefinitely with no TTL, and lets you disable memory capture if you only want the disk. Blaxel keeps filesystem and process state through standby. Vercel made persistence the default earlier this year, with snapshots and Drives on top. Daytona graduated forking and snapshots to stable. Northflank will give you a volume between 4GB and 64TB.

So everyone gives you file storage, the difference is the retention policy. Modal's memory snapshots are alpha, capped at seven days, and the cap is not extendable. Its filesystem and directory snapshots expire after thirty days by default. Vercel's snapshots expire thirty days after last use. Those are all defensible engineering decisions and they are all, structurally, a countdown on your environment.

Blaxel's default filesystem is tmpfs sized at roughly half your available memory. It's fast, and it's the default, and it means your disk is coupled to your RAM until you go configure disk-backed storage. That's a reasonable default for short work, but it is not how a disk behaves.

A Sprite gets 100GB of ext4. It does not expire and it is not a volume you attach nor a tmpfs that survives. The storage layer underneath it (we call it SBD) presents an S3 bucket to the kernel as a block device and runs ordinary ext4 on top, so you get block-level snapshots with deduplication and copy-on-write clones, and there's no metadata database to keep consistent. Checkpoints are unlimited and they don't rot. Nothing on your Sprite is on a timer.

It keeps running your programs

If you've ever had to climb a staircase with your laptop open, you get why we think this is so important.

The industry's answer to "does my process survive" is mostly "yes if it survives cryostasis." The most common approach is freeze it and thaw it. E2B preserves memory on pause and restores it. Blaxel keeps memory intact through standby and resumes in under 25 milliseconds (that is insanely fast BTW). Modal's memory snapshots restore every process still running, in the same state.

Freezing is not running though. E2B's pause costs about four seconds per gigabyte of RAM, so a 16GB environment takes something like a minute to put down. Blaxel is upfront that a restored snapshot brings back your processes but not your external connections; database handles, message queues, and HTTP pools all time out and close, so anything long-lived has to reconnect. Modal's restore is the sharpest example, because restoring doesn't resume your sandbox at all. It creates a new one. It's a clone, which matters if anything outside it is holding a reference to the original. The restored sandbox has its own identity, so a stored sandbox ID, a URL you handed to a webhook, or a job queued against...