NewWhite paper, Draft 3: a cost model and system design for dense AI workloads. Read it →
dense infra

Coming soon · Canestack Labs

Thousands of AI agents.
One machine.

Agents, sandboxes and small models sit idle most of the time. Dense infra starts each one in milliseconds, holds almost nothing while it waits, and wakes it on the next request. You pay for the work, not for the waiting.

Start in ms

No warm pools. A sandbox starts when its request arrives.

Sleep at zero

Idle sandboxes give their memory back and wait on disk.

Your cloud

Runs in your own account, on your servers or on your laptop.

01The problem

Agents wait. The bill doesn't.

A coding agent runs a test, then waits a minute for the model. A support bot answers one message every few minutes. Starts are slow, so teams keep every sandbox warm and pay for each idle second.

Kept warm 6 of 100 working

Dense 6 of 100 working

  1. 01

    Warm pools

    You pay for sandboxes that do nothing.

    Agents are busy about one second in twenty. A warm pool bills all twenty.

  2. 02

    Cold starts

    Starting fresh takes seconds.

    Containers and VMs that boot on demand make the user wait, so nobody lets them sleep.

  3. 03

    Someone else's cloud

    Hosted sandboxes take your code elsewhere.

    And your credits and commitments go unspent while you pay a second bill.

02The platform

Wake, sleep, pack and run anywhere.

Four jobs, one runtime. Each is a known hard problem; we are building them together, on the runtime under Kiri.

01

Wake on the request

A front door holds every sandbox's sockets. When a request arrives for one that is asleep, it holds the connection, restores the sandbox and passes the request in. The caller sees a slow first byte, never an error.

How the door works →
One wake, step by step target under 250 ms
  1. 1A request arrives at the doorconnection held
  2. 2The sleeping sandbox is foundpaused, compressed or on disk
  3. 3Its memory is mapped backpages load as touched
  4. 4The process runs againsame state as before
  5. 5The request is passed inthe caller sees a slower first byte
02

Sleep in tiers

Idle sandboxes step down: paused in memory, then pages compressed, then a snapshot on disk. Each step waits until sleeping saves more than waking costs, so the busy ones never notice.

The break-even rule →
The four tiers wake times are design targets
Awakerunning a request—
Pausedwakes in ~2 msafter 30 s idle
Reclaimedwakes in ~40 msafter 5 min
Snapshottedwakes in ~150 msafter break-even
03

Pack the host

Identical images, libraries and model weights are loaded once and shared. Memory goes to the sandboxes that are working, so one machine holds thousands instead of dozens.

How we will measure it →
0 awake of 1,240 on one hostIllustration
04

Run in your cloud

Connect a cloud account and dense infra starts hosts in it, or joins machines you already run: a Kubernetes node pool or your own servers. Your code stays in your account and your credits get spent.

Questions about clouds →
Where hosts can run planned
AWS
Google Cloud
Azure
Oracle Cloud
DigitalOcean
Akamai
Vultr
Hetzner
Kubernetes
Your servers

Runs where you already pay

  • AWS
  • Google Cloud
  • Azure
  • Oracle Cloud
  • DigitalOcean
  • Akamai
  • Vultr
  • Hetzner
  • Kubernetes
  • Your servers

03Where we start

Kiri already starts a container in 22 ms.

Kiri, our container runtime, replaces the dockerd, containerd, shim and runc chain with one Rust daemon and one small VM. Its start and packing numbers are what dense infra builds on.

22msA full docker run, start to finish.Docker Desktop 178 ms
Colima 152 ms
3.1msA container lifecycle through the Docker API.Colima 88 ms
Docker Desktop 163 ms
88.9/sContainers started in parallel, per second.Colima 12.9/s
Docker Desktop 11.4/s
19.7/sContainers packed per second in the density test.Colima 4.1/s
Docker Desktop 3.2/s

One kiri-bench run, one Apple Silicon Mac, every engine limited to 2 CPUs and 8 GB, 2 November 2026. Laptop numbers: servers at thousands of workloads per host are the work ahead. Benchmarks and method.

05How we will prove it

The first honest density benchmark.

Every "thousands per machine" figure we could find comes from the company selling it. Ours is a test anyone can rerun on equal hardware, against Docker, Firecracker, gVisor and a Kubernetes node, with the tests we lose left in.

METRIC 1

Workloads per host

How many fit before p95 latency moves.

METRIC 2

Wake time

Request to first byte, from asleep.

METRIC 3

Idle cost

Memory and CPU held while doing nothing.

METRIC 4

Cost per useful second

The machine's cost over the seconds of real work.

Be first to run dense.

Dense infra is not available yet. Join the waitlist and we will write when the first piece, many agents on your own machine, is ready to try.