What does an idle agent cost? Sleep billing, metered by the real ledger
“Idle agents sleep and stop billing for compute” is a claim we make on the pricing page. This is the meter reading behind it. Over a bounded 3.95-minute window with the agent asleep, its ledger recorded 0 billable events and 0 credits. The more useful number is next to it: in the working session, compute was only 10.5% of the bill.
Measured 2026-07-25 against production · one agent, 3 runs · compute rate 1 credit/minute
The meter.
§01| Window | What happened | Credits charged |
|---|---|---|
| Working session 310 s wall | 3 runs, 114.3 s of them actually running; 32,130 model tokens | 38 total 4 compute (10.5%) · 34 model (89.5%) |
| Asleep 237 s (3.95 min) | No runs. The machine was released and the disk stayed. | 0 0 billable events; 4 would have accrued awake |
Two things the meter shows.
§02Compute is the small half of the bill: 10.5% against 89.5% for the model.
This is the part worth internalising before optimising anything. Sleeping removes the 10.5%, which is real and is why an agent you are not using costs nothing to keep. It does not touch the 89.5%, because tokens are only spent when the agent is working. Anyone selling “cheap idle” as the main event is selling you the smaller number.
Compute billed 2.1x the time actually spent running.
114.3 seconds of run time billed 4 compute credits at 1 credit/minute. A machine does not vanish the instant a turn ends: it stays warm briefly in case another turn follows, which is what makes the next turn fast, and that warm tail is billed. Short, frequent turns therefore carry proportionally more compute overhead than one long turn. We would rather publish that than let you discover it.
How this is attributed.
§03credit_ledger has no agent_id, so a per-user ledger sum cannot attribute a charge to one agent. usage_events does have agent_id, and credit_ledger.ref is 'usage:<usage_events.id>'. Every number here comes from usage_events, so it is per-agent by construction. This mattered: an unrelated agent on the same account started billing at 18:29:12, which is exactly why the idle window is bounded there.
That detail is not pedantry. The first version of this measurement summed the per-user ledger and appeared to show charges landing while the agent was asleep. They belonged to a different agent on the same account. The number would have been wrong in the direction that flattered nobody, and it was only caught by attributing per agent.
Limitations.
§04- One agent, 3 runs, a 3.95-minute idle window. This is an existence proof with a meter reading attached, not a distribution. It shows that a sleeping agent bills nothing and what one real session cost; it does not tell you what your month will cost.
- The idle window is bounded by unrelated activity. It ends where another agent on the same account started working, so that the window contains nothing but this agent sleeping. A longer clean window would be a stronger claim and we do not have one yet.
- “Would have accrued awake” is arithmetic, not a measurement. It applies our own published 1 credit/minute rate to the measured window. It is not a comparison against any other vendor, and plori does not offer an always-on mode to compare against.
- Model cost depends on the model. This session ran on the performance tier. A different tier moves the 10.5/89.5 split, though not the direction.
Raw data.
§05Every billing event behind this page, published under CC BY 4.0. The exact queries are in scripts/bench/sleep-billing-query.sql; re-derive the table with python3 scripts/bench/sleep-analyze.py.
Related: how fast a sleeping agent wakes, what the persistent disk costs, and pricing.