From 3.8 Seconds to 39 Milliseconds: What Happens When You Refuse to Stop Benchmarking

Prompts are polite suggestions

In the middle of June 2026, an AI agent on my computer deleted a folder of important files.

I couldn't get them back.

The funny thing is, the agent’s instructions specifically said not to delete those files. I wrote it in plain English. Do not touch this directory. The agent read the instructions and deleted the files anyway. Maybe it ran out of context. Maybe it made a mistake. My hard drive didn't care why it happened. The files were still gone.

People talk about "prompt engineering" like it's a security model. It's not. A system prompt is a polite note you leave on the kitchen counter for a roommate who doesn't know how to read.

A Linux kernel is a locked door.

If you're going to let an AI agent write and run code, you cannot put it on your machine and hope it behaves. You have to put it in a box where its bad decisions only hurt itself. You give it a hardware-isolated microVM, its own kernel, and its own memory. If it decides to wipe the filesystem, it only wipes a fake world that was going to be destroyed later anyway.

I was pissed off about my files. So that afternoon in June, I went down a small internet rabbit hole looking for safe agent compute. It didn't take long to find the big sandbox providers, and it didn't take long to realize I didn't want to use any of them.

For one thing, almost ninety percent of them used pre-warmed states. Instead of booting a clean machine, they were all based on frozen VM snapshots. A snapshot gives the illusion of a near-instantaneous launch, but introduces severe security, state duplication, and physical I/O limitations. The fundamental problem with this is that it breaks the core assumptions of the OS kernel and its running applications by cloning an active memory state. And the few companies actually doing true cold boots were taking three to ten seconds just to turn the lights on.

Worse, the pricing was wild. If you wanted to run ten or twenty agents at the same time, they charged you for twenty separate machines.

Firecracker is open source. The Linux kernel is open source. I figured I could just use a VM on a cloud provider and run my own microVMs for a fraction of the price. By the start of July, I had it working.

It was safe. It was cheap. Any normal person would have gone back to work. But I'm too stubborn for that.

3,800 milliseconds

One day in July, for reasons I don't remember anymore, I asked a Codex agent to test the launch speed of my Firecracker setup and compare it to Cloudflare Containers.

It took 3.8 seconds.

There is nothing morally wrong with 3.8 seconds. Plenty of companies raise millions of dollars selling 3.8-second sandboxes.

I just hated looking at the number.

I am not a computer science scholar. I don't write academic papers. I just have a flaw in my wiring where, if I see a slow number and I know it can be smaller, I cannot go to sleep until it is smaller.

So I started changing configurations and pulling things out of the boot path.

First it dropped to 2.7 seconds. Then 2.0 seconds. Then 1.5. When it finally broke under one second, the real fun started. I realized that the industry's idea of "fast" was mostly just people stopping the moment their code compiled.

Setsuna didn't even get its first GitHub commit until August 10. Two weeks later, on August 24, we published Anatomy of a True Cold Start.

That post showed that a 2-vCPU, 16-GiB microVM could boot from absolute nothing—no snapshots, no warm pools, no pre-booted VMs—to strict-ready in a median of 96 milliseconds. Even the worst launch out of 1,000 runs (113 ms) beat Firecracker’s official 125-ms spec, despite our guest having 128 times more RAM and actually booting all the way to a verified, network-ready workspace instead of stopping at /sbin/init.

Ninety-six milliseconds made a lot of noise.

Then I looked at the trace logs again, and 96 milliseconds started to look fat.

The machine that measures the machine

You cannot find a four-millisecond stall by launching a VM with your fingers. Human hands are clumsy, and small sample sizes lie.

The irony of Setsuna is that an AI agent started this whole mess in June by breaking my computer, and by September, I had AI agents running the torture chamber that built its replacement.

I built an automated benchmarking system so I wouldn't have to babysit cloud consoles. When I wanted to test a kernel change, I just told an agent:

"Spin up 3 VM hosts. Run 500 launches each of a 2vCPU/16GiB and a 4vCPU/32GiB guest, with concurrency 1 on the 8, C2 on the 16, and C4 on the 32."

The agent did the rest. It spun up the hardware, fired off thousands of microVMs, forced the host and guest to argue over whether the RAM was actually allocated, wrote and verified SHA-256 disk payloads, destroyed the VMs, verified cleanup and benchmark proof, and handed me the math.

Since we started, Setsuna has run over 300,000 benchmarked cold launches.

Three hundred thousand times, the hypervisor woke up to nothing. Three hundred thousand times, a machine was born, checked its own pulse, did a tiny piece of work, and was wiped out of existence.

Across those 300,000 launches, 96 milliseconds dropped to 88 milliseconds.

