Spending & Credits

Daytona bills for what sandboxes actually consume. Every sandbox's CPU, memory, and disk usage is sampled continuously on the host it runs on and metered per second; the resulting charges are drawn from your organization's credit balance. There are no per-sandbox flat fees and no minimum billing increments — a sandbox that lives for forty seconds is billed for forty seconds.

What you pay for

The billing model follows the sandbox's resource mode:

• Guaranteed resources — the CPU and memory reservation a sandbox holds — are billed per second for the whole time the sandbox is starting, running, or stopping. For a dedicated sandbox this is the entire bill: you reserve fixed resources and pay for the reservation.
• Burst usage — for a burstable sandbox, measured consumption above the guarantee is charged on top, aggregated per minute. If the sandbox stays within its guarantee, only the guarantee is billed; the burst headroom costs nothing until it is actually used.
• Spot sandboxes bill their guaranteed CPU and memory at a discount, in exchange for being reclaimable by the platform.

States that don't burn compute:

• Queued (pending) sandboxes waiting for capacity are not billed.
• Paused and stopped sandboxes stop accruing CPU and memory charges entirely — only their storage is retained.
• Deleted sandboxes stop billing at the instant of deletion.

Note: current per-unit rates are shown in the dashboard. This page describes the mechanics, not prices.

Credits

Every charge is drawn from the organization's credit balance — one balance shared by all of the org's projects. New organizations (including your auto-created personal org) start with an initial credit grant.

When the balance reaches zero:

• Creating new sandboxes, starting stopped ones, and resuming paused ones is refused with an insufficient-credits error.
• Sandboxes that are already running are given a small grace overdraft so they aren't cut off mid-operation — but once the overdraft limit is crossed, the platform force-deletes the org's running sandboxes.

Don't rely on the overdraft: top up before the balance hits zero if you have long-running workloads.

Seeing your spend

Dashboard. The Spending page at app.rl.trydaytona.com shows the current credit balance and a usage report across the org's sandboxes. Each sandbox's details page also has a Usage tab with its individual time series.

Usage report (REST). GET /usage/report returns per-sandbox usage aggregated hourly (or daily with resolution=d) for the API key's project:

curl "https://api.rl.trydaytona.com/usage/report?resolution=d" \
  -H "Authorization: Bearer $RLP_API_KEY"

Each item reports the interval's CPU core-seconds, memory GiB-hours, peak disk bytes, and disk/network I/O byte counts per sandbox. The optional start and end query parameters take RFC 3339 timestamps; the default window is the last 24 hours. Per-sandbox live figures and history are available via GET /vms/:id/usage and GET /vms/:id/usage/history — see usage metrics.

Credit balance (management API). The organization's balance is available to signed-in users:

curl https://api.rl.trydaytona.com/orgs/$ORG_ID/credits \
  -H "Authorization: Bearer $OIDC_TOKEN"

This is the same balance the dashboard header and Spending page display.

Keeping costs down

• Prefer burstable mode with a modest guarantee for spiky workloads — you pay the reservation plus only the bursts you actually use.
• Delete (or stop, for persistent sandboxes) sandboxes when you're done; an idle running sandbox still bills its guarantee every second.
• Use spot sandboxes for interruptible batch work to get the discounted rate.
• Pause long-lived sandboxes between sessions instead of leaving them running.