Computers Compared

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 the old one are all now pointing at something that isn't there.

We also need to talk about time limits, because it's a weird thing for a computer to have one. Vercel Sandbox caps out at 24 hours on Pro and Enterprise, and 45 minutes on Hobby, with a five minute default you extend by calling a function. AWS AgentCore sessions cap at eight hours. Cloudflare is the exception here, because it sets no maximum lifetime at all. Its containers sleep after ten minutes of inactivity, and that's a default you can change rather than a ceiling you can't.

E2B has a 24 hour continuous runtime limit on Pro and one hour on Hobby. But the limit resets every time you pause and resume, so your total lifetime is effectively unbounded. It just means the platform decides when your processes stop, on its schedule, and you pay the pause tax each time.

Sprites have no duration cap of any kind. More to the point, in place of systemd, a Sprite runs services; long-lived processes with dependency ordering and automatic restart on crash, backing off from one second to sixty, persisted to disk and relaunched on boot. Your dev server, your database, your queue worker; they are supervised, they survive a reboot, and they come back on their own when something kills them, because they're real services and not a frozen memory image.

Sleep keeps your memory. The suspend snapshots RAM and the Sprite picks up mid-thought, which is why we bother warming the page cache on the way down. What sleep doesn't keep is your connections, and if the far end gave up while you were away your client re-dials, the same as it would after any network blip. Nothing needs reconfiguring, because nothing about the Sprite changed.

We still think this is a big one, but the industry doesn't seem as enthused and I don't know why.

Every Sprite has a public HTTPS URL with automatic TLS. A request to that URL wakes the Sprite if it's asleep and gets served. That's it… That's the whole feature. But it's the dividing line between a computer and a job.

It matters because of what it lets you do without any additional machinery. OAuth callbacks land. Webhooks land. You point Stripe or GitHub or Slack at the URL and it works. No tunnel, no ngrok, no relay process babysitting a connection. Your agent can build a thing, start it, and hand you a link.

Some on the field have a version of this. Blaxel and Daytona both do preview URLs. Vercel exposes ports, capped at fifteen. But an exposed port on a sandbox with a 24 hour ceiling is not the same thing as an address. The URL only means something if the machine behind it is still there tomorrow and wakes up when someone knocks.

It's astonishing how quickly we accepted that agents need to connect to 3rd-party services to be useful, but here we are. The default answer across this industry is still the worst one. Put the API key in an environment variable inside the sandbox and hope the model doesn't print it. This is nuts, guys. You are handing live credentials to a process whose entire job is to run code that a language model wrote, and the security boundary is vibes.

Two players have actually built a real answer though. Vercel runs a proxy outside the sandbox boundary that intercepts outbound requests and injects credentials into the headers in transit. If the code inside tries to set those same headers to redirect the authenticated request somewhere else, the proxy overwrites them. Their egress firewall resolves deny before allow, which is the correct precedence and not the obvious one. Runloop has Agent Gateways and an MCP Hub for the same purpose, explicitly so real credentials never reach the devbox.

What we built is the same shape and goes further down. Sprites has Connectors; real OAuth flows to OpenRouter, GitHub, Slack, Discourse, or any HTTP API with the custom Connector. The credential lives in the control plane. The Sprite never holds it. The gateway proxies the request and attaches the credential, and every request to a customer-chosen host passes an SSRF guard that checks self-targeting along with private and link-local addresses before anything leaves.

The Discourse connector is the one I'd shine the spotlight on, because it shows the difference between injecting a key and brokering an identity. It uses Discourse's User API Key flow, so you approve the connection on your own forum and the credential that comes back inherits your permissions and nothing more. A Sprite acting on your behalf on a Discourse instance can only do what you can do. It never holds site-wide admin, because it was never issued site-wide admin.

That's the gap between a static key in a proxy rule and a scoped identity. Injecting a header keeps the secret out of the sandbox. Brokering an identity also bounds the blast radius when the request is legitimate and the agent is just wrong about what it should be doing, which is the failure mode I actually lose sleep over.