Siklus hidup task
Pelajari bagaimana sebuah task bergerak dari permintaan hingga hasil, berapa lama biasanya berlangsung, dan berapa lama kode Anda harus menunggunya.
Bagaimana sebuah task berjalan
Permintaan pembuatan mengembalikan ID task tanpa menunggu task tersebut berjalan. Task kemudian berjalan di latar belakang, dan Anda dapat memantaunya dengan salah satu dari tiga cara: melakukan polling pada endpoint GET-nya, membuka endpoint stream-nya, atau menerima webhook.
PENDING. Seorang worker mengambilnya dan statusnya berubah menjadi IN_PROGRESS, di mana sebagian besar waktunya dihabiskan. Task berakhir dengan status SUCCEEDED atau FAILED, dan status akhir tidak akan pernah berubah lagi.PENDINGIN_PROGRESSSUCCEEDEDFAILEDTask mencatat setiap langkah dalam bidang created_at, started_at, dan finished_at.
Tabel berikut menunjukkan apa yang harus dilakukan kode Anda pada setiap status.
| Status | Yang harus dilakukan kode Anda |
|---|---|
PENDING | Tetap menunggu. |
IN_PROGRESS | Lacak progress: persentase pekerjaan yang telah selesai, dari 0 hingga 100. |
SUCCEEDED | Unduh hasilnya. Meshy menyimpan file untuk waktu yang terbatas. Lihat Retensi aset. |
FAILED | Baca task_error, lalu perbaiki input atau buat task baru. Lihat Kesalahan. |
CANCELED | Berhenti menunggu. Task tidak akan menghasilkan hasil apa pun. Hanya task Creative Lab yang menggunakan status ini. |
SUCCEEDED, FAILED, dan CANCELED bersifat final. Setelah task mencapai salah satu dari status tersebut, statusnya tidak akan pernah berubah lagi.
Dari sisi kode Anda, prosesnya terlihat seperti ini:
Permintaan: POST/image-to-3d
Respons: 202{ "result": "<task_id>" }task dibuat
- Ulangi setiap beberapa detik
Permintaan: GET/image-to-3d/<task_id>
Respons: 200{ "status": "IN_PROGRESS","progress": 45 }Retry-After: 5
Permintaan: GET/image-to-3d/<task_id>
Respons: 200{ "status": "SUCCEEDED","model_urls": { "glb": "…" } }
GET nanti dengan ID task yang sama.Waktu pemrosesan
Tabel berikut menunjukkan waktu median pada lalu lintas API produksi di bulan September 2026.
Waktu dihitung dari pembuatan task hingga status akhir. Hampir seluruhnya adalah waktu pemrosesan, karena task biasanya hanya berada dalam status PENDING selama beberapa detik. Ketika antrean sedang sibuk, task bisa menunggu lebih lama sebelum mulai berjalan, dan task pada paket dengan prioritas lebih tinggi biasanya mulai lebih cepat.
Waktu di bawah 2 menit ditampilkan dalam detik (s), dan waktu yang lebih lama ditampilkan dalam menit (min). "Tidak didukung" berarti API tidak menawarkan opsi tersebut dengan model itu.
Ini adalah waktu yang umum terjadi, bukan jaminan waktu penyelesaian. Selama periode sibuk, beberapa task membutuhkan waktu lebih lama namun tetap berhasil. Untuk memeriksa status Meshy, lihat halaman status. Jangan gunakan waktu ini sebagai timeout dalam kode Anda. Untuk nilai timeout, lihat Berapa lama harus menunggu.
Pembuatan 3D
| API | Konfigurasi | meshy-7.1 (latest) | meshy-6 | meshy-6-lite | meshy-t2 |
|---|---|---|---|---|---|
| Teks ke 3D (Preview) | Mesh saja | 75 s | 90 s | 45 s | 10 s |
| Gambar ke 3D | Mesh saja | 75 s | 90 s | 40 s | 4 s |
| Mesh dengan tekstur 2K | 2 min | 3 min | 75 s | 60 s | |
| Mesh dengan tekstur 4K | 2.5 min | 3.5 min | Tidak didukung | 80 s | |
| Mesh dengan tekstur 8K | 3.5 min | 4 min | Tidak didukung | 2.5 min | |
| Multi-Gambar ke 3D | Mesh saja | 65 s | 2 min | 30 s | Tidak didukung |
| Mesh dengan tekstur 2K | 2.5 min | 3.5 min | 85 s | Tidak didukung | |
| Mesh dengan tekstur 4K | 3 min | 4 min | Tidak didukung | Tidak didukung | |
| Mesh dengan tekstur 8K | 3.5 min | 4.5 min | Tidak didukung | Tidak didukung |
Untuk Gambar ke 3D dan Multi-Gambar ke 3D, "Mesh saja" berarti should_texture: false. Opsi dan input berikut mengubah durasinya:
- Peta PBR (
enable_pbr) menambah 30 hingga 60 detik. - Geometri ultra (
geometry_resolution: "2k"atau"4k") menambah hingga 1 menit. - Dengan pengaturan yang sama, gambar input yang lebih kompleks membutuhkan waktu lebih lama.
Pemberian tekstur
| API | Resolusi tekstur | Waktu umum |
|---|---|---|
| Teks ke 3D (Refine) | 2K atau 4K | 80 s |
| 8K | 3.5 min | |
| Retexture | 2K | 55 s |
| 4K | 90 s | |
| 8K | 2.5 min |
Pembuatan gambar
| API | nano-banana | nano-banana-2 | nano-banana-pro | Model GPT Image |
|---|---|---|---|---|
| Teks ke Gambar | 20 s | 15 s | 25 s | 20 hingga 35 s |
| Gambar ke Gambar | 40 s | 20 s | 30 s | 20 hingga 40 s |
Rigging dan Animasi
| API | Konfigurasi | Waktu umum |
|---|---|---|
| Auto-Rigging | Rigging otomatis | 40 s |
| Animasi | Per permintaan | 15 s |
| Teks ke Gerakan | mode prime | 15 s |
mode swift | 10 s |
Pasca-pemrosesan
| API | Waktu umum |
|---|---|
| Remesh | 2 min |
| UV Unwrap | 35 s |
| Konversi | 7 s |
| Ubah ukuran | 15 s |
Pencetakan 3D
| API | Konfigurasi | Waktu umum |
|---|---|---|
| Analisis kemampuan cetak | Hanya pemeriksaan mesh | 1 s |
| Pemeriksaan mesh dan dinding tipis | 10 s | |
| Multi-Color | Per permintaan | 30 s |
| Perbaiki kemampuan cetak | Hanya perbaikan mesh | 10 s |
| Pemeriksaan dinding tipis, dinding dipertahankan | 20 s | |
| Pemeriksaan dinding tipis, dinding ditebalkan | 100 s | |
| Auto Split | Bagian berwarna solid | 70 s |
Bagian bertekstur (keep_texture: true) | 170 s |
Pada v2, Perbaiki kemampuan cetak dan Analisis kemampuan cetak selalu menjalankan pemeriksaan dinding tipis. Pada v1, pemeriksaan ini dijalankan ketika Anda mengirimkan jenis printer atau ukuran cetak.
Berapa lama harus menunggu
Task akan tetap berjalan meskipun kode Anda berhenti menunggu. Jika permintaan Anda mengalami timeout, koneksi Anda terputus, atau stream Anda tertutup, task tidak akan gagal dan tidak akan dibatalkan.
- Tunggu setidaknya 60 menit, dihitung dari
created_attask, sebelum Anda berhenti menunggu. Jika Anda berhenti lebih awal, Anda mungkin melewatkan task yang berhasil kemudian. Hal ini paling sering terjadi selama periode sibuk. - Simpan ID task. Anda dapat mengambil task tersebut kembali kapan saja. Jika statusnya masih belum final setelah 60 menit, periksa lagi nanti. Jika tetap demikian, hubungi dukungan.
- Hanya status
FAILEDyang berarti task gagal. Meshy mengembalikan kredit untuk task yang gagal secara otomatis.
Gunakan nilai-nilai berikut dalam kode Anda:
| Pengaturan | Nilai yang disarankan |
|---|---|
Timeout permintaan pembuatan (POST) | 60 detik |
Timeout permintaan pembuatan (POST) dengan file model_url berukuran lebih dari 100 MB | 120 detik. Meshy mengunduh file tersebut sebelum merespons. |
Timeout permintaan status (GET) | 30 detik |
| Interval polling | Header Retry-After, atau 5 detik jika tidak ada. Polling dihitung ke dalam batas laju Anda. |
Permintaan status gagal (timeout, 429, atau 5xx) | Coba lagi pada polling berikutnya. Ini tidak berarti task gagal. |
| Total waktu tunggu per task | Setidaknya 60 menit dari created_at. Jangan mulai ulang hitungan ini saat Anda menyambungkan kembali stream. |
| Stream | Stream dapat tertutup sebelum task selesai. Jika tertutup tanpa status akhir, sambungkan kembali atau beralih ke polling. |
Untuk banyak task sekaligus, gunakan webhooks daripada melakukan polling pada masing-masing task. Jika event akhir suatu task belum muncul setelah kira-kira dua kali waktu umumnya, ambil task tersebut dari endpoint GET-nya.