Task lifecycle
Alamin kung paano umuusad ang isang task mula sa request hanggang sa resulta, kung gaano ito katagal karaniwang tumatagal, at kung gaano katagal dapat maghintay ang iyong code para dito.
Paano tumatakbo ang isang task
Ang isang create request ay nagbabalik ng task ID nang hindi hinihintay na tumakbo ang task. Pagkatapos, tumatakbo ang task sa background, at susubaybayan mo ito sa isa sa tatlong paraan: i-poll ang GET endpoint nito, buksan ang stream endpoint nito, o tumanggap ng webhook.
PENDING. Kukunin ito ng isang worker at lilipat ito sa IN_PROGRESS, kung saan ginugugol nito ang karamihan ng oras nito. Nagtatapos ito sa SUCCEEDED o FAILED, at ang final status ay hindi na nagbabago.PENDINGIN_PROGRESSSUCCEEDEDFAILEDItinatala ng task ang bawat hakbang sa mga field nitong created_at, started_at, at finished_at.
Ipinapakita ng sumusunod na talahanayan kung ano ang dapat gawin ng iyong code sa bawat status.
| Status | Ano ang dapat gawin ng iyong code |
|---|---|
PENDING | Magpatuloy sa paghihintay. |
IN_PROGRESS | Subaybayan ang progress: ang porsyento ng gawaing nagawa na, mula 0 hanggang 100. |
SUCCEEDED | I-download ang resulta. Pinapanatili ni Meshy ang mga file nang may limitadong oras lamang. Tingnan ang Asset retention. |
FAILED | Basahin ang task_error, pagkatapos ay ayusin ang input o gumawa ng bagong task. Tingnan ang Errors. |
CANCELED | Huminto sa paghihintay. Hindi magbubunga ng resulta ang task. Mga task lamang sa Creative Lab ang gumagamit ng status na ito. |
Ang SUCCEEDED, FAILED, at CANCELED ay final. Kapag naabot ng isang task ang isa sa mga ito, hindi na muling magbabago ang status nito.
Mula sa iyong code, ganito ang hitsura nito:
Request: POST/image-to-3d
Response: 202{ "result": "<task_id>" }nagawa ang task
- Ulitin tuwing ilang segundo
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 ito mamaya gamit ang parehong task ID.Mga oras ng pagproseso
Ipinapakita ng mga sumusunod na talahanayan ang median na oras batay sa production API traffic noong Setyembre 2026.
Ang oras ay binibilang mula sa paggawa ng task hanggang sa final status. Halos lahat nito ay pagproseso, dahil karaniwang nananatili lamang ang isang task sa PENDING nang ilang segundo. Kapag abala ang queue, maaaring mas matagal maghintay ang mga task bago magsimula, at ang mga task sa mga planong may mas mataas na priority ay karaniwang mas maagang nagsisimula.
Ang mga oras na mas mababa sa 2 minuto ay nasa segundo (s), at ang mas mahahabang oras ay nasa minuto (min). Ang ibig sabihin ng "Not supported" ay hindi inaalok ng API ang opsyong iyon sa modelong iyon.
Ito ay mga karaniwang oras, hindi garantisadong oras ng pagkumpleto. Sa mga abalang panahon, mas matagal tumatagal ang ilang task ngunit nagtatagumpay pa rin. Upang tingnan ang status ni Meshy, tingnan ang status page. Huwag gamitin ang mga oras na ito bilang timeout sa iyong code. Para sa mga timeout value, tingnan ang Gaano katagal maghihintay.
3D generation
| API | Configuration | meshy-7.1 (latest) | meshy-6 | meshy-6-lite | meshy-t2 |
|---|---|---|---|---|---|
| Text to 3D (Preview) | Mesh lamang | 75 s | 90 s | 45 s | 10 s |
| Image to 3D | Mesh lamang | 75 s | 90 s | 40 s | 4 s |
| Mesh na may 2K textures | 2 min | 3 min | 75 s | 60 s | |
| Mesh na may 4K textures | 2.5 min | 3.5 min | Not supported | 80 s | |
| Mesh na may 8K textures | 3.5 min | 4 min | Not supported | 2.5 min | |
| Multi-Image to 3D | Mesh lamang | 65 s | 2 min | 30 s | Not supported |
| Mesh na may 2K textures | 2.5 min | 3.5 min | 85 s | Not supported | |
| Mesh na may 4K textures | 3 min | 4 min | Not supported | Not supported | |
| Mesh na may 8K textures | 3.5 min | 4.5 min | Not supported | Not supported |
Para sa Image to 3D at Multi-Image to 3D, ang ibig sabihin ng "Mesh lamang" ay should_texture: false. Ang mga opsyon at input na ito ay nagbabago sa oras:
- Ang PBR maps (
enable_pbr) ay nagdaragdag ng 30 hanggang 60 segundo. - Ang Ultra geometry (
geometry_resolution: "2k"o"4k") ay nagdaragdag ng hanggang 1 minuto. - Sa parehong mga setting, mas matagal tumatagal ang mas kumplikadong input na mga larawan.
Texturing
| API | Texture resolution | Karaniwang oras |
|---|---|---|
| Text to 3D (Refine) | 2K o 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 | Mga modelo ng GPT Image |
|---|---|---|---|---|
| Text to Image | 20 s | 15 s | 25 s | 20 hanggang 35 s |
| Image to Image | 40 s | 20 s | 30 s | 20 hanggang 40 s |
Rigging at Animation
| API | Configuration | Karaniwang oras |
|---|---|---|
| Auto-Rigging | Awtomatikong rigging | 40 s |
| Animation | Bawat request | 15 s |
| Text to Motion | prime mode | 15 s |
swift mode | 10 s |
Post-processing
3D printing
| API | Configuration | Karaniwang oras |
|---|---|---|
| Analyze Printability | Mga pagsusuri lamang ng mesh | 1 s |
| Mga pagsusuri sa mesh at thin-wall | 10 s | |
| Multi-Color | Bawat request | 30 s |
| Repair Printability | Pagsasaayos lamang ng mesh | 10 s |
| Pagsusuri sa thin-wall, napanatiling mga pader | 20 s | |
| Pagsusuri sa thin-wall, pinalapot na mga pader | 100 s | |
| Auto Split | Bawat request | 70 s |
Sa v2, lagi nang pinapatakbo ng Repair Printability at Analyze Printability ang thin-wall check. Sa v1, pinapatakbo nila ito kapag nagpadala ka ng printer type o print size.
Gaano katagal maghihintay
Patuloy na tatakbo ang task kahit na huminto na sa paghihintay ang iyong code. Kung mag-timeout ang iyong request, mahiwalay ang iyong koneksyon, o magsara ang iyong stream, hindi mabibigo ang task at hindi ito nakakansela.
- Maghintay nang hindi bababa sa 60 minuto, binibilang mula sa
created_atng task, bago ka huminto sa paghihintay. Kung mas maagang huminto, maaari mong mapalampas ang isang task na magtatagumpay sa huli. Kadalasang nangyayari ito sa mga abalang panahon. - Panatilihin ang task ID. Maaari mong kunin muli ang task anumang oras. Kung hindi pa rin ito final matapos ang 60 minuto, tingnan itong muli sa ibang pagkakataon. Kung patuloy itong ganoon, makipag-ugnayan sa support.
FAILEDlamang ang nangangahulugang nabigo ang task. Awtomatikong ire-refund ni Meshy ang mga nabigong task.
Gamitin ang mga value na ito sa iyong code:
| Setting | Inirekomendang value |
|---|---|
Timeout ng create request (POST) | 60 segundo |
Timeout ng create request (POST) na may model_url file na higit sa 100 MB | 120 segundo. Dina-download muna ni Meshy ang file bago ito tumugon. |
Timeout ng status request (GET) | 30 segundo |
| Poll interval | Ang Retry-After header, o 5 segundo kung wala ito. Nabibilang ang mga poll sa iyong rate limit. |
Nabigong status request (timeout, 429, o 5xx) | Subukang muli sa susunod na poll. Hindi ito nangangahulugang nabigo ang task. |
| Kabuuang paghihintay bawat task | Hindi bababa sa 60 minuto mula sa created_at. Huwag i-restart ang bilang na ito kapag muli kang kumonekta sa isang stream. |
| Stream | Maaaring magsara ang isang stream bago matapos ang task. Kung magsara ito nang walang final status, kumonekta muli o lumipat sa polling. |
Para sa maraming task nang sabay-sabay, gumamit ng webhooks sa halip na i-poll ang bawat isa. Kung hindi pa dumating ang final event ng isang task matapos ang humigit-kumulang dalawang beses ng karaniwang oras nito, kunin ang task mula sa GET endpoint nito.