Request-rate quotas and credit / spending caps for the Pioneer API, how to handle 429 errors, and how to request higher limits
The Pioneer API enforces two independent things that can stop a request: request-rate limits that cap how many API calls you can make per minute or hour, and credit-based usage limits that cap how much you can spend. Exceeding a request-rate limit returns429 Too Many Requests. Running out of credits or hitting your plan’s overage ceiling returns 402 Payment Required or 403 Forbidden instead — see Credit limits and overage spending cap below.
Request-rate limits
Two independent layers protect the API:- Edge rate limit — always applied to every request at the load balancer, before it reaches the API, regardless of endpoint or authentication. Aggregated by the IP address the edge observes, which is not always your application’s true client IP (for example, requests proxied through a shared egress hop are aggregated together). Limit: 100,000 requests / 60 seconds.
- Per-endpoint limit — most endpoints below enforce their own limit scoped to your billing team (falling back to API key, then user, then client IP for unauthenticated requests). This is the limit that governs a normal, authenticated caller. It replaces the generic per-IP default for that endpoint rather than stacking on top of it — the per-IP default only governs endpoints with no listed override.
For a single API key or team, the per-endpoint limit above is what actually binds. The 100,000 requests / 60 second edge limit is a separate, always-on ceiling shared by all traffic through the same load balancer — it only comes into play when many different callers share the same observed IP and collectively exceed it.
Credit limits and overage spending cap
Inference is billed against a credit balance rather than a request-rate window (1 credit = $0.01). Each plan includes a credit allowance — the Free plan grants a one-time allowance that does not renew, while paid plans renew their included credits every billing month. Once a paid plan’s included credits are used, additional usage draws from overage billing (if enabled) up to that plan’s maximum overage spend per month; on the Free plan, running out simply stops inference until you add credits or upgrade. Exceeding a credit limit does not return429 Too Many Requests. Instead it returns:
402 Payment Requiredwhen your included credits are exhausted and there’s no spendable balance to draw from (code: "out_of_credits").403 Forbiddenwhen your plan’s maximum monthly overage spend has been reached (code: "credit_ceiling_reached").
Handling 429 responses
When you exceed a limit, the API returns429 Too Many Requests and includes a Retry-After header that tells you how many seconds to wait before retrying.
cURL
429 responses with a simple sleep-and-retry loop:
Python
Credit and overage denials (
402/403, see Credit limits and overage spending cap) won’t resolve by waiting — the retry loop above only applies to 429 responses. A 402/403 needs a billing action (add credits, enable auto top-up, or upgrade your plan) before the next request can succeed.