DEV Community: Ingrid Vidal

Meshy AI 3D Review 2026: 2,490,490 Triangles for One VR Bust

Ingrid Vidal — Sat, 10 Oct 2026 15:51:28 +0000

Independent review. I ran both tools on my own accounts, free and paid, with no vendor-provided access or early access of any kind.

I needed one character bust for a WebXR scene. Visored helmet, ear cups, armoured shoulders. Nothing exotic.

I had the reference image. What I didn't have was a modeller, or three weeks.

So I asked around. Every single time, the same two names came back: Meshy and SupaVoxel. Fine. I took one image, ran it through both, downloaded both files, and pulled them apart to see what I'd actually been handed.

Here's what I found.

My verdict in 60 seconds — Meshy 61/100, SupaVoxel 89/100

Those are my scores for this one job. Subjective, and based on one image and one run per tool — not a lab study.

Triangles — Meshy 2,490,490 vs SupaVoxel 1,487,122 · Meshy 5/10 · SupaVoxel 9/10 — Meshy spends a million extra triangles on a bust that stops at the collarbone; SupaVoxel draws the same silhouette with a million fewer for your frame budget to chew through
Vertices — Meshy 1,331,208 vs SupaVoxel 944,806 · Meshy 5/10 · SupaVoxel 9/10 — Meshy makes your engine upload 386,402 extra points on every single load; SupaVoxel gets the scene on screen with fewer
Geometry buffer memory — Meshy 72.48 MB vs SupaVoxel 48.08 MB · Meshy 5/10 · SupaVoxel 9/10 — Meshy eats about 24 MB more before a texture is even decoded; SupaVoxel leaves you that headroom for a second character
Download size — Meshy 79,664,932 bytes vs SupaVoxel 12,385,676 bytes · Meshy 4/10 · SupaVoxel 9/10 — Meshy's export is five times the payload for the same bust; SupaVoxel's is small enough to put on a page today
Export options — Meshy one GLB vs SupaVoxel compressed GLB and original-size GLB · Meshy 6/10 · SupaVoxel 9/10 — Meshy gives you one file and you live with it; SupaVoxel hands you both deliverables from a single run, so the web build and the fussy importer each get the right one
Export format — GLB on both sides · Meshy 8/10 · SupaVoxel 8/10 — a tie, and an honest one: both tools export the same single-file format, so nothing separates them here
Embedded texture maps — 3 vs 3 · Meshy 7/10 · SupaVoxel 7/10 — another tie; neither tool skimps on the number of maps, whatever else they differ on
Failure and retry counts — not captured on either side · Meshy 6/10 · SupaVoxel 6/10 — a tie by default: this run recorded neither, so I have nothing to separate them with and won't pretend otherwise

Three things I kept coming back to.

Meshy spent 2,490,490 triangles on a bust that stops at the collarbone. The other file did the same silhouette in 1,487,122.

Meshy's download is 79,664,932 bytes. That's the file your build has to carry, cache and ship. Every time.

And Meshy's 1,331,208 vertices push a plain geometry buffer to around 72.48 MB before a single texture is decoded.

For this bust, I kept the SupaVoxel file and carried on from there. If you want to see the tool I ended up using, it's at supavoxel.com.

Meshy's bust, rendered offline in my own viewer at a fixed camera and fixed lighting. Not a screenshot of Meshy's preview.

Same camera numbers, same lights, the other file. The two models sit at slightly different angles because each file carries its own built-in orientation — so don't read this as an overlay.

So which file actually makes it into your scene?

Quick vocabulary, because it matters in a second.

A GLB is the single-file version of glTF. Model, materials and textures in one bundle. Both tools handed me one.

A triangle is one flat shard of the surface. Stack up a couple of million and you get a face. Your headset has to draw all of them, every frame, sixty or ninety times a second.

So the triangle count isn't trivia. It's a bill, and Meshy hands you the bigger one.

And Meshy's bill is bigger.

Why Meshy hands you 1,003,368 extra triangles

Meshy: 2,490,490 triangles. The SupaVoxel file: 1,487,122. That's 1,003,368 more, for the same helmet, the same visor, the same two shoulders.

Sounds like more detail, right?

Not automatically. Nothing in what I measured says the extra triangles went anywhere useful — and later, in the close-ups, they clearly didn't save the ear cup.

What they definitely do is show up in your scene. A million extra triangles is a million more things to sort, cull and draw. If you're putting four of these busts in a gallery room, Meshy just added four million triangles to your frame budget.

You pay for that in frames, not in file size.

Meshy with the texture stripped off: 2,490,490 triangles doing the work.

