fix(pi): share the sandbox sizing and lift E2B off the base default

The two Pi images had drifted on exactly the axis their shared module exists to
prevent. Daytona asked for 4 CPU / 8 GB; the E2B template asked for nothing and
inherited its base default of 2 vCPU / 512 MB. That is a 16x memory gap between
the provider Pi normally runs on and the one it fails over to, so a failover
could be OOM-killed doing work that had just succeeded.

512 MB is too small independently of the drift: the Pi CLI is a Node process
holding an LLM context, running beside a clone of the user's repository, and
Node is OOM-killed rather than degraded at that ceiling — which reaches the
user as an opaque agent failure.

CPU and memory now come from pi-sandbox-packages.ts alongside the package
lists. Disk stays in the Daytona renderer: its 10 GB per-sandbox cap is a hard
provider limit with no E2B equivalent, so it is the one dimension where the
images legitimately differ.

E2B fixes resources at template build time, so this takes effect only when
build-pi-e2b-template.ts is re-run — nothing builds these images in CI.

Co-Authored-By: Claude <noreply@anthropic.com>

Author: icecrasher321

apps/docs/content/docs/en/workflows/blocks/pi.mdx

@@ -194,6 +194,8 @@ Create PR runs in a sandbox image with the Pi CLI and git baked in.
 
 1. **Enable sandbox execution.** On self-hosted Sim, set `E2B_ENABLED=true`, `E2B_API_KEY`, `E2B_PI_TEMPLATE_ID` (the Pi template id), and `NEXT_PUBLIC_E2B_ENABLED=true` (this reveals Create PR and Review Code in the UI). Build the template with `bun run apps/sim/scripts/build-pi-e2b-template.ts`. These modes stay hidden until `NEXT_PUBLIC_E2B_ENABLED` is set.
 
+   The template requests **4 vCPU and 8 GB of RAM** (within the per-build maximum on every E2B plan). Sizing is fixed when the template is built — E2B has no per-sandbox override — so changing it means rebuilding the template, not restarting Sim. Sandboxes are billed per second against the resources they are allocated, not the ones they use. Both numbers live in `apps/sim/scripts/pi-sandbox-packages.ts` and are shared with the Daytona snapshot so the failover image cannot drift from the primary.
+
    Sim sizes each Pi sandbox to **the execution's own remaining time**, so a run never holds a sandbox longer than the platform would let it run. The ceiling when there is no deadline to narrow to is the longest execution any plan permits (90 minutes); E2B rejects a create above the session length its plan allows, which is 1 hour on Hobby and 24 hours on Professional. `PI_SANDBOX_LIFETIME_MS` may lower that ceiling but has a **31-minute minimum**; lower values are raised to the minimum. A run that outlives the sandbox loses its work before the push, and an orphaned sandbox — one whose Sim process died mid-run — bills until the lifetime expires, which is why that lifetime tracks the deadline. Babysit Mode uses a second sequential sandbox after the creation sandbox has been destroyed; it is billed while polling checks and reviews. Daytona remains unchanged because its auto-stop setting is inactivity-based rather than an absolute lifetime.
 2. **Bring your own model key.** Set the provider API key in the block's API Key field, or store it in **Settings → BYOK** when the provider supports workspace BYOK.
 3. **Create a GitHub token** with permission to clone, push, and open a PR:

apps/sim/scripts/build-pi-daytona-snapshot.ts

@@ -31,18 +31,29 @@ import {
   PI_NODE_MAJOR,
   PI_NODE_VERSION_ASSERT,
   PI_NPM,
+  PI_SANDBOX_CPU_COUNT,
+  PI_SANDBOX_MEMORY_GB,
 } from '@/scripts/pi-sandbox-packages'
 
 /** Matches E2B's base: Debian 13 (trixie) with Python 3.13 installed to /usr/local. */
 const BASE_IMAGE = 'python:3.13-slim-trixie'
 
 /**
- * `daytona-large` sizing. 10 GB is a HARD per-sandbox disk cap — the API rejects
- * anything larger ("Disk request 20GB exceeds maximum allowed per sandbox
- * (10GB)"), regardless of plan tier, and raising it requires contacting Daytona.
- * That is the binding constraint on how large a repo Pi can clone here.
+ * CPU and memory come from the shared module so the two providers cannot drift
+ * apart on sizing the way they already had — see {@link PI_SANDBOX_CPU_COUNT}.
+ *
+ * Disk stays local because it is not shareable: 10 GB is a HARD per-sandbox cap
+ * here — the API rejects anything larger ("Disk request 20GB exceeds maximum
+ * allowed per sandbox (10GB)"), regardless of plan tier, and raising it requires
+ * contacting Daytona. E2B allows 20 GB, so this is the binding constraint on how
+ * large a repo Pi can clone on the failover provider, and the one dimension where
+ * the two images legitimately differ.
  */
-const RESOURCES = { cpu: 4, memory: 8, disk: 10 } as const
+const RESOURCES = {
+  cpu: PI_SANDBOX_CPU_COUNT,
+  memory: PI_SANDBOX_MEMORY_GB,
+  disk: 10,
+} as const
 
 const APT_PREFIX = 'DEBIAN_FRONTEND=noninteractive apt-get install -y --no-install-recommends'
 

apps/sim/scripts/build-pi-e2b-template.ts

@@ -22,6 +22,8 @@ import {
   PI_NODE_MAJOR,
   PI_NODE_VERSION_ASSERT,
   PI_NPM,
+  PI_SANDBOX_CPU_COUNT,
+  PI_SANDBOX_MEMORY_MB,
 } from '@/scripts/pi-sandbox-packages'
 
 const DEFAULT_TEMPLATE_NAME = 'sim-pi'
@@ -51,9 +53,15 @@ async function main() {
   const skipCache = args.includes('--no-cache')
 
   console.log(`Building Pi E2B template: ${templateName}`)
+  console.log(`Resources: ${PI_SANDBOX_CPU_COUNT} vCPU / ${PI_SANDBOX_MEMORY_MB} MB`)
   console.log(skipCache ? 'Cache: disabled\n' : 'Cache: enabled\n')
 
+  // Resources are fixed at build time — E2B has no per-`Sandbox.create` override —
+  // so this template's sizing applies to Create PR, Review Code, and Babysit
+  // alike, and changing it means rebuilding rather than redeploying the app.
   const result = await Template.build(piTemplate, templateName, {
+    cpuCount: PI_SANDBOX_CPU_COUNT,
+    memoryMB: PI_SANDBOX_MEMORY_MB,
     onBuildLogs: defaultBuildLogger(),
     ...(skipCache ? { skipCache: true } : {}),
   })

apps/sim/scripts/pi-sandbox-packages.ts

@@ -57,3 +57,32 @@ export const PI_NODE_VERSION_ASSERT =
  * only the Daytona image has to provide it explicitly.
  */
 export const PI_REQUIRES_PYTHON3 = true
+
+/**
+ * vCPU and RAM for the Pi sandbox, shared for the same reason the package lists
+ * are: 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.
+ *
+ * 512 MB is the real problem: 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
+ * as an opaque agent failure rather than a diagnosable one.
+ *
+ * Both numbers are at E2B's Professional maximum (8 vCPU / 8192 MB per build,
+ * 1 vCPU / 512 MB minimum). 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
+ * {@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.
+ */
+export const PI_SANDBOX_CPU_COUNT = 4
+
+/** Kept in GB and MB because Daytona takes GB and E2B takes MB. */
+export const PI_SANDBOX_MEMORY_GB = 8
+export const PI_SANDBOX_MEMORY_MB = PI_SANDBOX_MEMORY_GB * 1024