Spot Sandboxes

Spot sandboxes trade reliability for price: in exchange for a discount on CPU and memory billing, you allow the platform to reclaim the sandbox when capacity gets tight. For workloads that tolerate interruption — batch jobs, evaluation fleets, checkpointed training, retryable agent tasks — spot can substantially cut costs with little practical downside.

What spot: true means

Setting spot: true at create time places the sandbox in the spot tier. It behaves identically to a regular sandbox in every way — same isolation, same toolbox, same performance — except for two things: its guaranteed CPU and memory are billed at a discount, and the platform may reclaim it under capacity pressure.

Spot is an independent choice from the sandbox's durability (ephemeral vs persistent) and its resource mode (burstable vs dedicated). You can combine spot with any of them — and durability in particular decides what a reclaim does, so the two are worth choosing together.

The flag is immutable after create. You cannot promote a spot sandbox to on-demand or vice versa; recreate it instead. Sandboxes created by forking inherit the spot tier of their source.

Reclaim behavior

When a host runs hot, the platform reclaims spot sandboxes to free capacity, evicting newest-first — so long-lived spot sandboxes are the last to go. What "reclaimed" means depends on the sandbox's durability, and on whether it can be paused:

• Ephemeral spot → the sandbox is deleted. Its work is gone, so ephemeral spot only suits jobs that are idempotent or externalize their results (for example to a volume or object store).
• Persistent spot → the sandbox is paused: memory, running processes, and disk are all preserved, and you resume it with resume() or start() whenever you are ready. Nothing is lost — the interruption costs you only time.
• Persistent spot with attached volumes → the sandbox is warm-stopped instead of paused (pausing a sandbox with volumes is not supported in v1). The filesystem survives and start() boots it again, but in-memory state and running processes do not survive — treat it like a stop, not a pause.

When a reclaim happens, the sandbox object carries a spot_evicted_at timestamp (RFC 3339). It is cleared again when the sandbox is started or resumed, so you can use it to detect and account for evictions.

Note: because pausing is unavailable for sandboxes with attached volumes or a Docker device, a persistent spot sandbox using those features is warm-stopped on reclaim rather than paused. If preserving live memory across a reclaim matters, avoid attaching volumes/Docker to that sandbox.

Designing for spot

A few patterns make spot essentially free savings rather than a reliability gamble:

• Pair spot with persistent: true. Reclaim then means pause, not loss — your worst case is a delay. This is the recommended default for spot.
• Make work idempotent or checkpointed. If you must run ephemeral spot, ensure a killed job can be re-run from scratch or from externally stored progress.
• Detect evictions. Poll sandbox state (a persistent spot sandbox will show paused) or check spot_evicted_at, then resume or reschedule.
• Keep spot fleets homogeneous. Newest-first eviction means a freshly added worker is reclaimed before older ones — design fleet autoscaling with that in mind.

Example

Create a persistent spot sandbox, and later detect and recover from a reclaim:

from rlp import Daytona, CreateSandboxFromImageParams
 
daytona = Daytona()
sandbox = daytona.create(CreateSandboxFromImageParams(
    image="python:3.12-slim",
    persistent=True,   # reclaim = pause, not loss
    spot=True,
))
 
# ... later: recover if the platform reclaimed it
sandbox = daytona.get(sandbox.id)
if sandbox.state == "paused":
    sandbox.resume()   # continues exactly where it was paused

import { Daytona } from '@rlp/sdk'
 
const daytona = new Daytona()
let sandbox = await daytona.create({
  image: 'python:3.12-slim',
  persistent: true,  // reclaim = pause, not loss
  spot: true,
})
 
// ... later: recover if the platform reclaimed it
sandbox = await daytona.get(sandbox.id)
if (sandbox.state === 'paused') {
  await sandbox.resume() // continues exactly where it was paused
}

# Create a persistent spot sandbox
curl -X POST https://api.rl.trydaytona.com/vms \
  -H "Authorization: Bearer $RLP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"image": "python:3.12-slim", "persistent": true, "spot": true}'
 
# Check for a reclaim: state and spot_evicted_at
curl -s "https://api.rl.trydaytona.com/vms/$VM_ID" \
  -H "Authorization: Bearer $RLP_API_KEY"

Pricing

The spot discount applies to the sandbox's CPU and memory charges. Since those charges are based on your guaranteed floor (see Billing interaction), the practical effect is a discount on the guarantee you reserve — a burstable spot sandbox is billed at the discounted rate on its small floor and still bursts into idle capacity for free. Storage for persistent spot sandboxes is billed like any other persistent sandbox — including while paused or stopped after a reclaim — so delete spot sandboxes you no longer need. For rates and how charges appear on your account, see Spending.