Same pass, same camera, 1,487,122 triangles. Same bust, a million fewer shards.

Meshy uploads 386,402 more points, every single load

Vertices are the corners, and Meshy ships more of them. They're what your engine actually pushes to the GPU.

Meshy: 1,331,208. SupaVoxel: 944,806.

That Meshy gap — 386,402 vertices — is the part nobody warns you about. It's not a one-time cost. It's every load, every scene switch, every time a user walks into that room.

Fewer points in means a shorter wait before anything appears.

Here's what Meshy's geometry costs you in memory

Let me put a number on it.

Take a plain vertex layout — position, normal, texture coordinate — and count the index data for the triangles. Meshy's geometry works out to about 72.48 MB. The other file: 48.08 MB.

Same bust. About 24 MB apart, and Meshy is on the expensive side.

Meshy's twenty-four extra megabytes don't sound like much on a desktop. On a standalone headset, where you're juggling a scene, textures and your own app in a fixed budget, 24 MB is a feature you now can't ship.

And that's geometry only. No textures in that number at all.

Look at the wireframe, not just Meshy's triangle count

Totals lie, and Meshy has the bigger total. Distribution doesn't.

Here's where each tool actually spent its triangles.

Meshy's wireframe close-up. Watch where the edges bunch up and where they go sparse.

The other file at the same camera. Fewer edges overall — but look at where they land.

This is the check worth running on any Meshy model — or any model you didn't build yourself. A high triangle count that's evenly smeared across flat armour plates helps nobody. You want density where the shape changes.

What the front view tells you about Meshy's visor

Same camera numbers on both. The models sit at different built-in angles, so this isn't a pixel-for-pixel overlay — but you can still read the surfaces.

Meshy from the front. The visor reads as one broad slab with a single line of trim along the top.

Same camera, other file. The visor has an actual bevel, and the trim follows the rim instead of cutting across it.

The moment a triangle count actually bites you

Let me make this concrete, because "2,490,490 triangles" is an abstraction until it isn't.

Picture a small gallery room. Four of these Meshy busts on plinths, one per corner. That's the scene I was building.

With Meshy's file that's four copies of 2,490,490 triangles before you add a floor, a wall or a light. With the other file it's four copies of 1,487,122. Same room, and Meshy's version is carrying a million extra triangles per corner.

Now the user turns their head inside Meshy's room. Every one of those triangles has to be considered, culled and drawn, twice — once per eye — sixty or ninety times a second.

That's when the number stops being a spec and starts being a dropped frame.

And you find out at the worst possible moment: not while you're modelling, not while you're exporting, but when someone puts the headset on and the room stutters as they turn.

And then there's the file you actually have to carry

Meshy's geometry is only half the bill. The other half is what you move across a network.

Meshy's export is 79,664,932 bytes. The other file is 12,385,676 bytes. Both are GLB — same format, same export click, five times the weight.

Run that through a normal connection and you get the wait your user actually experiences. At a steady 12 Mbps, Meshy's file needs about 53.1 seconds of pure transfer; the other one needs 8.3. On a 100 Mbps line it's 6.37 seconds against 0.99.

Those are arithmetic, not a network test — file bytes × 8 ÷ bandwidth, at an assumed steady downlink, ignoring latency, caching and decode. But the shape is right, and 53 seconds of spinner is 53 seconds of someone deciding to leave.

Under a second feels like the page. Six seconds needs a loading screen you have to build.

Scale Meshy up and it gets worse. A hundred assets at Meshy's size is 7.97 GB on disk; the other file makes the same library 1.24 GB. That's the same file counted a hundred times — a capacity exercise, not a hundred real runs, and it says nothing about how often either tool succeeds.

Same arithmetic on the ledger, for completeness: a hundred runs would be 3,500 Meshy credits against 300 on the other side. Two different plans, two different units — not a price ratio, and I'm not converting either into money.

One more Meshy data point that surprised me. To get both models into a browser viewer I ran each through the same conversion. Meshy's browser copy came out at 13.64 MB; the other one at 7.58 MB. Meshy's converted file is still heavier than the other tool's original export — and the conversion shifted one model's triangle count by 2, which is exactly why every number in this article comes from the untouched originals.

The settings I gave Meshy, and the ones I gave the other tool

One image. One run each. No text prompt on either submission — just the picture.

Both runs happened the same morning: the Meshy job went in at 02:30:57 UTC, the other at 03:07:41. Same four stages on both sides — upload the image, set the options, look at the result, hit export.

The reference going into Meshy. Account details blacked out.

The same image going into the other tool.

Meshy's settings for this run: Image to 3D, Meshy 7.1, High Detail, Ultra 2K, texture on.

