Each Sweet web app session runs in its own Firecracker microVM — a real, isolated virtual machine per session, not a shared container. That isolation is great for security, but the original spec (2 vCPUs, 2GB of RAM) was sized for editing files and running quick scripts, not for the kind of work developers actually throw at an autonomous agent: full builds, test suites, and multi-service dev environments.
What changed
- 4 vCPUs , up from 2 — parallel test runs and multi-step builds no longer contend for a single core.
-
8GB of RAM
, up from 2GB — enough headroom for a real
npm run build, a local dev server plus a test runner, or a moderately sized dataset in memory, without the VM getting OOM-killed mid-task.
The goal was to make a Sweet session feel closer to a GitHub Actions runner than a sandbox — something that can carry a normal day of development work, including the parts that are memory- and CPU-hungry, not just the parts that are quick.
Why it matters for /workfor
This mattered most for longer autonomous runs. A /workfor session that spends two hours building, testing, and recovering from failures needs a machine that can actually sustain that — a cramped VM was the most common reason a long-running task would stall or get killed partway through, independent of anything the model itself did wrong.