April 19, 2026

Your Laptop Is Not the Right Place for Your Agent

Open developer Twitter this week. Under every Claude Code or Codex post, the replies have the same shape. "Max 20x is gone by Wednesday." "Burned $40 letting it explore on day one." "Beautiful, also it touched the wrong repo at 2am." "How do I run four of these in parallel?"

There's a pattern under all of it. The model isn't really getting greedier. It's that we're running 2026 agents inside the same software shape we used for 2024 chatbots — a process on your laptop, sharing your filesystem, your network, your billing dashboard, and your patience. That shape has run out of road.

Three Things That Break When the Agent Lives on Your Laptop

1. Cost is one shared meter.When the agent is yours and the laptop is yours, the $40 it burns "exploring" on day one is just your $40 — not budgeted to the task, not capped, not refundable. The hackathon teams figuring out Opus 4.7 this weekend aren't the ones with smarter prompts. They're the ones who put each task on its own meter.

2. Blast radius is your home directory.Every "let it run autonomously" tweet eventually has a reply that goes "yeah I let it run overnight and it touched 4,000 files in the wrong repo."Sandboxing is a runtime concern, but most agent setups treat it as a permissions checkbox in a settings file. That's the moral equivalent of chmod 777 ~.

3. Parallelism is a tmux trick, not a primitive.Smart teams run three to five Claude Code sessions in worktrees + tmux this weekend. It works. It also means every session is fighting your laptop for CPU, network, disk, and your own attention. You can squeeze five out of one machine. You can't squeeze fifty.

The Unspoken Assumption

All three problems come from the same place: agents should run where you do.

That made sense when "agent" meant ChatGPT in a tab. It stops making sense when agent means a process that runs npm install, edits 30 files, ships a PR, watches the build, and decides what to do next. That's not a chatbot. That's a tiny intern. Tiny interns don't share your laptop.

What Changes When the Agent Gets Its Own Computer

Give each agent task its own ephemeral compute — a sandbox spun up on demand, scoped to one task, billed separately, destroyed when done — and the three above stop being problems:

Budget per task. Each sandbox has its own runtime cap. The agent can burn 40 minutes "exploring" in a cheap container, not on your battery.
Blast radius is the sandbox. rm -rf / inside a 2-minute Firecracker microVM is a non-event.
Parallelism is horizontal. Need 50 agents trying 50 variations? Spawn 50 sandboxes, not 50 tmux panes.

The pattern that already works for human developers — push to CI, let it run on someone else's hardware, check the result — is the same pattern that should work for the agent. We just hadn't built it for them yet.

Where e2a Fits

That's the thing we're building. One API call gives you a sandbox an agent can run in. Pick the agent — Claude Code, Codex, or our first-party Deidict, BYO key. Pick the template — standard for code, browser for web tasks, CUA desktop for full computer use. Stream the agent's output back over WebSocket. The sandbox vanishes when the task ends.

No state to clean up. No laptop to baby-sit. No surprise $40 of "exploration." Each task gets its own meter, its own kernel, its own destruction.

If your laptop fan is loud right now reading this, you might be one of us. Spin up a sandbox → · Read the docs →