Credits & rate limits
Generation spends credits from your unified wallet. Deducted when a job starts, refunded automatically if it fails.
Cost depends on the engine and options you choose — an image ranges from 15 to 200 credits by model (higher again at 2K/4K output), so model choice, not request count, usually dominates a batch's cost. The exact, authoritative number for every model is the cost (and textureCost) field on GET /v1/models; check your live balance with GET /v1/credits.
What it costs
| Operation | Typical cost |
|---|---|
| Image generation | ≈ 15–200 credits (model-dependent) |
| Text / Image → 3D | ≈ 60–80 credits |
| Remesh | from 10 credits (PB Remesh) |
| Re-texture · Auto-rig | varies by engine — see GET /v1/models |
taskStatus: 3 costs nothing.Rate limits
| Limit | Scope | On exceed |
|---|---|---|
| 240 / min | per client IP | 429 · error.code 10003 |
| 120 / min | per user (generation POSTs) |
Over the limit returns 429 with error.code 10003. Back off with exponential delay (start ~1 s, cap ~30 s) and retry. Need higher limits for production volume? Get in touch.
Concurrent generations
Separate from the per-minute request rate, your account caps how many jobs may be in flight at once — that is, sitting at taskStatus 0 (queued) or 1 (processing). Images and 3D jobs draw on independent budgets, and each budget is shared with the PicoBerry web app signed in to the same account.
| Plan | Images in flight | 3D & post-processing in flight |
|---|---|---|
| Free | 1 | 1 |
| Starter | 3 | 5 |
| Pro | 6 | 20 |
| Max | 15 | 30 |
Submitting past the cap returns 429 with error.code 13002. Nothing is charged and nothing is queued — the request is simply refused, so retry it once a slot frees up.
{ "success": false, "error": { "code": 13002, "message": "Generation queue is full", "httpStatus": 429, "details": { "total": 15, "maxTotal": 15 } } }details.maxTotal is your live ceiling and details.total is what you currently have in flight. Read maxTotal rather than hard-coding a number — it is the whole budget, it rises when you upgrade, and a client that guesses low silently throws away throughput. The usual shape is: keep maxTotal requests running, and start one more each time a job reaches taskStatus 2 or 3.