Stop Treating Agent Sandboxes as Cattle

We think that this is a solved problem & has been for years.

What you essentially want is credentials never at rest in the sandbox. A network egress proxy gives you that (there are ones that are open source like fly's tokenizer or mitmproxy):

• The sandbox holds a handle (an opaque token, a placeholder, a short lived metadata service response). No real credential material.
• Outbound traffic routes through the proxy. The proxy substitutes the real token at the boundary.
• The upstream service sees a properly authenticated request. The sandbox NEVER sees the real secret.

This is what Fly's Tokenizer does. It's what AWS IMDS does for EC2 and Lambda with short lived role credentials. It's also the pattern Hashicorp Vault popularized fifteen years ago. It's the default for human developers and CI systems already, and it transfers cleanly to agent sandboxes.

Precisely right on the cost concern, idle compute shouldn't bill. But this isn't an argument for running the harness outside the sandbox, but about hibernation and elasticity, both of which are properties of the sandbox primitive & doesn't concern the location of the harness.

“You can't suspend the thing the loop is running on” is only true if your sandbox can't hibernate the whole VM. Opencomputer can:

• Hibernation drops idle sandboxes to disk. The entire VM ie. process tree, in-memory state, file handles, the loop itself is frozen and resumable in ~25ms. While hibernated, you're billing for snapshot storage and not compute. So stuff like CI waits, LLM round-trips, multi-minute “thinking” stretches all happen while the sandbox is essentially “off”.
• Elasticity scales the live VM between 1GB/1vCPU and 16GB/4vCPU based on observed memory pressure, with a 1 min cooldown on scale up and 15 min of low utilization data required to scale down. Idle agent reasoning runs at the bottom tier. A cargo build or npm install triggers a scale-up; it drops back when the work is done. The harness lives inside throughout, and it just rides the resize!
• For workloads that know their own shape better than the autoscaler can infer, there's an in-VM scaling API at 169.254.169.254 so the agent can scale itself up before a known heavy step and back down after. We think this is especially valuable in an era where agents are becoming more ambitious and have more autonomy.

This is also a real concern, no one wants to lose a multi hour session because a host went down ofc.

But this ALSO isn't an argument about where the harness runs. It's an argument about whether your sandbox primitive has “durability” built into it.

“Cattle vs pets” offers two options and asks you to pick one. There's a third, and we think of it as git branches for VMs. With Opencomputer.dev:

• Hibernation freezes the entire VM (process tree, in-memory state, file handles, the loop itself) and resumes it in ~25ms. Rolling deploys, scale events, restarts that are planned etc. all survivable. The loop kinda doesn't notice anything happened.
• For unexpected stuff, Checkpoints snapshot filesystem and installed state at any point in the session, and you can have up to 10 of them per sandbox. If a sandbox dies hard (host failure, kernel panic) you fork a fresh sandbox from the most recent checkpoint and resume. The harness re-reads on disk state ie. conversation history, planning state, todo list, the same way Claude Code does after you close your laptop and open it back up.
• Also forks aren't just for recovery. You can branch from any checkpoint to explore alternative paths in parallel: three migration strategies, two debugging hypotheses, two different refactors, without paying to bootstrap each one from scratch. The original keeps running.

All this to say that losing a sandbox isn't losing the session.

The original article spends a whole section on durable execution: agent loops are long running, have to survive deploys, and Mendral solved it with Inngest checkpointing each turn as a step. That's durable execution infrastructure they had to build because the loop lives on the backend. With the agent running inside a computer + checkpoints, the sandbox is the unit of durability ie. the entire compute environment, which means it isn't a function call. Inngest is a great tool, but the problem it's solving here doesn't exist if the sandbox is the host.

Andrea's article isn't really ‘the harness belongs outside the sandbox.’ It's ‘the harness belongs outside an ephemeral sandbox.’ The thesis is sort of tautological once you state the assumption. Persistent sandboxes (ala computers) don't have these problems.

Between right and easy, users will always default to easy. And we are on a mission to make building agents as easy and delightful as possible!