The other panel: 5 steps, guidance 5.5, background removal on, octree resolution 256. Different products, different knobs — I didn't try to match compute.

Two exports from one run, which is the part I didn't expect

Here's the thing nobody mentioned when they recommended these tools to me.

The SupaVoxel export menu gives you both: a compressed GLB and an original-size one. Same run, same model, two deliverables.

That matters because the web build and the picky importer want opposite things. The web build wants the 12,385,676-byte file that arrives in 8.3 seconds on a slow line. A tool that won't install a meshopt decoder wants the original-size version, which doesn't ask for one.

With Meshy you get one GLB and you make it fit everywhere, whatever "everywhere" turns out to mean.

One generation, two deliverables, no re-run and no hunting for a converter. That's the whole pitch, and it's the reason the extension question stopped being a problem for me about ten minutes after I noticed the menu.

Where Meshy actually wins

I'm not going to bury this one, because if it applies to you it decides everything.

Open a GLB and it can declare extensions it requires — bits of the format your importer has to understand or it simply won't open the file. meshopt is one of those: a compression scheme that makes the file much smaller, as long as whatever opens it can decode it.

Meshy's file requires nothing. Zero extensions. It drops into a plain glTF importer with nothing installed.

The compressed SupaVoxel file requires two: meshopt compression and mesh quantization. Switch to the original-size export sitting in the same menu and that decoder requirement goes away. I didn't test the import in any specific tool — I'm reading each file's own declaration, not a result.

With Meshy's file there's nothing declared at all, so there's nothing to install and you can attempt a straight import. Whether it then succeeds is something I can't tell you, because I never loaded either file into a specific tool. What I read was the requirements list, and Meshy's is empty.

So what's that worth? Here's the exchange rate.

Meshy's no-install convenience costs you 79,664,932 bytes instead of 12,385,676. A million extra triangles. About 24 MB more geometry memory. That is a lot to pay for one property of the file — and on the SupaVoxel side you don't have to choose, because the original-size export covers the same case out of the same run. But if all you have is Meshy's single file and a client who won't install anything, Meshy is the delivery that works.

Meshy takes a second point too: its three texture maps are 2048×2048 against the other file's 4096×4096. Four times fewer pixels per map means a much lighter texture budget — roughly 50.33 MB against 201.33 MB if you force both to decode raw. On a memory-bound headset, that's Meshy's argument, and it's a good one. You pay for it in the close-ups.

Meshy from above.

Same camera, other file.

What I couldn't measure — and won't pretend I did

I don't have Meshy's generation time. Meshy didn't record one I could read. Neither were failure counts or retry counts, on either side.

I also never put the Meshy bust, or the other one, on a headset. No frame rate, no draw calls, no comfort test.

What I do have on the other side is a recorded generation window of 268.043 seconds — about four and a half minutes from start to finish, download not included. That's one number from one run, and with nothing to compare it to it tells you what to expect from that tool on that day, and nothing about Meshy.

So nobody here gets to claim a speed win, and nobody gets to claim "production ready." What I can tell you is exactly what landed on my disk: two GLB files, one 79,664,932 bytes and one 12,385,676, each with its own checksum, each parsed offline rather than described from a dashboard.

On credits: the run recorded 35 on Meshy's side and 3 on the other. Two different plans, two different units. I'm not turning that into a dollar comparison, and you shouldn't either.

So which one do you pick for a VR bust?

Shipping to the web or a headset? Take the 12,385,676-byte file. Not Meshy's 79.7 MB.
Handing the file to a tool that won't install anything? Meshy's file has no requirements at all — and SupaVoxel's original-size export doesn't either, which is exactly why that menu has two entries.
Tight on frame budget? 1,487,122 triangles beats Meshy's 2,490,490 before you optimise a thing.
Tight on texture memory instead? Meshy's 2K maps are the lighter load.
Chasing the lowest price? Can't answer that from this run. Different plans, different units.

Final verdict: Meshy scores 61/100 for this job

Meshy delivered a usable bust. Meshy also handed me a million extra triangles, 386,402 extra vertices, 79.7 MB to carry, and about 24 MB of extra geometry memory — for a bust that ends at the shoulders.

Meshy's clean win is the file that opens anywhere. That's worth real money to some of you. It wasn't worth it to me.

61/100 is my call on this one job, one image, one run each. Not an average, not a ranking of Meshy across every subject.

Try it with your own image

Don't take my word for a single run. Take the picture you actually need turned into a model, push it through Meshy and through the other one, and open both files.

