Failed Runs, Queue Limits and Credits: How AI 3D Generators Bill by Plan

How billing and queues differ by plan

Concurrency and retries are plan features, which means the same tool behaves differently on Free and on a paid tier.

• Meshy lists concurrent tasks of 1 (Free), 10 (Pro), 30 (Premium) and 100 (Ultra), with “low queue priority” on Free and no free retries there. Paid plans list retries per task of 4 (Pro), 12 (Premium) and 40 (Ultra). Its pricing docs say it does not charge for failed generations and refunds canceled tasks (pricing page and web app docs, November 2026).
• Hunyuan3D (hosted by Tencent Cloud) has been listed with default concurrency of 3 for Professional and 1 for Express; the billing page blocked our last automated check (November 2026), so confirm it there.
• Sloyd lists parallel generations of 2 on Plus and 5 on Pro, with a priority queue on Pro, and states that payments are generally non-refundable, with mistaken-charge requests accepted within 14 days.
• Tripo’s Rate Limits docs give default concurrency of 10 for H-series generation, 5 for P-series, 1 for image generation, 10 for animation, 5 for model processing and 10 for mesh operations; its pricing page was unreachable for us, and secondary sources list 10 concurrent tasks on Pro, which we have not confirmed.
• Rodin’s pricing page has been read as listing API rate limits of 120 requests per minute on the first three tiers and 240 on higher, but those figures were not in the page source at our last check (November 2026), so confirm them; we saw no web-app queue documentation there.

What Meshy’s API says a task status and a refund mean

Meshy’s Text to 3D API page (read 2026-11-08) gives a precise status model you can log against: status is PENDING, IN_PROGRESS, SUCCEEDED, FAILED or CANCELED; progress is an integer that stays 0 until the task starts and reaches 100 on success; task_error is null unless the status is FAILED. For a FAILED task consumed_credits is 0 “because Meshy refunds the credits”. Deleting a PENDING task refunds its credits; deleting an IN_PROGRESS task returns 409 Conflict, the task keeps running and the error message says credits for a task the worker has already started are not refundable; deleting a finished task does not refund. The page lists no cancel endpoint (CANCELED appears only as a status), and the web-app docs say only that canceled tasks are refunded, so these API rules may not describe the web app. “Failed” in the API means the vendor’s own failure, not a mesh you find unusable. Moderation is separate: the parameter description says flagged requests return 400 and no task is created, while the page’s failure list gives 403 for moderation blocks, so log the code you actually receive. Tripo’s docs define task states (queued, running, success, failed, cancelled) and say frozen credits return on failure or cancellation (/en/docs/task-query, /en/docs/billing).

Whether a “failed” run in practice includes a moderation rejection, a timeout or a bad mesh is not defined in the pages we read. That definition is yours to set below.

What speed claims exist

Meshy’s own comparison post (posted 7 September 2026, updated 27 October 2026; it discloses that Meshy is one of the tools compared) says Tripo is “fastest for pure generation”, cites Hi3D’s own documentation for a usable model in about two minutes, and gives Meshy’s image-to-3D as roughly one minute. Those are quoted figures, not logs, and the post adds that generation time matters less than total time to a usable asset. It lists cost per usable asset at API volume, team workflows and output consistency across repeated runs as not measured. Hosted-queue speeds also change by time of day and plan, so a figure from one source cannot be carried to your account.

Logging method

1. Run the prompts you care about from the standard set; a sample of 100 or more runs per tool is needed before a rate means much.
2. Record submit_time when you press generate or when the API call returns, first_progress_time when the task first shows progress (queue ends here), and ready_time when the file is downloadable. Use the same clock and, for the API, the task’s status polling at a fixed interval, noted.
3. Read credits_before and credits_after from the account page for every run; do not infer them.
4. Log the hour and weekday, plan, and how many tasks you had in flight.
5. For every non-success, record its type: moderation rejected, timeout, error message, canceled by you, produced but unusable (fails the gate).

Fields: queue_seconds, generation_seconds, total_seconds, concurrent_tasks_in_flight, retries_used, retries_allowed_by_plan, status, failure_type, credits_charged, credits_refunded, hour_utc.

Derived: failure rate (failed or unusable runs divided by runs), and credits per usable output, which feeds cost per usable asset and the credit cost calculator.

Running it on a free tier

Meshy Free allows one concurrent task, low queue priority and no free retries, with 100 credits a month. At the web-app prices of 20 credits for a Meshy 6 text-to-3D run and 10 for Meshy 6 Lite (docs.meshy.ai/en/webapp/pricing), 100 credits buys five or ten runs a month, and Free downloads are limited to untextured Meshy 6 Lite models, so a free account cannot reach 100 runs; label any rate from it as a small-sample observation and do not compare it to a paid account’s. Use the free account to check the logging method and the billing behavior (does the balance change on a failed or canceled run?), and use a paid month, or the same plan on two vendors, for rates. Meshy’s Terms s.4 call fees “non-cancelable and non-refundable”, so budget the test before paying.

Ambiguous results

Rules to set before you start, for borderline readings; they are editorial, not outcomes we have seen.

• Task shows 0% for a long time then jumps: queue time ends at first progress, but if the UI shows no progress field, use the first status change and note it.
• You canceled a stuck task: log it as canceled_by_user, not a failure, and record whether credits returned.
• Credits dropped, then returned later: record both balances and the delay; a refund that arrives after hours still counts as refunded but is worth reporting.
• Output downloads but is empty or a placeholder: status success, usable no. Count it as unusable for failure rate and as success for vendor billing.
• Two runs overlapped: mark concurrent_tasks_in_flight, since queue time on a one-slot plan includes your own earlier task.

Pass or fail

There is no universal bar. Set two before you start: the longest total time you will wait per asset, and the highest share of runs that may fail or be unusable. A tool passes when both hold on your plan and the billing for failures matches its documentation (a failed run should not reduce your balance, where that is promised). If the balance moves on a failed run, that is a documented-versus-actual discrepancy worth reporting to the vendor. Plan-level billing detail is in Meshy pricing and credits and Tripo pricing and credits. To separate speed from variance, also run the repeatability protocol.

More on what AI 3D work costs is in the cost hub.