feat(deploy_sandbox): default an unsized sandbox to 1 vCPU

[canersoz-scaleai]

Summary

deploy_sandbox steps that set no cpu now reserve 1 vCPU instead of 2, on every provider.

The old 2.0 was the only CPU default in the framework above 1:

• agents default to 1.0 on every provider (A2AAgent.deploy);
• beta_scale env and agent deploys default to 1.0;
• the base provider's create_vm / create_container defaults are 1.0.

This makes deploy_sandbox consistent with them. Nothing recorded why it was 2.

Steps that set cpu are unchanged, and that includes every deploy_sandbox step stored today, because to_dict writes the value out. So the new default only reaches new tasks that leave cpu unset.

Part of FD-4008 (Modal sandbox cost). Modal bills whichever is higher, the request or actual use, and a scalar cpu is a request, not a cap. A lower default therefore cuts idle cost without capping boot bursts.

What changes per provider

• Modal (container and VM): the CPU is a reservation the sandbox bursts above, so the main effect is cheaper idle time. See the experiment below.
• beta_scale, smol_vm, e2b, local: these pass 1 through as a hard core count. That matches the 1.0 beta_scale already gives agents and envs by default. A caller who needs more for boot sets cpu: 2, as every current beta_scale caller already sets its own value (2–8).
• Tenki, Tensorlake: they raise any request to 2, so nothing changes.
• Vercel, sail_vm: they size from CPU and memory together, so the result may not change.

Today, the callers that leave cpu unset are on modal_vm (for example the hub's artifact-generation builder). Every non-Modal caller sets its own.

A Modal-only alternative is in draft #231. It's a per-provider DEPLOY_SANDBOX_CPU (2.0 on the base, 1.0 on Modal). It's here in case reviewers would rather leave other providers at 2.

Production data (Snowflake AGENTENV_MONGO, Datadog modal.cpu.*, last 30 days)

• About 80K deploy_sandbox runs already requested less than 1 vCPU.
• One project ran the same modal_vm workload at two sizes: 0.125 vCPU (Sep 24–Oct 2, ~50K runs) and 2 vCPU (Oct 3 onward, ~176K runs).
  • Run failures were 0.69% at 0.125 and 1.49% at 2.
  • Deploy and install step failures were 0.58% and 0.78%.
  • Median run time was 21 min at 0.125 and 12 min at 2. These were different batches, so this isn't a clean speed comparison.
• Modal sandboxes burst well past their request. 2-vCPU env sandboxes reach a p90 of 3.9 cores during boot, then sit around 0.35 cores.

Experiment (dev stage, no LLM)

Each run was deploy_sandbox (VM, 16 GiB) followed by install_agent (claude-code-cli), attributed to the agent-env unattributed test project. The side-by-side batch ran 1 and 2 vCPU on modal_vm at the same time:

Provider	vCPU	Passed	install_agent time
modal_vm	1	4/4	34, 43, 44, 48 s
modal_vm	2	4/4	36, 37, 41, 45 s
beta_scale	1	2/3*	137, 138 s
beta_scale	2	3/3	79, 81, 86 s

* The failed run lost its connection to the dev MongoDB from the laptop (no primary), not a CPU problem.

• On Modal, 1 vCPU behaves the same as 2.
• Across all 13 one-vCPU Modal runs that day, two installs were slow (83 s and 176 s); the seven 2-vCPU runs had none. The 83 s run's extra time was mostly the agent image download, and neither repeated in the side-by-side batch.
• On beta_scale the request is a hard cap, so install takes about 1.7× longer, though it still finishes well within timeouts.

Testing

• New tst/unit/task_step/deploy_sandbox_default_cpu_test.py covers:
  • the constructor and from_dict defaults;
  • keeping a stored cpu as written;
  • the value create_vm and create_container receive, for an unset and an explicit cpu.
• deploy_sandbox step tests pass locally, and so does ruff check. The rest of tst/unit runs in CI; my local venv predates main's current dependencies (sail, Vercel), so some unrelated provider tests can't import locally.

🤖 Generated with Claude Code

Confidence Score: 5/5

No blocking issues were found in the reviewed changes.

Summary

Changes the default CPU request for unsized deploy_sandbox steps from 2 to 1 vCPU.

• Unsized sandbox deployments now request 1 vCPU.

_{Reviews (2) · Last reviewed commit: "test(deploy_sandbox): cover the containe..." · Reviewed by Greptile}

[earakely-scale]

🤖 Automated Claude routine — Env Pod PR Context Review. This is a bot, not Edgar Arakelyan; not a human review.

Some context from outside this diff, on where the new default actually lands.

The summary reasons about modal_vm and beta_scale, and says "the default applies to whichever provider a step resolves to". Two of the providers in this repo never observe cpu=1.0 — they raise the request to their own floor before sizing the VM:

• src/agent_env/providers/sandbox_providers/tenki/provider.py:69 — cores = max(MIN_CPUS, math.ceil(cpu)), with MIN_CPUS = 2 at line 39. An unsized step still resolves to 2 cores.
• src/agent_env/providers/sandbox_providers/tensorlake/provider.py:123 — cpus = max(float(cpu), _MIN_CPUS), with _MIN_CPUS = 2 at line 38. Same.

So on those two the change is inert: no idle-cost saving to expect, and equally no boot-time regression to worry about. The behaviour change is confined to providers that pass cpu through unclamped — modal_sandbox.py / modal_vm_sandbox.py (where the comment at modal_sandbox.py:315 makes your "request, not a cap" point explicitly), beta_scale, and any provider outside this repo.

Might be worth a line in the summary, since as written it reads as uniform across providers.

---

Generated by Claude Code

[canersoz-scaleai]

Two of the providers in this repo never observe cpu=1.0 — they raise the request to their own floor

Thanks, confirmed: Tenki (max(MIN_CPUS, math.ceil(cpu)), MIN_CPUS = 2) and Tensorlake (max(float(cpu), _MIN_CPUS), _MIN_CPUS = 2) both raise the request to 2, so this change has no effect on them. No code change needed, since those floors are the providers' own minimums. I added a line to the summary saying the new default only takes effect where cpu is passed through as-is: Modal (container and VM), beta_scale, and providers outside this repo.