Our laptops carry far more agents than they could ever run at once. That's the whole reason we can work this way, and it took two changes to get there, neither of which was a bigger machine.
It showed up as a queue I hadn't expected, and I wasn't the one in it. The agents were, stopped and finished and idle, because my sandbox was busy showing me the last change.
We each had exactly one, which was plenty back when you could only work on one thing at a time.
So we built more, and that helped right up until the laptop ran out. A sandbox is a whole running copy of the product, and one machine only holds so many awake at once.
Let them sleep
An untouched sandbox parks itself. The process exits, the memory comes back, and its address still works, so the next request wakes it.
Most are asleep at any moment. Not more machine, just less of it held by work nobody is doing.
Stop letting anyone own one
The other half of the problem wasn't capacity, it was reservation. A sandbox belonged to a piece of work, so one could sit idle for days holding a slot for something you'd abandoned, while the agent you actually cared about had nowhere to run.
Now they're a pool. Ask, and you get whichever is free. Nothing is ever taken from an agent that's still working, so the only thing you can lose is a slot you weren't using.
Renting isn't the escape hatch
The obvious answer is to put the containers in the cloud and stop counting. It isn't that simple.
Our agents do their looking through Claude in Chrome, so the browser has to be signed in to our Claude account, and to everything else it needs to reach. That runs in the cloud fine, but now you're keeping a signed-in browser session alive per container, which is a different job from starting a machine on demand.
The laptops are already paid for, so staying local suits us for now. But the wall we hit next is a browser session, not a bill.
Read Next
Written by
Chris Fong
CTO & Co-founder