Skip to main content
There is no per-key rate limiter that will 429 you. What limits you instead is the capacity of the engine’s backing pool — accounts, IPs, or browsers. Push an engine past what its pool sustains and tasks do not get rejected at submit time; they queue, retry, and eventually fail. This is the single respect in which this API is not a drop-in for Cloro. Everything else — paths, schemas, statuses, webhooks — is identical.

​
Sustainable submission rates

These are operational figures that move as pools are provisioned. Treat them as an upper bound to design against, not a guarantee.
DEEPSEEK in particular is bound by a per-account rate wall rather than by how many workers you throw at it — roughly 2 QPS sustained regardless of scaling.

​
Region-gated engines

CHATGPT and CLAUDE draw on accounts provisioned per region. A task for a region with no serveable accounts is rejected at submit time with REGION_UNAVAILABLE rather than being queued to fail later. Set the region with payload.country (ISO 3166-1 alpha-2). It defaults to US.
Check what a region can currently serve before a large submission:
See GET /capacity.

​
Designing around the limits

1

Batch, don't spray

One POST /v1/async/task/batch with 500 items costs one round trip and one region check per distinct region. Five hundred single submissions cost five hundred of each.
2

Use priority to order, not to reserve

A high priority moves a task to the front of the queue. It does not create an account or an IP that the pool does not have.
3

Treat FAILED as a capacity signal

A rising FAILED rate on a browser-driven engine usually means you are submitting faster than the pool drains, not that the engine broke.
4

Watch the queue

GET /stats exposes queue depth and pool health. If depth grows monotonically, you are over the sustainable rate.