Rate limits
A 429 response means the request exceeded a relevant budget. Observe Retry-After and use bounded backoff. Retrying immediately consumes resources without creating capacity. The limit applies to the documented account, key, computer or IP bucket, so multiple workers share it.
Planned launch budgets
| Bucket | Tier 1 | Tier 2 |
|---|---|---|
| Control API, general | 10 req/s, burst 40 | 25 req/s, burst 100 |
| Create / start / resume | 5/min, 20/h, 60/day | 12/min, 60/h, 300/day |
| Access tokens | 60/min per key | 120/min per key |
| Data API, exec | 5/s per computer | 10/s per computer |
| Desktop actions / screenshots | 20/s / 5/s per computer | same |
| Snapshots | 6/h | 20/h |
| Private images | 2/day | 10/day |
| Top-up links | 1 open invoice; 5/day (Tier 0: 2/day) | 1 open invoice; 10/day |
| Unauthenticated, per IP | 30 req/min | 30 req/min |
| API keys (Tier 0 also) | 100 active; create plus rotation: 100 successful issuances per rolling 24 h | same |
These budgets are planned and may change before launch. Console requests never count against these buckets; the console applies its own request and authentication limits.
Tier 0 inherits the general limits of Tier 1, except 2 top-ups per day; this grants no resource permissions. Count-per-period rows are fixed counts over rolling periods, not token buckets that allow twice the count.
Every API HTTP response, including errors and WebSocket 101 handshakes, carries real RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset values; a 429 also carries Retry-After. Exec and process starts share a per-computer rolling-second budget (5/s on Tier 0 and 1, 10/s on Tier 2), without extra burst. Other data routes report that budget without consuming it, except desktop actions (20 calls per second, not individual actions) and screenshots (5 per second), which report their own buckets. Failures before authentication report 30/min per IP.
Per computer, at most 8 concurrent streams (exec and output streams, file downloads, WebSocket sessions) and 8 concurrent short requests are admitted, counted separately. A concurrency refusal is 429 rate_limited with CE-Not-Forwarded: true and that bucket's headers.
Platform admission limits can refuse create, start, resume and restart with 503 host_busy; an account can use only part of the shared admission capacity (429 rate_limited), and your tier limits still apply, so the effective limit is the smaller one. Stop, pause and delete are never refused by platform limits: they queue.
API-key quotas are per account and identical for Tier 0, 1 and 2, and include console and child keys. The active-key quota returns 403 tier_limit and the issuance budget returns 429 rate_limited with Retry-After; an exact idempotent replay does not consume another issuance, and varying Idempotency-Key cannot bypass the limits. Revocation is always available. Metadata of revoked or expired keys is kept for 30 days.
Distinguish capacity from rate
host_busy and capacity_unavailable are admission refusals, not a license to spin until capacity appears. A response failure can arrive after a forwarded guest action already ran; do not infer "not executed" from a transport error. Keep the idempotency identity for supported mutations and inspect the original resource before retrying.
Errors describes the fixed problem codes and Keys and limits for agents the issuance budget.
Dory is in development; these pages describe the planned service and may change. Questions: support@computeengines.com.