Meshy v4

Meshy-4 is a retired model version in Meshy's proprietary 3D-generation service, not the platform's current model. Meshy introduced it on August 22, 2024, then retired meshy-4 API requests on March 20, 2026. If you find the version in old code or a tutorial, do not start a new integration with it. Inventory the dependency and evaluate a current model against your own asset requirements.

Meshy-4 in the product timeline

Meshy's launch article introduced Meshy-4 as a selectable model for Text to 3D and Image to 3D. At that point, the company described it as its latest model and emphasized harder surfaces and finer geometric detail. Those descriptions are useful historical evidence, but "latest" was true only in the release context. It is false as a current label.

The lifecycle changed. Meshy's API changelog states that Meshy-4 was retired on March 20, 2026 and that API requests using meshy-4 are no longer supported. The current Text to 3D API documentation lists later supported model choices rather than Meshy-4. Meshy also announced Meshy 7.1 on September 10, 2026 as a later Image to 3D release.

If you maintain an older integration, treat Meshy-4 as a migration problem rather than a current product choice. Identify the obsolete reference, understand the changed contract, and test a supported replacement deliberately. Do not transfer old v4 claims to a successor or assume a new API user can still select v4.

The retirement evidence is specifically about API requests. We did not sign into the Meshy web workspace, inspect an old user's stored tasks, or test historical asset downloads. It would be too broad to say every Meshy-4 asset or web surface is unavailable. A user with an old project should inspect the account and applicable retention terms before deciding what can still be recovered.

What changed in the original workflow

The 2024 release post described a two-part Text to 3D process. A modeling stage produced four untextured candidates from a text prompt. The user then selected one candidate and moved to a texturing stage. That separation was intended to make the geometry decision visible before texture generation committed the workflow to a particular mesh.

The same post said Meshy-4 could be selected for both Text to 3D and Image to 3D. It contrasted Meshy-4 with Meshy-3 Turbo and the legacy Meshy-3 option, and associated Meshy-4 with hard-surface geometry. These statements document the product design at launch. They do not establish animation-ready topology, one-click production readiness, or consistent performance across characters, props, product photos, and printable objects.

For a text workflow, the conceptual input was a natural-language description and the output moved from an untextured mesh to a textured asset. For an image workflow, the input was a reference image. An image-to-3D result necessarily has to infer hidden surfaces that are not visible in a single view. The launch article's examples may illustrate vendor-selected results, but they do not tell you how an arbitrary input behaves.

The current API still documents a preview-then-refine Text to 3D pattern, but that resemblance does not establish contract compatibility. Model identifiers, parameters, task objects, formats, defaults, and retired fields can change. Build the migration from the current endpoint reference, not from the fact that both workflows have two stages.

What retirement means for new work

An explicit ai_model: meshy-4 request is now unsupported. Retry logic, higher timeouts, or more credits will not make it a valid new-model choice. First find every place where the identifier can enter a request: application configuration, environment-specific settings, job payloads, database rows, templates, tests, documentation, and queued work.

Do not replace the value with latest automatically. The alias can move. It is useful when a product intentionally accepts model evolution and risky when stable geometry, cost, latency, topology, or appearance matters. Decide whether predictable behavior or automatic upgrades matter more for the application.

Pinning a current model is not enough either. The downstream acceptance criteria must identify what behavior needs to stay stable. A game prop may need the right scale, silhouette, UV layout, material slots, polygon budget, pivot, and clean import into a target engine. A printable object may need wall thickness, watertight geometry, supported overhangs, and physical dimensions. A product visualization may prioritize proportions and material response. "Generated successfully" is not the same result for those jobs.

Preserve safe old request and response samples before changing the integration. They show which fields the application used and which response properties it consumed. A migration that fixes request creation can still fail if a downloader, processor, viewer, or database expects a retired field.

Inventory an old integration first

Use this source-based inventory before editing production code. It is a planning tool, not evidence that a migration has been executed successfully.

A small test set is more informative than a large unstructured batch. Choose inputs that expose the pipeline's real risks. For a game-asset workflow, that might include one hard-surface prop, one asymmetrical organic object, one object with thin parts, and one asset whose scale is already known. Keep the same inputs and acceptance worksheet across candidate current models. This controls the comparison without pretending the old model is still callable.

Record the model identifier returned or stored with every new task. Record settings and task dates as well. If latest is used, the alias alone is not enough for a later audit because its resolution may change.

Map old assumptions to current docs

The current Text to 3D reference separates standard generation from a smart-topology mode and places conditions on some parameter combinations. Treat those as present contract details, not evidence that Meshy-4 behaved the same way.

The September 11, 2026 changelog adds meshy-6-lite and deprecates meshy-5. The latter still accepts requests, but Meshy plans to stop new traffic in a future release. Deprecation is therefore a migration warning, distinct from the already unsupported meshy-4 API requests.

Validate the replacement model's topology, remeshing, face-count, pose, and format choices before creating a paid task. Request only what the destination needs and test the exported files there. A listed format does not prove destination readiness.

PBR claims need the same version discipline. Meshy's changelog records changes to enable_pbr, texture fields, and model support over time. Do not carry a promised bundle of diffuse, normal, roughness, and metallic maps into the replacement without evidence. Check the current response and the files the destination renderer actually receives.

Do not rely on an unqualified generation-time promise. Queue conditions, model, mode, quality settings, account priority, and service load can affect timing. A one-to-three-minute estimate has no recorded task evidence here. Measure latency during a real current-model trial if it affects a user-facing deadline.

Access, downloads and output rights

