> ## Documentation Index
> Fetch the complete documentation index at: https://docs.querying.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Rate limits and capacity

> The contract is identical across engines. The throughput is not.

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

<Warning>
  These are operational figures that move as pools are provisioned. Treat them as an
  upper bound to design against, not a guarantee.
</Warning>

| Engine                                                        | Sustainable rate                            | Why                                                                       |
| ------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------------- |
| `GEMINI`                                                      | **\~14 QPS** — 1M tasks/day proven          | Direct HTTP scraping, no account pool                                     |
| `PERPLEXITY`                                                  | **≤2 QPS**                                  | Bound by IP pool size; failures climb sharply above this                  |
| `CHATGPT`                                                     | High in anonymous mode, low in account mode | Anonymous is browserless and IP-bound; account mode is capped per account |
| `GOOGLE` `AIMODE`                                             | Moderate                                    | Browser-driven                                                            |
| `COPILOT` `CLAUDE` `GROK` `NAVER_AI_MODE` `DEEPSEEK` `AMAZON` | **Low**                                     | Browser-driven or account-rate-bound. Not intended for bulk volume.       |

`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`.

```json theme={null}
{ "taskType": "CLAUDE", "payload": { "prompt": "...", "country": "GB" } }
```

Check what a region can currently serve before a large submission:

```bash theme={null}
curl "$BASE/capacity" -H "Authorization: Bearer $API_KEY"
```

See [`GET /capacity`](/api-reference/capacity).

## Designing around the limits

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Watch the queue">
    `GET /stats` exposes queue depth and pool health. If depth grows monotonically, you are
    over the sustainable rate.
  </Step>
</Steps>