From e36be99918339a541e4928bf36ab761c57d73bdd Mon Sep 17 00:00:00 2001 From: Waleed Latif Date: Fri, 30 Oct 2026 10:46:02 -0700 Subject: [PATCH 1/2] fix(sandbox): correct the E2B build default in the Pi sizing doc --- .../execution/remote-sandbox/pi-resources.ts | 22 +++++++++---------- 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/apps/sim/lib/execution/remote-sandbox/pi-resources.ts b/apps/sim/lib/execution/remote-sandbox/pi-resources.ts index 143dda6c235..9f03e566ee5 100644 --- a/apps/sim/lib/execution/remote-sandbox/pi-resources.ts +++ b/apps/sim/lib/execution/remote-sandbox/pi-resources.ts @@ -1,22 +1,20 @@ /** * vCPU and RAM for the Pi sandbox, shared by both provider builds and by sandbox - * pricing. The two providers had already drifted here. Daytona asked for 4 CPU / 8 GB - * while the E2B template asked for nothing and inherited its base default of - * 2 vCPU / 512 MB — a 16x memory gap between the provider Pi normally runs on and - * the one it fails over to, which would surface as the agent being killed on E2B - * for work that succeeded on Daytona. + * pricing, so the provider Pi fails over to gives it the same machine as the one it + * normally runs on. A template built without explicit sizes gets E2B's build default + * of 2 vCPU / 1 GiB, an eighth of the memory Pi gets on Daytona. * - * 512 MB is the real problem: the Pi CLI is a Node process holding an LLM + * Memory is the dimension that matters: the Pi CLI is a Node process holding an LLM * context, running beside a `git clone` of the user's repository, and Node has no - * graceful behaviour at that ceiling — it is OOM-killed, which reaches the user + * graceful behaviour at its memory ceiling — it is OOM-killed, which reaches the user * as an opaque agent failure rather than a diagnosable one. * * Memory is at E2B's Professional maximum (8192 MB per build) and CPU is half of - * its 8 vCPU maximum; the minimum is 1 vCPU / 512 MB. Sizing is per-second billed against allocated - * resources rather than used ones, so this costs roughly 3x the previous E2B - * default per sandbox-second. On the compute-bound phases that is close to - * neutral — the work finishes proportionally sooner — but Babysit deliberately - * idles between review polls, and idle seconds bill at the same rate. Lower + * its 8 vCPU maximum. Sizing is per-second billed against allocated resources rather + * than used ones, so this costs roughly 3x the E2B build default per sandbox-second. + * On the compute-bound phases that is close to neutral — the work finishes + * proportionally sooner — but Babysit deliberately idles between review polls, and + * idle seconds bill at the same rate. Lower * {@link PI_SANDBOX_CPU_COUNT} first if that idle time proves dominant: vCPU is * ~3x the hourly rate of a GB of RAM, and RAM is the dimension that prevents * hard failures. From 16ebf3e0f309d6836ddda1c40e5008cd6feb21fc Mon Sep 17 00:00:00 2001 From: Waleed Latif Date: Fri, 30 Oct 2026 10:54:38 -0700 Subject: [PATCH 2/2] fix(sandbox): clarify the Pi sizing sentence --- apps/sim/lib/execution/remote-sandbox/pi-resources.ts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/apps/sim/lib/execution/remote-sandbox/pi-resources.ts b/apps/sim/lib/execution/remote-sandbox/pi-resources.ts index 9f03e566ee5..09a32c03257 100644 --- a/apps/sim/lib/execution/remote-sandbox/pi-resources.ts +++ b/apps/sim/lib/execution/remote-sandbox/pi-resources.ts @@ -1,7 +1,7 @@ /** * vCPU and RAM for the Pi sandbox, shared by both provider builds and by sandbox - * pricing, so the provider Pi fails over to gives it the same machine as the one it - * normally runs on. A template built without explicit sizes gets E2B's build default + * pricing, so Pi gets the same machine on the provider it fails over to as on the one + * it normally runs on. A template built without explicit sizes gets E2B's build default * of 2 vCPU / 1 GiB, an eighth of the memory Pi gets on Daytona. * * Memory is the dimension that matters: the Pi CLI is a Node process holding an LLM