Kubernetes Finally Has a Checkpoint/Restore Working Group. Here's What Pausing a Mid-Task Agent Sandbox Actually Saves

Here is the number that should reframe every "CRIU will make agent sandboxes cheap" thread you have read this year. Take a background coding agent on a 2 vCPU / 4 GiB sandbox, 6,000 sessions a month, each session doing 20 minutes of real work and then sitting open for four hours across six turns while a human reviews the pull request. At a representative metered rate of $0.0504/vCPU-hour plus $0.0162/GiB-hour, the monthly bill for that fleet looks like this:

Two-thirds of the available savings is already sitting on the table, today, with no CRIU anywhere in the picture. The Kubernetes Checkpoint/Restore Working Group, chartered on January 21, 2026, is competing for the remaining third — a further 59% off an already-hibernating bill.

That is still a real prize. It is just not the prize the hype is selling. And there is a fourth row that the table above leaves off, because it needs its own explanation: what the kubelet's checkpoint API gives you right now, which is not a hibernation loop at all.

What the working group is actually chartered to do​

The WG's announcement lists six use cases, and only one of them is the forensics story that container checkpointing has been known for since 2022: optimizing resource use for interactive workloads like Jupyter notebooks and chatbots, accelerating startup for slow-initializing apps (Java, LLM inference), periodic checkpointing for fault tolerance, preemption-aware scheduling, pod migration across nodes for maintenance, and forensic checkpointing for incident investigation. It meets every second Thursday at 17:00 UTC in #wg-checkpoint-restore.

The underlying machinery is older than the WG. The kubelet exposes a node-local checkpoint API — an HTTP POST to https://localhost:10250/checkpoint/<namespace>/<pod>/<container> behind the ContainerCheckpoint feature gate. It landed alpha in Kubernetes v1.25 and graduated to beta in v1.30. The kubelet asks the CRI runtime, the runtime asks the low-level runtime (runc), and runc invokes CRIU, which writes a tar archive containing memory pages, filesystem deltas, process state, open files, and sockets.

Here is the part that matters and that almost nobody mentions: there is no restore API. Not alpha, not beta, not anywhere.

To bring a checkpoint back you run checkpointctl build to convert the tarball into an OCI image using Buildah, push that image to a registry, and then set it as a pod's image: field. That is a build-and-deploy pipeline wearing a hibernation costume. It is a genuinely good forensics tool — freeze a compromised container, ship it to an analyst, resume it in a lab — and a genuinely bad way to pause a chatbot between turns.

Running the numbers on today's path​

Put that pipeline into the same cost model and it falls apart in an instructive way. Assume a 4 GiB sandbox produces a ~1.5 GiB compressed checkpoint image, and that the build → push → pull → start round trip takes about three minutes. With an aggressive 2-minute idle grace and six turns per session:

• Paid compute: 20 min active + 12 min grace + 5 × 3 min of restore = 47 min/session → $778/month

Cheaper than PVC hibernation! On the compute line. Now count the rest. Six checkpoints per session × 6,000 sessions = 36,000 images a month at 1.5 GiB each: 54 TiB written to and read from your container registry every month, roughly 170 Mbit/s sustained. Object storage for it is nearly free if you expire images within the hour (a couple of dollars). The transfer is not. On a cheap metered network at $0.01/GiB that is $540/month; on a hyperscaler's $0.085/GiB egress it is $4,600/month — more than the entire always-on bill you were trying to escape.

And your agent takes three minutes to answer the second question.

So the honest fourth row: today's kubelet checkpoint API is not option C. It is a forensics primitive whose cost profile happens to look attractive on the compute line and disastrous everywhere else. This is precisely why the working group exists — the gap between "we can dump process state" and "we can pause and resume a workload" is the whole agenda.

The sensitivity that actually decides this​

The variable that drives everything is not vCPU price. It is how chatty the session is — how many times the sandbox has to wake up. Same workload, same rates, varying the number of turns per session:

B pays a 10-minute idle grace per cycle plus ~40 seconds of cold re-initialization per resume. C pays a 2-minute grace plus ~2 seconds of restore. At 60 turns in a 4h20m session there is only four minutes between turns, so a 10-minute timeout never fires — PVC hibernation quietly degenerates into leaving the box running, and saves nothing at all.

Now the row that keeps this honest. That table gives B a 10-minute grace and C a 2-minute one, which is doing a lot of work. Force both to the same 2-minute aggression at six turns:

• B at 2-min grace: 20 + 12 + 5 × 40 s = 35.3 min → $0.0975/session
• C at 2-min grace: 32.2 min → $0.0888/session

Nine percent apart. Most of the gap in the headline table is not CRIU being magic; it is CRIU being fast enough that you dare to set the timeout that aggressively. If your cold restart is genuinely cheap, you can set a 2-minute timeout today and capture nearly all of it.

