Capability without always-on machines.
Can a million agents run without machines?
Why a sleeping agent costs money
Agents are mostly asleep. They wait for a person, a schedule, or an upstream job. So the interesting question is not what a working agent costs — it is what a sleeping one costs, and that turns out to be an architectural property rather than a pricing one.
A machine cannot be stopped if stopping it destroys the agent. That is not a billing policy; it is a consequence of where the state lives. Put an agent’s state on a disk attached to the machine and the machine can never be reclaimed. Put it in storage that travels with the compute and the architecture can, in principle, put the agent to sleep without paying for reserved uptime in the gap — whether that holds under real traffic is what we are measuring.
Which means scale-to-zero is not a separate product feature alongside durability. It is an application of where state lives. You get the shape of it when durable state and compute share an address, and not otherwise — still an open Lab question, not a shipping promise.
Idle and hibernatable are not the same thing
This is where the reasoning usually goes wrong, and where it went wrong for us. An agent waiting on a model response is idle in every intuitive sense. It is also still bound to compute in flight, because a durable object cannot go to sleep while a request it is awaiting is still open.
We retracted an earlier idle metric that miscounted waiting-as-free. We lead with that because a cost argument that has never corrected itself should not be trusted.
| State | Serverless shape | Always-on machine |
|---|---|---|
| Computing | in use | in use |
| Waiting on a model or tool | still bound | still bound |
| Dormant — no session at all | no reserved machine (under study) | machine still reserved |
The advantage is not smaller machines
The obvious story is that a small isolate beats a large container. That story is mostly wrong, and it took a correction from someone who knew the deployment to see it.
Nobody runs one machine per agent. They run one machine per tenant, with several agents sharing it. Once you account for that, the memory an agent actually holds is far closer to what an isolate holds, and the allocation difference mostly disappears.
What survives is dormancy. The interesting quantity is not that the machine is smaller — it is whether anyone is renting it while the agent sleeps. That reframing matters, because it moves the argument onto a quantity that has to be measured rather than assumed.
At scale, cost stops being the question
Past a certain fleet size the question changes from what it costs to which limit binds first. Concurrency caps, storage ceilings, and the rate at which a platform will deliver scheduled wake-ups all arrive before the bill becomes interesting.
Some of those ceilings are documented. Some are acknowledged only in error messages. A cost curve with a hard wall partway up it is a different engineering decision from one that scales smoothly, and anyone planning a large fleet should work out their own version of that table before they work out their bill.
Where this loses
Agents that hold a kernel open — coding agents with a filesystem, long-running tool sessions — look much more like the always-on model, because the sandbox they need sleeps on a timer rather than on a condition. The more of your fleet lives there, the smaller the difference.
Agents that are genuinely busy erode it too. If there is no dormancy there is nothing to not pay for, and a reserved machine bought on a long commitment is cheap.
And there is a ceiling that is not a price at all: an isolate has a fixed memory allocation with no dial. A workload that does not fit does not cost more, it does not run. We name these limits because a model that only ever finds in its own favour is not a model.
- Status
- Research
- Focus
- Idle cost, resume, and coordination
- Surface
- Early / evolving
- Papers
- Findings land on /lab/papers when gated