# Pause And Resume

Sandbox0 can pause an idle sandbox without deleting it. Pause preserves sandbox state, while resume makes the sandbox runnable again.

Use this page when you need to:

- pause a sandbox explicitly
- resume a paused sandbox explicitly
- understand how `ttl`, `auto_resume`, service routes, and SSH interact with pause state
- inspect whether a pause or resume request has completed

<Callout variant="info">
Pause state is separate from `status`. Use `paused` for the simple user-facing state, and `power_state` when you need to inspect desired versus observed transition progress.
</Callout>

## Pause A Sandbox

Pause a sandbox to release compute while keeping its state available for a later resume.

<Endpoint method="POST">
/api/v1/sandboxes/{'{id}'}/pause
</Endpoint>

<Tabs
  tabs={[
    {
      label: "Go",
      language: "go",
      code: `_, err := client.PauseSandbox(ctx, sandbox.ID)
if err != nil {
    log.Fatal(err)
}
fmt.Println("Pause requested")`
    },
    {
      label: "Python",
      language: "python",
      code: `client.pause_sandbox(sandbox.id)
print("Pause requested")`
    },
    {
      label: "TypeScript",
      language: "typescript",
      code: `await client.sandboxes.pause(sandbox.id);
console.log("Pause requested");`
    },
    {
      label: "CLI",
      language: "bash",
      code: `s0 sandbox pause sb_abc123`
    }
  ]}
/>

## Resume A Sandbox

Resume a sandbox that was paused manually or by TTL expiry.

<Endpoint method="POST">
/api/v1/sandboxes/{'{id}'}/resume
</Endpoint>

<Tabs
  tabs={[
    {
      label: "Go",
      language: "go",
      code: `_, err := client.ResumeSandbox(ctx, sandbox.ID)
if err != nil {
    log.Fatal(err)
}
fmt.Println("Resume requested")`
    },
    {
      label: "Python",
      language: "python",
      code: `client.resume_sandbox(sandbox.id)
print("Resume requested")`
    },
    {
      label: "TypeScript",
      language: "typescript",
      code: `await client.sandboxes.resume(sandbox.id);
console.log("Resume requested");`
    },
    {
      label: "CLI",
      language: "bash",
      code: `s0 sandbox resume sb_abc123`
    }
  ]}
/>

## Inspect Pause State

After requesting a pause or resume, fetch sandbox details to check whether the transition has completed.

<Tabs
  tabs={[
    {
      label: "Go",
      language: "go",
      code: `sb, err := client.GetSandbox(ctx, sandbox.ID)
if err != nil {
    log.Fatal(err)
}
fmt.Printf("paused=%v\n", sb.Paused)
fmt.Printf("power_state=%+v\n", sb.PowerState)`
    },
    {
      label: "Python",
      language: "python",
      code: `sb = client.get_sandbox(sandbox.id)
print("paused=", sb.paused)
print("power_state=", sb.power_state)`
    },
    {
      label: "TypeScript",
      language: "typescript",
      code: `const sb = await client.sandboxes.get(sandbox.id);
console.log("paused=", sb.paused);
console.log("powerState=", sb.powerState);`
    },
    {
      label: "CLI",
      language: "bash",
      code: `s0 sandbox get sb_abc123`
    }
  ]}
/>

## TTL And Auto Resume

`ttl` and `hard_ttl` interact with pause differently:

| Field | Behavior |
|-------|----------|
| `ttl` | Soft timeout. When it expires, Sandbox0 pauses the sandbox. |
| `hard_ttl` | Hard runtime timeout. When it expires, Sandbox0 cleans the runtime pod and keeps the sandbox identity for later resume. |

`auto_resume` is the sandbox-level gate for whether inbound access can wake a paused or cleaned sandbox:

- when `auto_resume` is `true`, supported access paths can resume the sandbox automatically
- when `auto_resume` is `false`, you must call resume explicitly

Common auto-resume entrypoints:

- service routes configured with `resume: true`; public service requests require both sandbox `auto_resume: true` and route `resume: true`
- SSH access through Sandbox0 SSH Gateway

For a cleaned sandbox, auto-resume creates a new runtime pod for the same sandbox identity. Public service URLs remain stable until the sandbox is explicitly deleted.

See [Sandbox Services](/docs/sandbox/services) and [SSH](/docs/sandbox/ssh) for the user-facing flows.

## Typical Pattern

For long-running agent workflows, a common pattern is:

1. claim a sandbox with `ttl` set
2. do active work through contexts and files
3. let idle sandboxes pause automatically
4. resume on the next user action, SSH session, or service route hit
5. use `hard_ttl` to cap the maximum lifetime

## Next Steps

<CardGroup>
  <Card title="Contexts" href="/docs/sandbox/contexts" cta="Continue">
    Run REPL and command contexts inside a sandbox and stream process output.
  </Card>

  <Card title="Files" href="/docs/sandbox/files" cta="Continue">
    Read, write, watch, and manage files inside a sandbox workspace.
  </Card>
</CardGroup>
