Warm pools

What it is

A job gets a running VM in 1.2 ms, because the boot already happened.

A warm pool keeps FlashVMs booted, networked and parked, ready for work. A job claims one and starts at once. The pool boots a replacement behind it, so the next job never waits either.

Why it matters

An 18 ms cold start is already instant, and a warm pool removes even that. When agent tasks arrive in bursts, every millisecond on the path is multiplied. A warm pool takes boot time off the critical path entirely: every request meets a VM that is already up, already on the network, already waiting.

• No boot on the hot path. Claim a warm VM in 1.2 ms and run the job immediately.
• Fresh every time. Each job gets a brand-new VM; used ones are retired, and the pool replaces them.
• Cheap to keep ready. An idle VM holds as little as 27 MB of host memory, so a deep bench costs little.

Runs on

• Linux x86_64
• Linux arm64
• macOS
• Windows x64
• Windows arm64

How it works

Create a pool of any shape, claim a member when work arrives, and the pool refills itself.

CLI

flash pool create --count 5 --vcpus 1 --mem-mib 256 --nic kind=nat --wait-idle 300
flash pool members POOL_ID
flash claim VM_ID --entry 'python3 /work/task.py'
flash exec VM_ID -- sh -c 'cat /work/result.txt'

MCP

flash_pool(method: "POST", path: "/v1/vm-pools", body: {shape: {vcpus: 1, mem_mib: 256, nics: [{kind: "nat"}]}, count: 5})
flash_pool(method: "GET", path: "/v1/vm-pools/POOL_ID/members?state=idle")
flash_cli(args: ["claim", "VM_ID", "--entry", "python3 /work/task.py"])

API

POST /v1/vm-pools {"shape": {"vcpus": 1, "mem_mib": 256, "nics": [{"kind": "nat"}]}, "count": 5}
GET  /v1/vm-pools/{pool_id}/members?state=idle
PUT  /v1/flashvm/workload {"entry": "python3 /work/task.py"}

The result

A running, networked VM in a job's hands in 1.2 ms, its boot already behind it.

Bursts of work meet a bench of ready machines, and the bench refills on its own. Waiting for a sandbox stops being part of the job.