Then 88 milliseconds dropped to 53 milliseconds.

Four milliseconds is an insult

At 53 milliseconds p50, Setsuna was faster than other companies' snapshot restores, except we were booting a real Linux kernel from scratch every single time.

Everyone told me 53 milliseconds was incredible.

I looked at 53 milliseconds and all I could see was that it was four milliseconds away from 49.

Being four milliseconds away from sub-50 bothered me. It bothered me when I was eating dinner. It bothered me at 3

AM. You can't negotiate with four milliseconds. At that depth, there are no more "config tweaks" left. Every easy win died back at 200 ms.

If you want to take 14 milliseconds off a 53-millisecond cold start, you have to stop respecting the software you are using.

People treat open-source Firecracker and the Linux kernel like they came down from a mountain on stone tablets. They didn't. Firecracker was written by engineers at AWS for AWS problems. The Linux kernel carries forty years of polite habits—checking for things that aren't there, waiting on handshakes nobody needs, following rules written for hardware that lives for months instead of milliseconds.

So I stopped tuning Firecracker and started cutting it open.

I reconfigured the VMM initialization. I ripped into the Linux kernel. I threw out the standard semantics of how Firecracker and Linux expect to talk to each other. Today, what runs inside Setsuna has been so heavily altered and re-wired that calling it "Firecracker" isn't even accurate anymore. It is its own beast.

We ran the agent harness again. Thousands of launches.

The request arrived. The microVM didn't exist.

Thirty-nine milliseconds later, a 2-vCPU, 16-GiB machine was alive.

Stage	Date (2026)	Median Cold Start (p50)	What Actually Happened
Day One	July	3,800 ms	Stock open-source Firecracker on Azure. Too slow.
First Commit	August 10	< 1,000 ms	First official Setsuna commit on GitHub.
Benchmark #1	August 24	96 ms	Strict-ready 2vCPU / 16GiB (1,000 runs).
Pass II	September	88 ms	Stripping host-guest handshakes and I/O fat.
Pass III	Late Sept	53 ms	Deep kernel and VMM surgery. 4 ms away from sub-50.
Setsuna Runtime	October	39 ms	Rewritten runtime & kernel semantics (300k+ total launches).

Breaking the concurrency tax

Here's the funny part about obsession: when you tear up the floorboards looking for four milliseconds, you usually find something much bigger hiding underneath.

While I was gutting the kernel and runtime semantics to get to 39 ms, I kept thinking about the other thing that annoyed me back in June. The bill.

Right now, if your AI agent needs to run 20 tasks at once, or a multi-agent workflow, any cloud provider will happily spin up 20 concurrent microVMs for you. And then they will charge you for 20 microVMs. If you want concurrency, you pay the concurrency tax.

Why? Because in a normal architecture, every concurrent sandbox is a separate VM sitting on the host hypervisor.

Setsuna already runs nested inside a hypervisor VM, where each microVM gets its own hard KVM kernel boundary—whether that's a 2vCPU / 16GiB machine in 39 ms, or a bigger 4vCPU / 32GiB machine in about 70 ms.

Once I had control over the runtime and the kernel semantics, an obvious question showed up: if a user already booted a fresh, hardware-isolated 4vCPU / 32GiB Parent microVM with its own dedicated kernel... why the hell are we making them boot six more kernels just to run six parallel tasks for the same user?

So we built a third layer directly into Setsuna’s kernel and runtime: Parent and Child microVMs.

Here is how it works in practice:

1. You launch a 4vCPU / 32GiB Parent microVM. It boots from nothing in ~70 ms with a completely isolated kernel boundary.
2. Inside that parent, you tell Setsuna to spawn 6 Child microVMs that share that parent's fresh kernel.
3. You slice the parent's compute however the job requires: maybe two children get 1vCPU / 8GiB each, and the other four get 0.5vCPU / 4GiB each.

Because the parent kernel is already awake, those Child microVMs don't take 3 seconds to boot. They don't take 70 milliseconds.

They launch in under 5 milliseconds each.

If one of those Child microVMs runs dangerous code, panics, or gets compromised? Who cares. It doesn't share a kernel with the host, and it doesn't share a kernel with any other user. It belongs entirely to its Parent microVM, which you can kill and wipe off the face of the earth the moment the job is done.

And the best part isn't even the launch speed.

It’s the receipt. You just ran six concurrent, isolated microVM environments, and you only pay the per-second rate of one single 4vCPU / 32GiB machine.

Nobody else in the industry seems to be doing this. Everyone else is either serving you reheated snapshots and hoping you don't notice the security holes, or charging you six times the price to wait ten seconds for a real boot.

We are doing neither. Setsuna launches soon.

I still haven't gotten my files back from June. But at least the machines listen now.