Limits & plans

The four axes

• Rate (rpm) — how many requests per minute a key accepts.
• Concurrency — how many requests may run at once; a stream holds its slot until it ends.
• Daily quota — requests available per day on the plan, on a rolling 24-hour reset.
• Lifetime image quota — how many images a key may ever generate.

The numbers

What happens when you hit one

The request is refused with 429 before routing, so a rejection costs no quota. The body carries the kind and, when the gateway can compute it, retry_after_sec.

• rate_limited — you hit the rate or concurrency ceiling. Wait, then retry.
• quota_exceeded — the daily or lifetime quota is spent. Retrying will not help: wait for the reset or change plan.

{
  "success": false,
  "code": 429,
  "data": null,
  "error": {
    "kind": "rate_limited",
    "message": "rate limit exceeded (rpm)",
    "retry_after_sec": 8
  }
}

Where to watch consumption

The Statistics page in the cabinet shows requests, images and errors for the month and all time; Logs shows each call with its latency and attempt count. Both break down per key.

Designing within the limits

• Queue on your side: Free allows exactly one in-flight request, so parallel calls will be refused.
• Exponential backoff with jitter prevents synchronised spikes after a 429.
• Use separate keys per environment so debugging never eats production quota.
• For images, count pictures rather than calls: n > 1 burns the lifetime quota faster.