Task Lifecycle
How a task moves from request to result, how long it usually takes, and how long your code should wait for it.
How a Task Runs
A create request returns a task ID without waiting for the task to run. The task then runs in the background, and you follow it in one of three ways: poll its GET endpoint, open its stream endpoint, or receive a webhook.
PENDING. A worker picks it up and it moves to IN_PROGRESS, where it spends most of its time. It ends in SUCCEEDED or FAILED, and a final status never changes.PENDINGIN_PROGRESSSUCCEEDEDFAILEDThe task records each step in its created_at, started_at and finished_at fields.
| Status | What your code should do |
|---|---|
PENDING | Keep waiting. |
IN_PROGRESS | Track progress: the percentage of the work that's done, from 0 to 100. |
SUCCEEDED | Download the result. Files are kept for a limited time (see Asset Retention). |
FAILED | Read task_error, then fix the input or create a new task (see Errors). |
CANCELED | Stop waiting. The task won't produce a result. Only Creative Lab tasks use this status. |
SUCCEEDED, FAILED and CANCELED are final: once a task reaches one of them, its status never changes again.
From your code, it looks like this:
Request: POST/image-to-3d
Response: 202{ "result": "<task_id>" }task created
- Repeat every few seconds
Request: GET/image-to-3d/<task_id>
Response: 200{ "status": "IN_PROGRESS","progress": 45 }Retry-After: 5
Request: GET/image-to-3d/<task_id>
Response: 200{ "status": "SUCCEEDED","model_urls": { "glb": "…" } }
GET it later with the same task ID.Processing Times
Median times on production API traffic in September 2026.
A time runs from task creation to the final status. Nearly all of it is processing, because a task usually stays in PENDING for only a few seconds. When the queue is busy, tasks can wait longer before they start, and tasks on plans with a higher priority usually start sooner.
Times under 2 minutes are in seconds (s), longer times in minutes (min). A dash (—) means the option is not supported.
These are typical times, not guaranteed completion times. During busy periods, some tasks take longer and still succeed. You can check Meshy's status at status.meshy.ai. Don't use these times as timeouts in your code. For timeout values, see How Long to Wait.
3D Generation
| API | Configuration | meshy-7.1 (latest) | meshy-6 | meshy-6-lite | meshy-t2 |
|---|---|---|---|---|---|
| Text to 3D (Preview) | Mesh only | 75 s | 90 s | 45 s | 10 s |
| Image to 3D | Mesh only | 75 s | 90 s | 40 s | 4 s |
| Mesh with 2K textures | 2 min | 3 min | 75 s | 60 s | |
| Mesh with 4K textures | 2.5 min | 3.5 min | — | 80 s | |
| Mesh with 8K textures | 3.5 min | 4 min | — | 2.5 min | |
| Multi-Image to 3D | Mesh only | 65 s | 2 min | 30 s | — |
| Mesh with 2K textures | 2.5 min | 3.5 min | 85 s | — | |
| Mesh with 4K textures | 3 min | 4 min | — | — | |
| Mesh with 8K textures | 3.5 min | 4.5 min | — | — |
For Image to 3D and Multi-Image to 3D, "Mesh only" means should_texture: false.
- PBR maps (
enable_pbr) add 30 to 60 seconds. - Ultra geometry (
geometry_resolution: "2k"or"4k") adds up to 1 minute. - With the same settings, more complex input images take longer.
Texturing
| API | Texture resolution | Typical time |
|---|---|---|
| Text to 3D (Refine) | 2K or 4K | 80 s |
| 8K | 3.5 min | |
| Retexture | 2K | 55 s |
| 4K | 90 s | |
| 8K | 2.5 min |
Image Generation
| API | nano-banana | nano-banana-2 | nano-banana-pro | GPT Image models |
|---|---|---|---|---|
| Text to Image | 20 s | 15 s | 25 s | 20 to 35 s |
| Image to Image | 40 s | 20 s | 30 s | 20 to 40 s |
Rigging and Animation
| API | Configuration | Typical time |
|---|---|---|
| Auto-Rigging | Automatic rigging | 40 s |
| Animation | Per request | 15 s |
| Text to Motion | prime mode | 15 s |
swift mode | 10 s |
Post-processing
3D Printing
| API | Typical time |
|---|---|
| Analyze Printability | 1 s |
| Multi-Color | 30 s |
| Repair Printability | 10 s |
| Auto Split | 70 s |
How Long to Wait
The task keeps running even if your code stops waiting. If your request times out, your connection drops or your stream closes, the task does not fail and is not canceled.
- Wait at least 60 minutes, counted from the task's
created_at, before you stop waiting. If you stop earlier, you may miss a task that succeeds later. This happens mostly during busy periods. - Keep the task ID. You can fetch the task again at any time. If it still isn't final after 60 minutes, check it again later, and contact support if it stays that way.
- Only
FAILEDmeans the task failed. Failed tasks are refunded automatically.
| Setting | Recommended value |
|---|---|
Create request (POST) timeout | 60 seconds |
Status request (GET) timeout | 30 seconds |
| Poll interval | The Retry-After header, or 5 seconds if it's missing. Polls count toward your rate limit. |
Failed status request (timeout, 429 or 5xx) | Try again at the next poll. It doesn't mean the task failed. |
| Overall wait per task | At least 60 minutes from created_at. Don't restart this count when you reconnect a stream. |
| Stream | A stream can close before the task finishes. If it closes without a final status, reconnect or switch to polling. |
For many tasks at once, use webhooks instead of polling each one. If a task's final event hasn't arrived after about twice its typical time, check the task with its GET endpoint.