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.
The dense infra console, an early design. Not built yet; the numbers follow the white paper's model.
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
- 01
Warm pools
You pay for sandboxes that do nothing.
Agents are busy about one second in twenty. A warm pool bills all twenty.
- 02
Cold starts
Starting fresh takes seconds.
Containers and VMs that boot on demand make the user wait, so nobody lets them sleep.
- 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.
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 →- 0 msRequest arrives at the doorHTTP POST /run
- 2 msSandbox found in a snapshoton local disk
- 37 msMemory mapped, pages load as touchedlazy restore
- 141 msProcess running againsame PID, same state
- 148 msFirst byte to the callertarget 250 ms
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 →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 →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 →Runs where you already pay
- AWS
- Google Cloud
- Azure
- Oracle Cloud
- DigitalOcean
- Akamai
- Vultr
- Hetzner
- Kubernetes
- Your servers
A first look
What it could feel like.
Early design for the first piece: many agent sandboxes on your own machine, in Kiri. Not built yet; names, commands and screens will change.
$ kiri sandbox run --count 100 --image agent:latest --sleep-when-idle ✓ 100 sandboxes from 1 shared image awake 6 asleep 94 memory held only by the awake $ kiri sandbox ls NAMESTATEIMAGEDOINGagent-001awakeagent:latestrunning testsagent-002asleepagent:latestwaiting on the modelagent-003asleepagent:latestwaiting on the modelagent-004wakingagent:latestrequest arrivedagent-005asleepagent:latestidleagent-006awakeagent:latestwriting a patch… 94 more $ kiri sandbox freeze agent-001 ✓ agent-001 frozen · memory returned to the host · wakes on the next request $
Image agent:latest
Libraries python 3.13
Model weights none
● Woke on a request
● Frozen after idling
● Woke on a request
CPU none
Memory returned
State in a snapshot
Illustration of a design that isn't built. Counts are examples, not measurements.
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.
docker run, start to finish.Docker Desktop 178 msColima 152 ms
Docker Desktop 163 ms
Docker Desktop 11.4/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.
04Who it is for
From your laptop to your servers.
Developers running many agents
Ten to a hundred coding agents in parallel on your own Mac or Linux machine, each in its own sandbox. Free, in Kiri.
Teams that must self-host
Code that can't leave the company. Dense sandboxes in your own cloud account, on Kubernetes or on your own servers.
Platforms hosting agents
Agent and evaluation platforms that pay per sandbox-hour and buy density directly.
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.
Workloads per host
How many fit before p95 latency moves.
Wake time
Request to first byte, from asleep.
Idle cost
Memory and CPU held while doing nothing.
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.