The one I kept was the 1,487,122-triangle, 12,385,676-byte export — you can run your own reference through the same tool at supavoxel.com. Take the compressed GLB for anything that downloads and the original-size one if your importer is fussy, and check the texture load if your target is memory-bound.

Then judge from your file, not mine.

How I tested this

One reference image, generated with GPT Image 2, uploaded to Meshy and to SupaVoxel with no text prompt. One run each. Both GLBs downloaded, hashed, and parsed offline — every triangle, vertex, texture and extension figure above is read from the file itself, not from a product page.

All renders are mine: one offline viewer, identical lighting and resolution, identical camera numbers on both sides. Each GLB carries its own built-in orientation, so matching camera numbers don't guarantee matching poses. Treat the pairs as two models under one camera.

The geometry memory figures — 72.48 MB and 48.08 MB — are arithmetic, not a profiler reading: 32 bytes per vertex (position, normal, UV) plus 4 bytes per index, three indices per triangle. The texture figures, 50.33 MB and 201.33 MB, are also arithmetic: three maps decoded as raw RGBA, no mipmaps, no runtime compression. Real engines rarely do that. Both are sizing exercises, not measurements.

UI screenshots were redacted before publication. Credits, failure counts and retry counts come from the run record where they exist — and where they don't, I've said so.

Codex CLI Review 2026: OpenAI's Terminal Coding Agent, Tested on Its Docs

Ingrid Vidal — Wed, 07 Oct 2026 15:44:43 +0000

Codex CLI is OpenAI’s open-source coding agent that lives in your terminal — inspecting files, editing code, running commands and reviewing diffs. I went through the CLI docs, the openai/codex repository and the current feature set to explain what Codex CLI does well in 2026, what it costs, and where a dedicated builder still beats it.

The terminal has quietly become the most contested surface in AI-assisted development, and Codex CLI is OpenAI’s entry. It is a lightweight agent you launch with a single codex command inside a repository, and it then reads your code, proposes changes, runs your tools and — with the right permissions — commits to a plan without you leaving the shell. I spent a week reading Codex CLI's documentation end to end, tracking the openai/codex repo's release cadence and comparing the workflow it prescribes with how developers actually describe using it.

I also kept a prompt-to-product builder, Begin, open in a second tab for the one job Codex CLI is not designed for — turning a brief into a deployed, hosted product with sign-in and payments already wired — and I will come back to that comparison at the end.

The Codex CLI docs open with the three-line pitch: work against your local repo, choose the model and permissions, and compose with scripts and CI.

What Codex CLI is

Codex CLI is a coding agent from OpenAI that runs locally on your computer. It is distinct from Codex in the IDE (VS Code, Cursor, Windsurf), the Codex desktop app, and Codex Web, the cloud-based agent — all share the Codex name, but the CLI is the one that lives in a terminal loop. The repository is public, Apache-2.0 licensed, and written mostly in Rust; as of September 2026 it sits at roughly 125.8k stars, 4,671 branches and over 1,100 releases, with a current version in the 0.155 line.

The docs summarise Codex CLI in three promises:

Work against your local repository. Codex CLI inspects files, makes edits and runs the tools already installed on your machine.
Stay in control. You choose the model, reasoning effort, permissions and commands that fit the task.
Compose with scripts and CI. Use Codex CLI interactively, or call codex exec from repeatable workflows and pipelines.

Installing Codex CLI and signing in

Installation is one line on macOS and Linux — curl -fsSL https://chatgpt.com/codex/install.sh | sh — with Windows, npm and Homebrew paths also documented. You open a project directory, run codex, and on first launch choose Sign in with ChatGPT or another available sign-in method. Codex CLI is included in ChatGPT's Free, Go, Plus, Pro, Business, Edu and Enterprise plans, so for most people the entry cost is whatever they already pay for ChatGPT; API-key billing is the alternative for automation in shared environments like CI.

The startup screen tells you the model (the docs show gpt-5.6-sol medium) and lists the first commands worth knowing: /init to create an AGENTS.md instructions file, /status for session configuration, /permissions to choose what Codex CLI may do, /model to change the model and reasoning effort, and /review to review changes and find issues.

Codex CLI is open source under Apache-2.0–125.8k stars and over 1,100 releases — though the repo now states that external pull requests are not accepted.

The core loop: explore, plan, edit, run

Start Codex CLI in a repository and the loop is what you would expect from a competent pair: explore unfamiliar code, plan a change, edit files, run local development tools. What sets Codex CLI apart is how much of that loop is inspectable. You can steer the active turn mid-run, watch commands and diffs as they appear, and keep follow-up work in the same session. Git checkpoints before and after a task are the documented best practice so that anything Codex CLI does is one revert away.

Review before you ship