Meshy's current free-plan guide says free accounts receive 100 credits per month. It also describes ten free downloads per month for models generated with Meshy 6 Lite, while downloads for Meshy 6 or Meshy 7 require an upgrade. These limits are current plan facts, not Meshy-4 characteristics, and they can change. Recheck them before making a purchasing or workflow decision.

The same guide says API access is not available on the free plan. That corrects a misleading combination often found in old summaries: a service can offer free web access while requiring a paid subscription for API task creation. A production integration must verify the actual account's entitlement and credit model rather than count on a generic "freemium" label.

Rights also depend on the plan and publication choice. The free-plan guide states that free-plan outputs are licensed under CC BY 4.0 and require attribution. Meshy's ownership guide says paid subscribers retain private ownership subject to conditions, including not publishing the asset to the Meshy Community and having rights to the input material. The controlling terms of service, last updated March 7, 2026, place responsibility on the customer to evaluate outputs and prohibit infringing or deceptive uses.

This is more precise than saying paid plans provide "commercial licensing." Current free output may permit commercial use with attribution, while paid output may carry different ownership treatment and conditions. An organization should record the plan at generation time, input provenance, community-publication status, output date, intended use, and applicable terms. Existing enterprise orders or negotiated terms may alter the general website language.

Validate an asset for its real job

Documentation alone cannot tell you whether a generated asset is production-ready. That verdict requires an exact input, current model, settings, output, destination, and reviewer. Use a worksheet that turns "quality" into observable checks.

For geometry, inspect silhouette from required views, missing or invented parts, non-manifold edges, intersections, thin structures, face distribution, normals, pivot, scale, and dimensions. For materials, inspect UV seams, texture alignment, channel naming, color-space assumptions, and how maps behave under the target renderer. For an animated asset, add deformation, joint placement, weight painting, topology flow, and extreme-pose tests. For printing, add watertightness, wall thickness, unsupported features, part separation, tolerances, and a slicer preview.

Define acceptance before generation. A mobile-game prop might require an import without errors, a fixed polygon budget, a one-meter reference scale, no visible UV seam at the normal camera distance, and no missing component from four required views. Record pass or failure per condition. If an output needs repair, record the action and recheck the same criteria. This makes correction effort part of the decision rather than hiding it behind a polished render.

Compare current candidates only under equivalent inputs and settings that matter to the job. Vendor launch examples and vendor-created benchmarks can help identify claims to test, but they cannot substitute for the test. Treat Meshy's internal evaluations as vendor evidence, not an independent recommendation.

Failure modes before a migration

The first failure mode is silent alias drift. A pipeline uses latest, output behavior changes, and no release record identifies the resolved model. Pin a model when stability matters, or monitor and retest the alias when automatic upgrades are intentional.

The second is a partial contract update. Request creation succeeds, but polling never recognizes a new terminal state or the downloader expects an old response field. Exercise the complete path from task creation through storage and destination import. Test documented failure responses as well as success.

The third is incompatible parameter carryover. A deprecated art style, PBR flag, topology setting, or remesh assumption may be ignored or rejected under a current model. Construct requests from the current model's documented combinations. Treat an ignored parameter as a behavior change, not as a harmless warning.

The fourth is plan mismatch. A developer proves a workflow in the web app, then discovers that the free account has no API entitlement or cannot download the chosen current model. Confirm access, credits, download rules, retention, and output rights before building around the service.

The fifth is render-only acceptance. A thumbnail looks good, but the asset fails in Blender, an engine, a slicer, or a material pipeline. The observable check belongs in the destination environment. Stop when a critical criterion fails, fix or regenerate, then rerun the same worksheet.

The sixth is overstating retirement. The API changelog proves that new meshy-4 API requests are unsupported. It does not, by itself, prove that a historical task, downloaded file, or every authenticated web control has vanished. Verify account-specific recovery questions with the current workspace and terms.

When another workflow fits better

Use a current Meshy model only after it passes the relevant asset worksheet and the account terms fit the project. Use a conventional 3D modeling workflow when exact topology, dimensions, brand-controlled geometry, or deterministic revision history matters more than rapid exploration. A generated draft can still support ideation without being accepted as a final asset.

Use photogrammetry or another measured reconstruction process when the job is to capture an existing physical object rather than invent one from text or a single image. Use a commissioned artist or licensed asset library when rights, art direction, and predictable editability outweigh generation speed. Each alternative solves a different problem; none is a universal winner.

If you only need old assets, prioritize retention, download access, and archival formats. If new generation is central, evaluate a supported model under a new contract. The AI model directory can help you identify other model categories, but each candidate still needs the same destination-specific checks.

Method, dates and unresolved limits

This evaluation read Meshy's dated launch article, API changelog, Text to 3D reference, free-plan guide, ownership guide, and terms on September 10, 2026. The changelog and Text to 3D reference were checked again on September 11 to incorporate the new meshy-6-lite and meshy-5 status. It is source-based. No account was opened, no API key was used, no credit was consumed, and no model was generated or imported.

The evidence establishes the release date, documented launch workflow, API retirement, current model identifiers, current free-plan constraints, and published rights distinctions. It does not establish generation speed, topology quality, material fidelity, printability, animation readiness, engine compatibility, current web-workspace availability, or the fate of a specific old task.

Plan limits, model aliases, terms, and API parameters are volatile. Recheck consequential claims and critical links shortly before changing or deploying an integration. A future update may change latest again without changing the historical fact that meshy-4 was retired.

Do not begin new API work with Meshy-4. Preserve old evidence, identify every dependency, choose whether to pin or follow a current alias, run the full current contract, and accept assets only against criteria defined for their destination. Until that work is performed, treat the available evidence as migration guidance, not a hands-on quality verdict.