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

# Live Resize

> Change the CPUs, memory, and root disk of a running sandbox without restarting it.

A sandbox created from a [CAS image](/sandboxes/cas-images) can change its CPU, memory, and root disk allocation while it runs.
Processes keep running, the API reports the confirmed allocation, and the guest sees the new CPUs, memory, and disk capacity.
[GPU sandboxes](/sandboxes/gpu) can only grow their root disk, and sandboxes created from the default-format `tensorlake/*` images
can't be resized live; recreate those with the new size instead.

## What You Can Change

* **CPUs**: up or down, in whole vCPUs, with a minimum of 1.
* **Memory**: up is always possible. Down goes no lower than the memory the sandbox booted with, and only as far as the guest can free memory at that moment. Memory changes happen in 128 MiB steps.
* **Disk**: up only. The filesystem grows in place.

If the guest can't release enough memory for a shrink, the resize stops above the target and is reported as failed with the size it reached, and the sandbox keeps that size.
For example, a sandbox booted with 1 GiB, grown to 64 GiB, and still using 34 GiB can shrink to about 34 GiB, not back to 1 GiB.

Each resize is a numbered generation. The sandbox's `resources` always hold the confirmed allocation, and `resource_resize` describes the latest generation with its
status: `pending`, `succeeded`, or `failed`.

## Resize a Running Sandbox

Omitted dimensions keep their current allocation. A resize can't be combined with name, port, or network changes in the same call.

<Tabs>
  <Tab title="CLI">
    ```bash theme={null}
    tl sbx update <sandbox-id> --cpus 4 --memory 8192
    tl sbx update <sandbox-id> --disk_mb 51200
    ```

    The command waits up to 300s for the resize to complete. `--wait-timeout` changes the limit, and `--no-wait` returns as soon as the resize is admitted.
  </Tab>

  <Tab title="Python">
    ```python theme={null}
    info = sandbox.update(cpus=4, memory_mb=8192)
    print(info.resources.cpus, info.resources.memory_mb)

    info = sandbox.update(disk_mb=51200)
    print(info.resources.disk_mb)
    ```

    `update()` waits up to `timeout` seconds (default 300) and raises `SandboxResizeError` if the resize fails or times out. A timeout doesn't cancel the resize.
  </Tab>

  <Tab title="TypeScript">
    ```typescript theme={null}
    let info = await sandbox.update({ cpus: 4, memoryMb: 8192 });
    console.log(info.resources.cpus, info.resources.memoryMb);

    info = await sandbox.update({ diskMb: 51200 });
    console.log(info.resources.diskMb);
    ```

    `update()` waits up to `timeout` seconds (default 300) and throws `SandboxResizeError` if the resize fails or times out. A timeout doesn't cancel the resize.
  </Tab>
</Tabs>

## Wait for a Resize Later

Return as soon as the resize is admitted and wait for its generation when convenient, for example from another process:

<Tabs>
  <Tab title="CLI">
    ```bash theme={null}
    tl sbx update <sandbox-id> --memory 16384 --no-wait
    tl sbx wait <sandbox-id> --resize <generation> --timeout 600
    ```

    With `--no-wait`, `tl sbx update` prints the `tl sbx wait` command to run, including the generation.
  </Tab>

  <Tab title="Python">
    ```python theme={null}
    info = sandbox.update(memory_mb=16384, wait=False)
    generation = info.resource_resize.generation

    info = sandbox.wait_for_resource_resize(generation, timeout=600)
    ```
  </Tab>

  <Tab title="TypeScript">
    ```typescript theme={null}
    const admitted = await sandbox.update({ memoryMb: 16384, wait: false });
    const generation = admitted.resourceResize!.generation;

    const info = await sandbox.waitForResourceResize(generation, { timeout: 600 });
    ```
  </Tab>
</Tabs>

A wait that times out doesn't cancel the resize. Wait for the same generation again to keep following it.

## Resize and Snapshots

A [memory snapshot](/sandboxes/snapshots) records the resized allocation, so a sandbox restored from it starts with that size.
The restored sandbox can be resized again, including shrinking memory down to the size the original sandbox booted with.

## See Also

<CardGroup cols={3}>
  <Card title="CAS Images" icon="boxes-stacked" href="/sandboxes/cas-images">
    The image format that makes a sandbox resizable.
  </Card>

  <Card title="Lifecycle" icon="arrows-spin" href="/sandboxes/lifecycle">
    Sandbox states, timeouts, and suspend/resume.
  </Card>

  <Card title="Snapshot and Clone" icon="camera" href="/sandboxes/snapshots">
    Save and restore a resized sandbox.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.