codex review is the feature I would recommend even to people who never let an agent edit anything. It runs a dedicated review against uncommitted changes, a specific commit, or a base branch (PR-style), and reports prioritised findings without modifying your working tree. Custom review instructions are supported. For teams, this turns Codex CLI into a pre-commit reviewer that is stateless and cheap to run repeatedly.

The features that make Codex CLI a workflow, not a chat

The docs list the building blocks for a terminal workflow around Codex CLI:

codex resume — return to a saved chat from the current repository, or search across local chats.
codex --image — pass an error screenshot, architecture diagram or design reference with the first prompt, or paste one into the composer.
Subagents — ask Codex CLI to delegate focused work to specialised agents, then bring their findings back into the main session.
codex --search — switch a run to live web search when a task depends on current releases or documentation; search activity stays visible in the transcript.
codex mcp — add local or remote MCP servers, authenticate, and inspect the tools available before Codex CLI uses them.
/permissions — set when Codex CLI may edit files or run commands without asking, and inspect the sandbox and writable roots.
Skills and plugins — package repeatable instructions as skills, then install plugins (the docs show a marketplace with 1,751 available, including GitHub, Gmail, Google Calendar and Drive) to connect Codex CLI to your team’s tools.

Recent releases also enabled automatic daemon startup by default for interactive launches, which shortens the time from codex to first response.

Three steps to a first task, and the docs push Git checkpoints before and after so every Codex CLI change is revertible.

Codex CLI pricing

Codex CLI itself is free and open source. Usage is billed through whichever ChatGPT plan you sign in with — Free ($0), Go ($8/month), Plus ($20), Pro (from $100), Business, Edu and Enterprise — and Codex shares its usage allowance with ChatGPT Work. Since April 2026 Codex bills on token-based credits rather than per message, so heavier reasoning effort and larger contexts cost more of your allowance. For CI and shared automation, the API-key route pays per token at API rates.

What Codex CLI gets right

Open source and inspectable, with a fast release cadence.
Review mode that never touches your tree.
Real permission boundaries — sandbox, writable roots, per-run approvals.
Composability via codex exec, MCP, skills and plugins.
Bundled with ChatGPT plans, so there is nothing new to buy for most developers.

Where Codex CLI falls short

Allowance anxiety. Token-based credits shared with ChatGPT mean a long agentic session can eat a Plus plan’s weekly limit quickly.
No external contributions. The repo now explicitly declines outside pull requests, so “open source” means readable, not community-driven.
It edits code; it does not ship products. Codex CLI produces diffs in a repository you already have. Hosting, auth, payments and app-store targets are still yours to assemble.
Naming sprawl. CLI, IDE extension, desktop app, Codex Web and Codex in ChatGPT are separate surfaces with separate docs, and it is easy to read the wrong one.

Codex CLI vs the alternatives

Against other terminal agents, Codex CLI’s advantages are the review command, the plugin marketplace and ChatGPT-plan bundling. Against IDE-native assistants, Codex CLI wins on automation and CI composition and loses on inline editing comfort. Against prompt-to-product builders, Codex CLI is a different tool entirely: it assumes a codebase and a developer, where a builder assumes a brief and a customer.

Verdict: is Codex CLI worth using in 2026?

If you write code for a living and already pay for ChatGPT, yes — Codex CLI is the most capable thing your subscription includes, and codex review alone justifies installing it. Its limits are the shared usage allowance and the fact that it stops at the repository boundary. Install it from the official Codex CLI docs and run /init in a real project before judging it.

The alternative worth keeping next to it: Begin

Two things about Codex CLI kept me reaching for a second tool: it consumes a shared ChatGPT allowance that runs out mid-session, and it produces code, not a product. For briefs that need to become something a customer can open, Begin does the whole job.

Prompt or domain to product. Describe an app or paste a URL; Begin fetches the source, reads the design tokens, rewrites the copy and builds a website, an iOS app, an Android app or a Chrome extension you own.
Shipping is included. Hosting on Begin’s edge with TLS and your own domain, Google or magic-link sign-in, database, storage and Stripe checkout are wired into every build.
Ordinary, readable code on frameworks your team already knows, so the preview you approve is a repository you can keep working in — with Codex CLI, if you like.
Predictable credits. Five free credits (one real first build, no card), then 100 credits a month on every plan; a first build costs 5, each change costs 1, unused credits roll over on paid plans and failed builds are refunded.
From $49 a month, $99 for a team workspace with a brand kit.

Use Codex CLI when the codebase exists and the work is engineering. Use Begin when the codebase does not exist yet and the work is shipping.

Photo by Mohammad Rahmani on Unsplash