Uppgiftens livscykel
Lär dig hur en uppgift går från förfrågan till resultat, hur lång tid det vanligtvis tar, och hur länge din kod bör vänta på den.
Hur en uppgift körs
En create-förfrågan returnerar ett uppgifts-ID utan att vänta på att uppgiften ska köras. Uppgiften körs sedan i bakgrunden, och du följer den på ett av tre sätt: pollar dess GET-endpoint, öppnar dess stream-endpoint, eller tar emot en webhook.
PENDING. En worker plockar upp den och den övergår till IN_PROGRESS, där den tillbringar merparten av tiden. Den slutar i SUCCEEDED eller FAILED, och en slutgiltig status ändras aldrig.PENDINGIN_PROGRESSSUCCEEDEDFAILEDUppgiften registrerar varje steg i sina fält created_at, started_at och finished_at.
Följande tabell visar vad din kod bör göra vid varje status.
| Status | Vad din kod bör göra |
|---|---|
PENDING | Fortsätt vänta. |
IN_PROGRESS | Spåra progress: hur många procent av arbetet som är klart, från 0 till 100. |
SUCCEEDED | Ladda ner resultatet. Meshy sparar filerna under en begränsad tid. Se Tillgångslagring. |
FAILED | Läs task_error, och åtgärda sedan indata eller skapa en ny uppgift. Se Fel. |
CANCELED | Sluta vänta. Uppgiften kommer inte att ge något resultat. Endast Creative Lab-uppgifter använder denna status. |
SUCCEEDED, FAILED och CANCELED är slutgiltiga. När en uppgift når någon av dessa statusar ändras den aldrig igen.
Från din kod ser det ut så här:
Förfrågan: POST/image-to-3d
Svar: 202{ "result": "<task_id>" }uppgift skapad
- Upprepa var några sekunder
Förfrågan: GET/image-to-3d/<task_id>
Svar: 200{ "status": "IN_PROGRESS","progress": 45 }Retry-After: 5
Förfrågan: GET/image-to-3d/<task_id>
Svar: 200{ "status": "SUCCEEDED","model_urls": { "glb": "…" } }
GET med samma uppgifts-ID.Bearbetningstider
Följande tabeller visar mediantider för produktionstrafiken i Meshy API i september 2026.
En tid räknas från att uppgiften skapas till den slutgiltiga statusen. Nästan hela tiden är bearbetning, eftersom en uppgift vanligtvis bara stannar i PENDING i några sekunder. När kön är belastad kan uppgifter behöva vänta längre innan de startar, och uppgifter på planer med högre prioritet startar vanligtvis snabbare.
Tider under 2 minuter anges i sekunder (s), och längre tider anges i minuter (min). Stöds ej betyder att API:et inte erbjuder det alternativet med den modellen.
Dessa är typiska tider, inte garanterade sluttider. Under belastade perioder kan vissa uppgifter ta längre tid men ändå lyckas. För att kontrollera Meshys status, se statussidan. Använd inte dessa tider som timeout-värden i din kod. För timeout-värden, se Hur länge man ska vänta.
3D-generering
| API | Konfiguration | meshy-7.1 (latest) | meshy-6 | meshy-6-lite | meshy-t2 |
|---|---|---|---|---|---|
| Text till 3D (Preview) | Endast nät | 75 s | 90 s | 45 s | 10 s |
| Bild till 3D | Endast nät | 75 s | 90 s | 40 s | 4 s |
| Nät med 2K-texturer | 2 min | 3 min | 75 s | 60 s | |
| Nät med 4K-texturer | 2,5 min | 3,5 min | Stöds ej | 80 s | |
| Nät med 8K-texturer | 3,5 min | 4 min | Stöds ej | 2,5 min | |
| Flera bilder till 3D | Endast nät | 65 s | 2 min | 30 s | Stöds ej |
| Nät med 2K-texturer | 2,5 min | 3,5 min | 85 s | Stöds ej | |
| Nät med 4K-texturer | 3 min | 4 min | Stöds ej | Stöds ej | |
| Nät med 8K-texturer | 3,5 min | 4,5 min | Stöds ej | Stöds ej |
För Bild till 3D och Flera bilder till 3D betyder "Endast nät" should_texture: false. Dessa alternativ och indata ändrar tiden:
- PBR-mappar (
enable_pbr) lägger till 30 till 60 sekunder. - Ultra-geometri (
geometry_resolution: "2k"eller"4k") lägger till upp till 1 minut. - Med samma inställningar tar mer komplexa indatabilder längre tid.
Texturering
| API | Texturupplösning | Typisk tid |
|---|---|---|
| Text till 3D (Refine) | 2K eller 4K | 80 s |
| 8K | 3,5 min | |
| Omtexturering | 2K | 55 s |
| 4K | 90 s | |
| 8K | 2,5 min |
Bildgenerering
| API | nano-banana | nano-banana-2 | nano-banana-pro | GPT Image-modeller |
|---|---|---|---|---|
| Text till bild | 20 s | 15 s | 25 s | 20 till 35 s |
| Bild till bild | 40 s | 20 s | 30 s | 20 till 40 s |
Rigging och Animation
| API | Konfiguration | Typisk tid |
|---|---|---|
| Auto-Rigging | Automatisk rigging | 40 s |
| Animation | Per förfrågan | 15 s |
| Text till rörelse | prime-mode | 15 s |
swift-mode | 10 s |
Efterbearbetning
| API | Typisk tid |
|---|---|
| Remesh | 2 min |
| UV-uppveckling | 35 s |
| Konvertera | 7 s |
| Ändra storlek | 15 s |
3D-utskrift
| API | Konfiguration | Typisk tid |
|---|---|---|
| Analysera utskrivbarhet | Endast nätkontroller | 1 s |
| Nät- och tunnväggskontroller | 10 s | |
| Multi-Color | Per förfrågan | 30 s |
| Reparera utskrivbarhet | Endast nätreparation | 10 s |
| Tunnväggskontroll, väggar behålls | 20 s | |
| Tunnväggskontroll, väggar förtjockas | 100 s | |
| Auto Split | Per förfrågan | 70 s |
I v2 kör Reparera utskrivbarhet och Analysera utskrivbarhet alltid tunnväggskontrollen. I v1 körs den när du skickar en skrivartyp eller en utskriftsstorlek.
Hur länge man ska vänta
Uppgiften fortsätter att köras även om din kod slutar vänta. Om din förfrågan får timeout, din anslutning bryts, eller din stream stängs, misslyckas inte uppgiften och avbryts inte.
- Vänta minst 60 minuter, räknat från uppgiftens
created_at, innan du slutar vänta. Om du slutar tidigare kan du missa en uppgift som lyckas senare. Detta händer mestadels under belastade perioder. - Behåll uppgifts-ID:t. Du kan hämta uppgiften igen när som helst. Om den fortfarande inte är slutgiltig efter 60 minuter, kontrollera den igen senare. Om den förblir så, kontakta support.
- Endast
FAILEDinnebär att uppgiften misslyckades. Meshy återbetalar misslyckade uppgifter automatiskt.
Använd dessa värden i din kod:
| Inställning | Rekommenderat värde |
|---|---|
Timeout för create-förfrågan (POST) | 60 sekunder |
Timeout för create-förfrågan (POST) med en model_url-fil över 100 MB | 120 sekunder. Meshy laddar ner filen innan den svarar. |
Timeout för statusförfrågan (GET) | 30 sekunder |
| Pollingintervall | Headern Retry-After, eller 5 sekunder om den saknas. Pollningar räknas mot din hastighetsgräns. |
Misslyckad statusförfrågan (timeout, 429 eller 5xx) | Försök igen vid nästa poll. Det betyder inte att uppgiften misslyckades. |
| Total väntetid per uppgift | Minst 60 minuter från created_at. Starta inte om denna räkning när du återansluter en stream. |
| Stream | En stream kan stängas innan uppgiften är klar. Om den stängs utan en slutgiltig status, anslut igen eller växla till polling. |
För många uppgifter samtidigt, använd webhooks istället för att polla varje enskild. Om en uppgifts slutgiltiga händelse inte har kommit efter ungefär dubbla dess typiska tid, hämta uppgiften från dess GET-endpoint.