Which points straight at the real question.

What CRIU actually buys, and when it buys nothing​

Not "idle is free." PVC-based hibernation already gives you that: kubernetes-sigs/agent-sandbox ships Suspend/Resume (PVC-based) as a completed roadmap item — when a sandbox goes idle the controller snapshots status, scales the pod to zero, keeps the PersistentVolumeClaim, and re-mounts the identical volume on resume. Files, git checkout, and scratch state survive intact. Auto Suspend/Resume and Scale to Zero are still listed as planned.

What does not survive is everything in RAM. That is the entire CRIU delta, and its value is exactly the cost of rebuilding your process's warm state:

• A bare shell agent that runs git and pytest — near zero. Cold start is a second; PVC hibernation is already optimal. Don't wait for the WG.
• An agent holding a warm Python interpreter with heavy imports — Modal's gVisor-based memory snapshots take a import torch container from ~5 seconds cold to 1.05 s at p50, and a Stable Diffusion path from ~13 s to 3.5 s, by collapsing roughly 26,000 syscalls into what amounts to a single file load.
• An agent with an indexed repository — an LSP server that spent 45 seconds building a symbol index for a large monorepo rebuilds it on every single resume under PVC hibernation, and never rebuilds it under checkpoint/restore. At 20 turns a session, that is 15 minutes of pure re-indexing per session that simply disappears.

The rule of thumb: CRIU is worth waiting for in proportion to how expensive your process's first 60 seconds are. Measure that before you plan around it.

The gaps between here and there​

Even granting a real restore API, production needs several things that do not exist yet:

• gVisor. runsc can checkpoint itself, but containerd's CRI CheckpointContainer method is not implemented for the runsc shim. The sandbox runtime most agent platforms actually chose cannot be driven through the kubelet API at all. Modal shipped its own path precisely because the standard one doesn't reach.
• Kata Containers. No checkpoint/restore commands, and the guest kernel is built without CONFIG_CHECKPOINT_RESTORE. The proposed route is VM save/restore, which is a different mechanism with a different image-size story.
• GPUs. Transparent GPU-state checkpointing is still research (CRIUgpu, Feb 2025). Modal's snapshots explicitly exclude GPU state; initialization must happen after restore.
• Live sockets don't come back. An agent holding an open connection to a model API reconnects on resume, and your harness has to be built for that.
• Restore is hardware-fussy. Modal documents snapshots breaking across CPU instruction-set differences (a node missing pclmulqdq), NVIDIA driver versions, and runtime versions. Restore lands on a homogeneous node pool or it doesn't land.
• Image size. 100 MiB to 10 GiB per snapshot. Storage is cheap; moving them is not, as the $540-to-$4,600 registry-transfer spread above shows.

And the tell: the agent-sandbox roadmap does not mention CRIU anywhere. The project closest to this problem is betting on volumes and warm pools, not process state.

What to do this quarter​

Skip the waiting. The 67% is available now, on any self-hosted Kubernetes fleet:

1. Hibernate on a PVC and drop the timeout. The idle grace is the single biggest line in the bill — a 10-minute default costs 5× what a 2-minute one does at six turns per session. Tighten it until users complain, then back off one notch.
2. Measure your cold-resume cost before optimizing anything else. If it's under ~10 seconds, PVC hibernation is your endgame and CRIU would buy you 9%. If it's 45 seconds of LSP indexing, that number is your CRIU business case — write it down now.
3. Pin sandboxes to a homogeneous node pool anyway. Same CPU generation, same kernel, same runtime version. It costs nothing today and it is a precondition for every restore path that lands later.
4. Use the checkpoint API for what it's actually good at. A crash-looping or compromised agent container is exactly the forensics case the beta API was built for. checkpointctl on a stuck sandbox beats reconstructing state from logs.

The working group's real contribution over the next year probably isn't the cost curve at all. It's turning "pause a running workload" into a primitive the scheduler can use — preemption-aware bin packing, node drains that don't cold-restart every pod, migration for maintenance. Cheap idle agent sandboxes are a side effect of that, and a smaller one than the headlines suggest.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.

Sources​

• Announcing the Checkpoint/Restore Working Group — Kubernetes Contributors, Jan 21 2026
• CRIU project — Kubernetes integration page
• Forensic container checkpointing in Kubernetes — Kubernetes Blog
• kubernetes-sigs/agent-sandbox roadmap
• Memory snapshots: checkpoint/restore for sub-second startup — Modal
• Support container checkpoint/restore for gVisor runtime — containerd #12280
• Thoughts on CONFIG_CHECKPOINT_RESTORE — Kata Containers #10385
• CRIUgpu: Transparent Checkpointing of GPU-Accelerated Workloads (arXiv 2502.16631)
• AI Sandbox pricing comparison (2026) — Northflank