Task lifecycle

Learn 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.

A create request starts a task in 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.

Create request

PENDING

Waiting in the queue

IN_PROGRESS

Generating the result

SUCCEEDED

Download the result

FAILED

Credits refunded

The task records each step in its created_at, started_at, and finished_at fields.

The following table shows what your code should do at each status.

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. Meshy keeps the files 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. After 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
1. Request: GET/image-to-3d/<task_id>
2. Response: 200{ "status": "IN_PROGRESS","progress": 45 }Retry-After: 5
Request: GET/image-to-3d/<task_id>
Response: 200{ "status": "SUCCEEDED","model_urls": { "glb": "…" } }

If your app stops waiting, the task keeps running. GET it later with the same task ID.

Processing times

The following tables show 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), and longer times are in minutes (min). Not supported means the API doesn't offer that option with that model.

These are typical times, not guaranteed completion times. During busy periods, some tasks take longer and still succeed. To check Meshy's status, see the status page. 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	Not supported	80 s
	Mesh with 8K textures	3.5 min	4 min	Not supported	2.5 min
Multi-Image to 3D	Mesh only	65 s	2 min	30 s	Not supported
	Mesh with 2K textures	2.5 min	3.5 min	85 s	Not supported
	Mesh with 4K textures	3 min	4 min	Not supported	Not supported
	Mesh with 8K textures	3.5 min	4.5 min	Not supported	Not supported

For Image to 3D and Multi-Image to 3D, "Mesh only" means should_texture: false. These options and inputs change the time:

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

API	Typical time
Remesh	2 min
UV Unwrap	35 s
Convert	7 s
Resize	15 s

3D printing

API	Configuration	Typical time
Analyze Printability	Mesh checks only	1 s
	Mesh and thin-wall checks	10 s
Multi-Color	Per request	30 s
Repair Printability	Mesh repair only	10 s
	Thin-wall check, walls kept	20 s
	Thin-wall check, walls thickened	100 s
Auto Split	Per request	70 s

On v2, Repair Printability and Analyze Printability always run the thin-wall check. On v1, they run it when you send a printer type or a print size.

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 doesn't fail and isn't canceled.

Wait at least 60 minutes, counted from the task's created_at, before you stop waiting. If you stop earlier, you might miss a task that succeeds later. This happens mostly during busy periods.
Keep the task ID. You can get the task again at any time. If it still isn't final after 60 minutes, check it again later. If it stays that way, contact support.
Only FAILED means the task failed. Meshy refunds failed tasks automatically.

Use these values in your code:

Setting	Recommended value
Create request (`POST`) timeout	60 seconds
Create request (`POST`) timeout with a `model_url` file over 100 MB	120 seconds. Meshy downloads the file before it responds.
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, get the task from its GET endpoint.