const image = Image.base()
  .aptInstall(['build-essential', 'cmake'])
  .runCommands('make -j')
  .builderMemory(8192);          // 8 GB to build…

const sandbox = await Sandbox.create({ image, memoryMB: 4096 });  // …run at 4 GB

The image's 1 GB floor is set by an internal runtimeMemoryMB (defaults to 1 GB,
not exposed in the SDKs — available via raw manifest only, for the rare image
whose services auto-start heavy at boot).

Behavior / back-compat

- Floor stays at 1 GB; forks stay instant (still a warm savevm). Existing
manifests are unaffected — builds just stop OOMing.
- builderMemory is excluded from the content hash (a build resource, not
image content) — consistent across server + both SDKs.

Surface

- Proto: CreateCheckpointRequest.finalize_memory_mb
- Worker: CreateCheckpoint routes to the finalize path when set
- Manager: new CreateCheckpointFinalized (sync → cold-boot at floor → snapshot → cleanup)
- API: buildImage runs the build VM at builderMemory, finalizes at the floor
- SDKs: .builderMemory() / .builder_memory() (TS + Python)
- Docs: "Build memory" section + per-class SDK reference pages

Validation (dev)

30 builds across the full matrix — build sizes 1/4/8/16 GB + defaults, floors,
wake sizes 1–16 GB (clamp-up and hotplug-up), every step kind
(run/apt/pip/env/file/multi/big):
- All builds came up ready; build content survived the finalize cold-boot in
100% of cases.
- Run memory was correct in every case (clamps to floor below it, hotplugs above).
- Ephemeral finalize VMs cleaned up; no leaks.