# Runtime vs Daytona

Runtime and Daytona both run AI agents in isolated Linux sandboxes; Runtime bills the CPU your code uses, not the CPUs it holds.

This page compares the two for teams looking for a Daytona alternative. Facts
about Daytona come from its public pricing and documentation, checked
22 September 2026; check the links at the end before relying on them. Equal vCPU
counts do not prove equal performance, and the two services have not been
benchmarked against each other.

## At a glance

|                  | Runtime                                                   | Daytona                                                       |
| ---------------- | --------------------------------------------------------- | ------------------------------------------------------------- |
| Isolation        | Firecracker microVM for every sandbox                     | Container sandboxes and VM sandboxes                          |
| CPU billing      | $0.025 per vCPU-hour of measured CPU, with a small floor  | $0.0504 per allocated vCPU-hour                               |
| Memory billing   | $0.0075 per reserved GiB-hour                             | $0.0162 per GiB-hour                                          |
| Disk             | Included while running; paused storage $0.08 per GB-month | First 5 GiB free, then $0.000108 per GiB-hour, stopped or not |
| Plan fee         | None; prepaid credit from $10                             | None published                                                |
| Free start       | 20 sandbox hours, no card                                 | $200 of compute                                               |
| Pause and resume | Files and memory, every sandbox                           | Files and memory on VM sandboxes                              |
| Regions          | One                                                       | US and EU                                                     |
| GPUs and Windows | Neither                                                   | Both                                                          |

## Cost for the same job

Take 1,000 runs of a 2 vCPU, 4 GiB sandbox. Each run lasts 60 seconds and
keeps the CPU busy for 20 CPU-seconds, which is typical of an agent that spends
most of its time waiting for a model.

```
Runtime  CPU    1,000 × 20 s / 3,600 × $0.025      = $0.14
         Memory 1,000 × 60 s / 3,600 × 4 × $0.0075 = $0.50
         Total                                        $0.64

Daytona  CPU    1,000 × 60 s / 3,600 × 2 × $0.0504 = $1.68
         Memory 1,000 × 60 s / 3,600 × 4 × $0.0162 = $1.08
         Total                                        $2.76
```

Daytona bills the vCPUs a sandbox has for as long as it runs. Runtime bills the
CPU the sandbox measurably used, with a default floor of a twentieth of a vCPU.
With both CPUs busy for the whole minute, the same job costs $1.33 on Runtime
and $2.76 on Daytona. Disk, network, taxes and free credits are excluded from
both. See [pricing](./pricing) for Runtime's terms.

## Where Daytona is stronger

- **GPUs and Windows.** Daytona offers GPU sandboxes and Windows machines.
  Runtime has neither.
- **Regions.** Daytona runs in the US and the EU. Runtime runs in one region.
- **Credits.** Daytona starts accounts with $200 of compute and runs a startup
  program. Runtime's trial is 20 sandbox hours.
- **Snapshots and forks.** Runtime's are paused while an issue is fixed; build a
  [custom image](./javascript#custom-images) to start many sandboxes from one
  setup.

## Where Runtime is stronger

- **Cost for agents that wait.** CPU you do not use is not billed.
- **One kind of sandbox.** Every Runtime sandbox is a microVM with its own
  kernel, and every one can pause with its memory. There is no class to choose.
- **Setup by the agent.** An agent runs `npx withruntime run --trial -- ...`,
  shows you a link, and starts work once you approve it in the browser. No API
  key is copied into a prompt or a config file, and the [MCP server](./mcp)
  reuses the same connection.
- **Safe retries.** Every write takes an idempotency key, and the SDKs retry
  with one automatically, so a lost response does not create a second sandbox.

## Moving from Daytona

Daytona:

```js
import { Daytona } from "@daytonaio/sdk";
const daytona = new Daytona();
const sandbox = await daytona.create();
const response = await sandbox.process.executeCommand("python3 -c 'print(6 * 7)'");
await sandbox.delete();
```

Runtime:

```ts
import { Sandbox } from "withruntime";
const box = await Sandbox.create({ funding: "trial" });
try {
  console.log((await box.exec("python3 -c 'print(6 * 7)'", { check: true })).stdout);
} finally {
  await box.stop();
}
```

To have a coding agent make the switch, test it and compare costs on your own
workload, give it the prompt in [migration](./migrate). Keep Daytona available
until the same job passes on both.

## Sources

- [Daytona pricing](https://www.daytona.io/pricing)
- [Daytona sandboxes](https://www.daytona.io/docs/en/sandboxes)
- [Daytona on microVMs, pause and fork](https://www.daytona.io/dotfiles/vms-pause-and-fork)
- Runtime [pricing](./pricing), [security](./security) and [products](./products)