API rate limits

ModelsLab runs a shared GPU fleet, so every account has a cap on how many generations it can start in a given period. The caps exist so one very heavy account cannot absorb the whole fleet and leave everyone else queueing. There are four of them, and they are independent — this page shows all four, and your live usage against each.

1. Your plan’s request window

The main limit. Every plan gets an hourly allowance, enforced in 30 minutes slices so a burst cannot spend the whole hour in the first few minutes. Video and 3D draw on a second, smaller allowance of their own, because a single video costs 10–100× the GPU time of an image.

Requests to a dedicated Enterprise endpoint run on your own GPUs, not the shared fleet, and are not counted here.

2. Generations running at the same time

Separate from the window above, and the one most often mistaken for it. It caps how many of your generations may be in progress at once, not how many you may start. It is not a budget that refills on a clock — a slot frees the moment a generation finishes, so this limit clears itself. The number for each plan is in the last column of the table above.

3. Per-model caps

A few model pools are small enough that one account running flat out fills the queue for everybody else on them, while staying comfortably inside its plan window. Those pools carry their own cap, applied on top of your plan window, on every plan.

4. What does and does not count

Only requests that actually start work on a GPU count. In particular, polling a generation you already started is free — a single generation is polled up to 25 times, and counting those would exhaust an allowance after a dozen real generations.

Reading your limits from the API

Every API response carries your current state, so a client can slow down before it is refused rather than after.

The legacy X-RateLimit-Limit and X-RateLimit-Remaining headers are still sent alongside these.

What a refusal looks like

The generation API reports every failure as HTTP 200 with an error body, so check status and code rather than the HTTP status:

{
  "status": "error",
  "code": "rate_limited",
  "message": "Rate limit exceeded: Try again in 12 minute(s), ..."
}

Wait for Retry-After and retry. Retrying immediately does not help — a refused request still counts, so a tight retry loop keeps the window full and extends the lockout.

Other limits

These apply to account and billing endpoints rather than to generation, and are unrelated to the caps above.

Need more

A higher plan raises the window. Compare plans. If your workload does not fit any of them, an Enterprise deployment runs on GPUs reserved for you, with no shared-fleet cap at all.