Skip to main content
Every sandbox and instance runs on a tier that sets its CPU and memory capacity. Accounts also have rate limits that protect the platform and your workloads.

​
Compute tiers

If a requested tier has no capacity, allocation returns 503 rather than substituting another tier.
Tier capacity is hard-limited. When a tier is full, the platform returns 503 Service Unavailable — there is no automatic fallback to a different tier. This means a burst of sandbox or instance creation requests can fail simultaneously if your organization’s concurrent allocation exceeds available capacity. Monitor the ConcurrentSandboxes quota to stay ahead of this.

​
Quota keys

When you receive quota_exceeded (HTTP 429), the response includes X-RateLimit-Limit and X-RateLimit-Reset headers. Unlike rate limits which auto-resolve with time, quota limits require you to release resources or request a quota increase via Support.

​
Rate limits

API requests are rate-limited per organization. When you exceed a limit, the API responds with 429 Too Many Requests and the SDKs retry automatically with exponential backoff. List endpoints are paginated: page starts at 1, page_size ranges 1-100 (default 20).
Current pricing is shown in your Console and on the pricing page. Rates are not duplicated here to keep the docs accurate.

​
Common mistakes

  • Treating 429 as a hard failure. It is a signal to back off and retry, not an error to surface to users.
  • Over-provisioning the tier. Start at standard and move up only when metrics justify it.

​
Best practices

  • Right-size tiers using metrics.
  • Handle 429 with backoff (the SDKs do this automatically).
  • Check the Console for current limits before high-volume runs.

Usage

Track consumption.

Scaling

Adjust capacity.

Error Handling (Python)

How the SDKs handle 429s.

Troubleshooting

Resolve limit-related issues.