Why Ortam
Updated 27 October 2026
Ortam gives a coding agent a machine it keeps. Each Sandbox is a Linux VM whose whole disk is saved while the agent works. The next job starts with the repository, dependencies and Docker images in place instead of rebuilding them.
Setup on every job
A coding agent on a fresh machine starts each job with setup. It clones the repository, installs dependencies, pulls container images and fills the build cache. When the sandbox is thrown away after each job, that setup repeats on every job.
That repetition costs three things:
- Waiting. Setup delays the start of every task. On a 10-minute job, 4 minutes of setup is 40% of the job. At 6,000 jobs a month, it adds up to 400 hours. These are example inputs, so time your own setup on a fresh machine.
- Failures. Every network step at the start of a job can fail. A package mirror can be slow, a registry can limit pulls, and a dependency version can be withdrawn. Someone then has to rerun the job.
- Context. If the agent runs setup itself, every install command and its long output pass through the model. That costs tokens and leaves less room for the task.
Three ways to start a job
Most providers also let you install dependencies into a template, image or snapshot and give each job a fresh copy. That makes three ways to start a job:
| Compared | Fresh | Prebuilt image | Kept disk |
|---|---|---|---|
| Wait before each job | Full setup | Catch-up since the image | Start, then catch-up since the last job |
| Can fail on | Every network step | Changes since the image | Changes since the last job |
| Carries over earlier changes | No | No, between rebuilds | Yes |
| Parallel jobs on a repository | Yes | Yes | One per working tree |
| Build cache | Empty | As old as the image | Current |
- Fresh fits untrusted code, one-off jobs, and setup that takes seconds.
- Prebuilt fits parallel tasks on the same repositories, each from a known state.
- Kept fits long work in sequence on one repository, and large incremental builds.
Ortam does the second and third. For prebuilt, take a Snapshot of a set-up Sandbox and start a Sandbox from it per task. Each copy writes to its own disk. For kept, stop a Sandbox and start it again. The next job finds the repository, dependencies and Docker images as they were at the last save. Keep environments warm builds both.
A kept disk has to be restored before the job can use it. A large disk can take longer to restore than a small image takes to boot. Ortam doesn’t publish its start time yet, so measure it on a disk of your size.
A kept disk collects changes over time, such as a package an agent installed for one task. Rebuild it from scratch when the lockfile changes. Run CI on clean machines, so nothing installed by hand goes unnoticed.
When Ortam isn't the right fit
- You need memory and running processes to survive. Ortam saves the disk, not memory. A Sandbox starts again by booting from its last save. Enabled services come back, but running processes don’t. For work that must resume mid-process, use a provider that pauses a VM’s memory.
- Each job runs untrusted code for seconds. If setup takes seconds and nothing should carry over between jobs, a fresh disposable sandbox is simpler.
- You need GPUs, or a location Ortam doesn’t run in. Ortam’s sizes are CPU machines, and Sandboxes run in Germany and Finland.
- You need it today without waiting. Ortam is in private beta and lets teams in a few at a time.
What ten providers keep, compared goes through the alternatives provider by provider, and How Ortam works follows one Sandbox from creation to its next start.