The Pulse
Prime Intellect Adds Filesystem Checkpoints to Sandboxes
Prime Intellect has added filesystem checkpointing and forking to its VM sandboxes, letting developers branch new agent runs from a saved workspace. The checkpoints preserve files, not running processes or memory, and storage costs $0.10 pe
AI.info Team · Written with AI ·
Prime Intellect’s default account limit is 1,024 active sandboxes, and its new filesystem checkpoints let developers branch work from a saved workspace instead of rebuilding the same setup for every agent run. Checkpoint storage costs $0.10 per GiB per month, billed hourly; running a sandbox incurs separate compute charges. The feature applies to Prime’s VM sandboxes, which the company describes as designed for agentic reinforcement learning and workloads requiring stronger isolation.
Saved files, not a paused machine
A checkpoint captures the sandbox filesystem so a developer can restore it into a new sandbox or fork it to explore a different line of work. Prime’s documentation draws a clear boundary around what gets preserved:
“Checkpoints capture files only, not running processes or memory.”
Prime Intellect documentation
That means a branch can retain a repository, installed files and other disk-based setup, but it will not resume a live database, background service or interpreter exactly where the original left off. Those processes must be started again, and anything held only in memory must be reloaded. The feature is therefore a filesystem save point, not a full virtual-machine snapshot.
Forking turns one setup into several trials
For coding agents and reinforcement-learning rollouts, the practical use is to prepare an environment once, save its files, then start multiple sandboxes from that shared starting point. Each branch can try a different prompt, model action or repair without repeating the initial setup. Developers can also checkpoint a branch and restore from it later, allowing experiments to build on intermediate filesystem states.
Prime’s documented command for a direct fork is prime sandbox fork; users can also create a checkpoint and restore it by ID through the CLI or Python SDK. The resulting sandbox inherits the source’s CPU, memory and timeout unless the user overrides those settings. Once a checkpoint reaches DURABLE, it survives deletion of its source sandbox; before that status, Prime says the original sandbox must remain running.
Storage and runtime charges are separate
Prime lists checkpoint storage at $0.10 per GiB per month, charged hourly, plus a one-time upload fee equal to one day of storage when the checkpoint becomes durable. Running a sandbox is billed separately at $0.02 per vCPU hour, $0.0125 per GiB of memory per hour and $0.0002 per GiB of disk per hour. The company says those sandbox rates are valid through December 22, 2026.
At the documented example rate, one sandbox with 1 vCPU, 2 GiB of memory and 5 GiB of disk costs $0.046 an hour before checkpoint storage. The default account limits include 4,096 total vCPUs and 32,768 GiB of storage, as well as the 1,024 active-sandbox cap. Every fork uses sandbox resources, so parallel exploration still counts against account limits and incurs running costs.
The operational boundaries remain important
Filesystem branching can reduce repeated cloning and dependency installation, but it does not remove the work of restarting services or loading models. A checkpoint can also carry any secrets or sensitive data written to disk, so teams need to inspect what they save and who can restore it. Prime says encrypted sandbox secrets are injected as environment variables, but data deliberately written into files becomes part of the saved filesystem.
Prime’s documentation does not specify how long a fork takes, how long checkpoints are retained, or a maximum depth for repeatedly checkpointing and branching. Those details matter for teams planning large rollout trees, where storage, startup time and concurrent-sandbox limits shape how many experiments can run at once. For now, the documented guarantee is narrower: save files, wait for DURABLE, and restore or fork the workspace into another VM sandbox.