Runtime lets each key make about 50 requests a second, with bursts of up to 200. It serves 128 requests at the same time. A request past that limit waits up to
five seconds. If no slot opens in that time, the request is refused. A
refusal is a 429 with Retry-After. It costs nothing. Both SDKs retry it with
the same idempotency key (limits).
The status code
RFC 6585, published in April 2012, defines it: "The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting")." The response "MAY include a Retry-After header indicating how long to wait before making a new request". A client that honors that header, and backs off when it is missing, recovers with no action from anyone.
Kinds of limit
| Limit | Counts | Example on Runtime |
|---|---|---|
| Rate | Requests per second | About 50 a second per key |
| Burst | Requests allowed above the rate at the same time | Up to 200 |
| Concurrency | Requests in flight at the same moment | 128 per key; 192 per organization, plus 6 per sandbox |
| Quota | Resources held, not requests | 100 sandboxes at the same time on a paid account |
A quota is a different kind of refusal. Past a quota, a create returns
quota_exceeded. The response names the limit and says when it lifts for a new
account (how many at the same time).
Why agents meet rate limits
An agent makes many calls at the same time. Forty tool calls in one second is normal.
Two practices keep it within the limits without slowing it down. First, retry
429 and 503 after Retry-After, with the same idempotency key.
A retried create then never makes a second sandbox. Second, let the SDK wait
for a free slot when every slot is taken, rather than fail the task
(handle no capacity).
Related
- What is an idempotency key?
- How to retry safely with idempotency keys
- How to handle no capacity
- What is a webhook?
Sources
Checked 25 October 2026.