Daytona pricing: compute, storage, deposits and monthly examples

Daytona's listed CPU rate is $0.0504 per vCPU-hour and its RAM rate is $0.0162 per GiB-hour. A running 2-vCPU, 4-GiB sandbox therefore costs $0.1656 an hour before extra disk and other charges. The price page lists $200 of introductory compute; that is not a recurring monthly allowance. Daytona pricing

The hourly rate answers only part of the question. Stored workspaces can keep costing money after compute stops. Account tiers also affect resource pools and network access, with deposits needed for higher tiers.

We build Lizard, which appears in the comparison below. We checked prices and documentation on 4 November 2026. All examples are calculations, not measured workloads or a claim of equal provider performance.

Calculate the running rate

For the published Linux CPU and memory rates:

Running compute cost = hours × (vCPU × 0.0504 + RAM in GiB × 0.0162)

These figures use reserved resources. A shell waiting on a model response still occupies a running sandbox. CPU utilization does not reduce the reserved-resource bill. Creating, starting, stopping and pausing transitions also remain billable until the sandbox reaches the cheaper state. Daytona billing

Do not use this table to price GPU or other runtime classes without checking their current terms. It also does not include snapshots or extra retained storage.

Add disk for the time you keep it

Daytona lists disk above the first 5 GiB at $0.000108 per GiB-hour. In a 10-GiB example, the extra 5 GiB costs $0.00054 an hour. Keeping that chargeable capacity for 730 hours adds $0.3942, even if compute ran for only part of the month. Disk pricing

GPU and ephemeral sandboxes have deletion rules that differ from persistent CPU workspaces. Check the runtime before assuming stop keeps it available. State billing

Storage billing and storage quota are separate. Freeing an organization's disk quota does not necessarily end a storage charge. Likewise, a stop operation that returned successfully may still have a transition to finish. Use the final lifecycle state in your cost records. Daytona limits

Deposits affect access and cash needed upfront

Daytona's tier documentation lists these requirements:

Sources: tier requirements, network policy.

At the time of review, the same limits page lists both 10 and 20 GiB for Tier 1 RAM. Use the dashboard's effective limits for capacity planning. Do not build a concurrency promise from that conflicting field.

A deposit funds later usage. Report it separately from expense: adding both the full deposit and the usage it pays for counts the same spend twice. It still matters to cash flow. An agent that must visit arbitrary websites may need the higher network tier before it exhausts a lower tier's CPU pool.

Tier pools apply across sandboxes. Peak concurrency depends on CPU, memory, retained disk, region and creation limits. It does not follow from monthly running hours alone.

Three monthly workloads

Assume each sandbox uses 2 vCPU and 4 GiB, runs in a supported region at the listed base rate and adds no chargeable disk. Runtime includes setup and all billable transitions. Exclude introductory credit, model tokens, external storage, network extras and tax differences. The examples stay within 20 simultaneous machines; confirm the account's effective quotas before running them.

The formulas are 120 × 5 / 60 × 0.1656, 10,000 × 5 / 60 × 0.1656 and 20 × 8 × 22 × 0.1656. These values precede invoice rounding and any other charges.

An eight-hour session should not inherit an idle-stop policy that interrupts its work. Decide whether waiting for a model counts as activity and verify that choice with the runtime you use. Stopping compute between tasks can lower the subtotal, while keeping every workspace running overnight increases it. Daytona persistence and lifecycle

Daytona versus Lizard and E2B

For 1,000 aggregate hours at 2 vCPU and roughly 4 GB of memory, Lizard Small uses $16.20 of compute. On a new Pro account, the monthly subtotal is $19 because the plan includes $19 of usage. Daytona's compute subtotal is $165.60. E2B has the same compute subtotal at 4 GiB; Pro adds its $150 base fee, while eligible Hobby use does not. Lizard pricing, E2B pricing, Daytona pricing

This comparison assumes no extra storage or transfer, no introductory credits and an otherwise unused account. Each vendor labels memory units differently; matching the headline size does not prove equal capacity or speed. E2B Hobby also requires sessions within its one-hour limit and at most 20 concurrent sandboxes.

Lizard Small includes 5 GB of local disk and uses fixed sizes. Its base Pro pool supports 20 Small sandboxes; larger plans raise that pool. Daytona offers runtime choices and workspace tools that may justify its price for your application. Compare them in the Daytona alternatives guide, and use E2B vs Daytona for the pair.

Keep cost records per task

Record the sandbox ID, runtime class, allocated resources, region, create time and final stop or deletion state. Record extra disk and snapshots separately. Join these records to the task outcome so retries and failed runs appear in the cost of a successful task.

Set alerts for a growing pool of stopped workspaces and snapshots. A coordinator should reconcile unfinished cleanup after a timeout or network failure. Sending a stop request once is insufficient if the application never checks the resulting state.

Before switching hosts, run the same task on each and measure total billable time. A lower rate can still produce a larger bill if the machine takes much longer or fails more often. The sandbox cost comparison shows how plan minimums and recurring credits change this decision.

Does Daytona charge while idle? Yes, a running sandbox keeps its reserved-resource charge. Stopped or paused states remove CPU and RAM charges, but retained disk can still cost money. The specific runtime determines which states it supports.

Is the tier deposit a second monthly subscription? It funds usage. Keep the required funding amount separate from consumed-resource expense, and check the rolling requirement for Tier 4.

Does deleting a sandbox remove every charge? Separate snapshots can outlive it. Check those resources and verify that deletion finished before treating the workspace as closed.