Rate limit

Providers set limits for plain reasons. Capacity is finite and shared, so one runaway script must not slow everybody else. Limits also contain cost and stop abuse such as a stolen key being used to flood a service. Without them, a bug in a loop could send thousands of calls in a minute. Think of a bakery that serves a queue: letting one customer buy every loaf in the first minute is unfair to the rest, so the baker caps each person, and a good limit is just a fair share written as a number.

Limits come in several shapes. A short limit per minute absorbs bursts. A longer one, per day, bounds total use, either as a fixed window that resets at a set hour or as a rolling window that always looks back over the last stretch of time. Some services count requests, others count tokens, and some also cap how many calls may run at the same moment. Limits often depend on the plan, so a higher tier gets a higher ceiling.

Handling a limit well is a small piece of craft. Read the Retry-After header when it is present and wait that long. Otherwise retry with exponential backoff and a little random jitter, and never in a tight loop. Reduce the number of calls by caching answers and batching work, and spread the load over time. Remember that a rate limit is not a spending limit: running out of balance is a separate error, and the fix is different. Libraries often wrap this logic for you, retrying politely and pausing between attempts; when you write your own client, log each 429 with its timestamp so that you can see whether bursts or sustained load cause it.

The NeverNo API documentation sets the rule. Each account has a number of API requests per rolling 24 hours, depending on its plan. Past it, calls receive a 429 with the code rate_limited until the window moves. A short limit per minute applies as well, and then the 429 comes with a Retry-After header. Every call counts as one request, whatever the number of tokens or images, while the token-counting endpoint does not count. Because the window is rolling, capacity returns gradually as old calls age out, instead of all at once at midnight.

The exact numbers per plan are in the table of the API documentation, and we do not repeat them here so that this page never goes out of date. Running out of credits is a different case: the API answers 402 with insufficient_credits. The Dev subscription uses the request limit of Pro+. Because the documentation is the single source of the numbers, a script should read the ceiling from there rather than hard-code a guess, and treat a sudden rise in 429 errors as a signal to slow down and queue its work.