How to Retest Meshy, Tripo and Rodin After a New Model Version

Know exactly which version you used

Version names are messy, and that is a reproducibility problem before it is a quality one. Meshy’s API pricing page lists meshy-7.1 (with latest beside it), meshy-6, meshy-6-lite, meshy-t2 and meshy-t2.5 as model identifiers, while its docs landing page names Meshy 7 and 6 and omits 7.1 and 6 Lite (November 2026). The value latest is an alias that can change under you. Tripo’s developer docs landing page lists H3.1 and P2.0 and a dated API example, v3.1-20260211. Rodin’s changelog records Gen-2.5 documentation (May 2026), a change of the default geometry_instruct_mode from faithful to creative (July 2026) and updates to add-on pricing (August 2026), at month level only. Meshy’s own comparison post (posted 7 September 2026, updated 27 October 2026) names Meshy 7.1 as the current build, uses Meshy 7 in its alignment and texture benchmarks and Hi3D 2.1 in the alignment benchmark, and says its texture benchmark labels the Tripo entry “3.5” while Tripo’s public materials name P2.0 and 3.1.

So log the identifier the API accepts or the string the UI shows at run time, and prefer a dated or pinned ID over latest.

What Meshy’s API changelog shows about drift

Meshy’s API changelog (docs.meshy.ai/en/api/changelog, read 2026-11-08) is the clearest primary record of how a version name moves under you. These are API dates; the web app may differ.

Three lessons for the protocol. First, a model can disappear: Meshy-4 was retired on 2026-03-20 and Meshy-5 on 2026-10-10, so archive outputs and settings, not just prompts. Second, record the parameter defaults as well as the model, because a default flip (should_remesh) changes mesh density on its own. Third, on 2026-11-08 the text-to-3D docs list meshy-7 as deprecated while Retexture’s latest still resolves to Meshy 7, so “latest” is not one model across a pipeline. Tripo and Rodin changelogs gave us no comparable day-level record we could read (Tripo’s docs list product names without dates; Rodin’s changelog is month-level, as cited above).

What the published version comparison covers

Meshy’s 12 August 2026 post compares Meshy 7 with Meshy 6 Lite (not Meshy 6) and other vendors’ models using an automatic geometry benchmark on rendered held-out models. Under single top-quarter input the post reports Meshy 7 ahead of the other models on all three scores. With four views it says Meshy 7 “remains among the leading models”: its own table has Hi3D 2.1 and Tripo 3.1 scoring higher on overall proportion and on surface details, and the post says the gap between leaders is “small relative to the variation across individual test objects”. Limits: it is vendor-run, covers image-to-geometry only (it says it focuses specifically on geometry alignment and leaves texture to later work), uses renders, and the benchmark had not been released when we read it. It is one release step; it is not a history of re-runs. A second Meshy post (the Hi3D, Meshy and Tripo comparison) reports a blind pairwise arena at top3d.ai in which Tripo 3.1, Hi3D 3.0 and Meshy 7 all rank above Meshy 7.1 on overall quality, and concedes that Meshy 7.1 does not rank first there; that is a vote, not a mesh measurement. Back to the tests hub.

Retest protocol

1. Freeze a baseline. Before a release, archive raw outputs for a fixed subset of the standard prompt set (at least one prompt per class), with model identifier, plan, date and settings. Keep the prompts verbatim.
2. On a release, rerun the same prompts with the new identifier, same settings, same plan. If the old model remains selectable, rerun it too the same day to separate a model change from drift.
3. Compare using metrics, not impressions. For each prompt, record the deltas below.
4. Repeat for variance. One new output against one old output can be noise; use the repeatability protocol before calling a regression.
5. Log it publicly or privately, with the date; PromptToProp’s planned log will live on the corrections and retest page.

Fields: model_old, model_new, prompt_id, delta_triangles, delta_loose_pieces, delta_open_edges, delta_cleanup_minutes, delta_gate (pass to fail, fail to pass, unchanged), delta_credits, texture_change (better/worse/same, with the map), notes.

Ambiguous results

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

• Mixed deltas (fewer loose pieces, more open edges): do not net them. Use your gate; if the gate result is unchanged, call it “unchanged” and list the mixed metrics.
• Within the noise: if the old model’s own two reruns differ by as much as old versus new, record “not distinguishable” and keep the old identifier.
• Old model no longer selectable: you cannot attribute a change to the model. Compare against your archived baseline and label it “baseline from date, not same-day”.
• Default changed, model did not: record it as a settings regression, not a model regression, and pin the parameter explicitly next time.
• Credit cost changed: report delta_credits separately; a cheaper but worse model is a decision, not a pass.

Pass or fail

An upgrade passes when your gate-pass count on the baseline prompts rises or holds, cleanup minutes do not rise, and the credit cost does not rise beyond what you accept. A regression is any prompt where gate result goes from pass to fail, or cleanup time rises sharply, even if the average improves; report these first. Keep the old identifier in use for any project that already shipped with it, where the vendor still offers it.

Where this connects

The wider comparison is in the game-prop comparison; release dates are tracked in the AI 3D model release tracker; for how to read vendors’ reviews alongside these changes, see the Meshy review and the Tripo review.