> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opencomputer.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Sandbox sizes

> Which memory sizes exist, which are available to you, and what happens when one isn't

On v2 a sandbox's memory is a property of the **image** it launches from, not a
parameter of the launch. The platform has no memory or vCPU field on the create call at all —
the only knob is the memory declared when an image is published.

Two consequences follow, and they explain everything else on this page: the set of sizes is a
fixed list rather than any number you like, and a size cannot change after launch.

## Sizes the platform supports

Memory belongs to the image, so a size exists only if we have published an image for it. The
sizes mirror the current runtime's tiers as closely as the platform allows:

| Memory   | On the current runtime | On v2                                                    |
| -------- | ---------------------- | -------------------------------------------------------- |
| 1 GB     | 1 vCPU (best-effort)   | same — CPU is best-effort at this size                   |
| 2 GB     | —                      | available (no equivalent tier today)                     |
| **4 GB** | 1 vCPU                 | **default**, and the only size served from the warm pool |
| 8 GB     | 2 vCPU                 | available                                                |
| 16 GB    | 4 vCPU                 | **not available** — 8 GB is the ceiling                  |

<Note>
  These are steps, not a range. `3072` is not a size — a tier is either published or it is not,
  and nothing in between exists.
</Note>

The one gap is **16 GB**. If you run 16 GB sandboxes today, that work has to fit in 8 GB or be
split before you migrate — memory cannot be raised after launch either. See
[Prepare to migrate](/migrating-from-v1).

## Disk

Disk is **fixed at roughly 16 GB** and is not configurable. It comes from the image, the same
way memory does.

<Warning>
  `diskMB` is accepted by the create API and has **no effect** — asking for 64 GB returns `201`
  and gives you the standard \~16 GB. Do not rely on it.
</Warning>

This is smaller than the current runtime's 20 GB default, and much smaller than the 256 GB
ceiling it allows. If any workload needs more disk than 16 GB, it needs somewhere else to put
the data — object storage, or a service it streams from — before you migrate.

Roughly 14 GB of the 16 GB is free on a fresh sandbox; the rest is the base image.

## Which sizes are available to you

Every size above is *possible*; which ones are *published in your region* is configuration.
A region typically publishes the default and a subset of the others.

There is no endpoint that lists them. The reliable way to find out is to ask for one — an
unavailable size is refused with the list of sizes that region actually offers:

```json theme={null}
{
  "error": "requested sandbox size is not available in this region: 8192MB was requested; this region offers 4096 MB",
  "hint": "request one of the listed sizes, or contact support to have another published"
}
```

<Note>
  That is a `400`, not a `503`. The request names something the region cannot serve, so retrying
  never helps — as opposed to a real capacity shortage, which is reported separately and *is*
  worth retrying.
</Note>

If a size in the supported enum is not published in your region and you need it, ask us — that
is a matter of publishing another image, and it is quick. A size outside the enum is not.

## Choosing one

```typescript theme={null}
const sandbox = await Sandbox.create();                  // default, 4096 MB
const bigger  = await Sandbox.create({ memoryMB: 8192 }); // if published in your region
```

Omitting `memoryMB` gives you the default. That is also the fastest option:

<Warning>
  **Only the default size is kept warm.** Every other size cold-launches from its own image,
  which takes a few seconds rather than the sub-second create you get from the pool.
</Warning>

Warm stock is per-image, so pooling every size would either multiply idle cost by the number of
tiers or split one pool between them and lose the latency the pool exists for. Deliberately, one
size is fast and the rest are correct.

## You are never silently given the wrong size

If a size cannot be served, the create fails. It is never quietly served from the default image.

This matters more here than on the current runtime: memory is fixed at launch, so there is no
later point at which a wrong size could be corrected — you would simply be billed for one size
and running on another for the life of the sandbox.

## Resizing is not possible

<Warning>
  `scale()` and `setAutoscale()` return `501`. Memory belongs to the image, so a running sandbox
  cannot be resized.
</Warning>

If you size sandboxes dynamically today, that decision has to move to create time. See
[What's not supported](/migrating-from-v1).