How fast does a sleeping agent wake? Cold-start latency on plori, measured end to end
An idle plori agent sleeps and costs nothing, so the question that matters is the wake: from a cold visitor with no session to the first streamed token of a reply, plori takes about 2.6 s at the median and 3.5 s at p90, measured end to end against production, network round trips included.
Data window 2026-07-18 to 2026-07-18 (UTC) · 110 samples, 0 excluded · Revised 2026-07-18
The numbers.
§01| Step | p50 | p90 | p99 | max | samples |
|---|---|---|---|---|---|
| Anonymous session mintPOST /v1/anon/sessions, a fresh trial agent | 379 ms | 468 ms | 673 ms | 1,317 ms | 110 |
| Warm-pod attach (wake to ready)claim a machine from the warm pool, disk mounted | 1,006 ms | 1,591 ms | 4,403 ms | 4,950 ms | 110 |
| First token after sendrun.create over WebSocket to the first streamed text delta | 1,228 ms | 1,486 ms | 2,337 ms | 5,479 ms | 110 |
| Total: wake to first tokenmint + attach + first token, the end-to-end wait | 2,642 ms | 3,493 ms | 6,543 ms | 6,766 ms | 110 |
The total row is the sum of the three phases per sample: session mint, then warm-pod attach, then the streamed turn's first token. It is what a first-time visitor actually waits between opening plori.ai/agent and seeing the agent start to answer.
Methodology.
§02This is a controlled probe, not user traffic. Every 3 minutes a probe host runs the exact flow a first-time visitor hits, against live production, and records one sample:
- Anonymous trial mint. POST /v1/anon/sessions with a fresh device id creates a new trial agent; the wall time is mint_ms.
- Warm-pod attach. The agent wakes: a machine is claimed from the warm pool and its disk is mounted. The wall time, including any async re-attach polling, is attach_ms.
- One streamed turn. A WebSocket run with the prompt "Reply with exactly OK". Offsets from the run.create send: run started, first streamed text delta (first_delta_ms, the wake-to-first-token moment), and run finished.
Collection window: 2026-07-18 to 2026-07-18 (UTC), 110 samples at a 3-minute cadence. Vantage: a Singapore datacenter host, probing the production region (sea) over the public internet, so real network round trips are included by design. Samples that errored are excluded and counted: 0 in this window. Percentiles use linear interpolation between closest ranks.
Not measured here: resuming a registered account's existing agent (this is the anonymous first-visit path), and anything after the first token (the model's full answer time depends on the model and the prompt). Warm-pool misses that force a cold boot are not separated out; when the pool misses, that boot is simply part of the attach time reported above.
Limitations.
§03- One region (sea) and one vantage (Singapore datacenter); other routes will see different network latency.
- A controlled one-line prompt; longer prompts and tool-using turns take longer after the first token.
- The anonymous warm-pool path only; registered-account resume is a different path and is not covered by these numbers.
- 110 samples in this window; tail percentiles (p99, max) are noisy at this sample size.
- No cross-vendor comparison: this page measures plori against itself, under a stated method, and claims nothing about other platforms.
Reproducibility and data.
§04The probe and analysis scripts are in scripts/bench/ (coldstart-sample.sh, coldstart-collect.sh, coldstart-analyze.py) on plori's GitHub, github.com/plori-ai/coldstart-bench. The sampler is a thin wrapper over the same WebSocket protocol the web app uses, so it measures the product path, not a private fast lane.
Raw data, one row per sample: data.csv · data.json (with collection metadata). The data is published under CC BY 4.0; reuse it with attribution to plori.
plori engineering. Data window and revision date are stated above; the page is regenerated only when new data is collected.