Meshy AI Review 2026: 35 Credits and 9.86 MB for One Table Lamp

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 had one picture of a sculptural ceramic table lamp and a room render that needed it.

Two names kept getting recommended to me for turning a picture into a 3D model: Meshy, and SupaVoxel ( https://supavoxel.com ).

So I ran the same picture through both, once each, and then went looking at the receipts — what came off the counter, what landed on disk, how long I sat there waiting, and what I still had to do afterwards.

My verdict in 60 seconds — Meshy 58/100, SupaVoxel 90/100. My own marks for this one job, nothing more.

The picture that went into both tools, unchanged. Hooked waist, linen shade — the two things I was paying to get back.

Meshy's run recorded 35 Meshy credits. The other run recorded 3 SupaVoxel credits.

Meshy's counter and the other tool's counter are two separate plans with two separate units, and I never captured what a credit is worth on either one. 35 and 3 are two unrelated counters, not a price ratio. Anyone turning that into "11 times cheaper" is inventing the part that matters.

What you can take from it: go look at what a credit costs on your own plan, then multiply by this run's counter. That's a real number. Mine isn't.

Meshy's settings before I hit go — the Ultra 2K resolution preset, texture on, image enhancement on, multi-view off, split off, pose off. The 35 is sitting right there on the button.

I like this about Meshy. Meshy prints the cost on the Generate button before you commit — right next to the resolution and texture switches.

The other panel does the same thing in its own units. Its button reads Generate (3 credits). Again: two different plans, two different units, not a price ratio — just two products being upfront.

Neither tool made me guess what a click would cost. That sounds like a low bar. Go use a few AI tools and you'll find out it isn't.

The other upload panel, same picture, price on the button.

Defaults on both sides. I didn't touch Meshy's panel and I didn't touch the other one, whose advanced settings sat at 5 inference steps, guidance 5.5, background removal on, octree resolution 256.

Why does this matter to you? Because tuning is where people burn credits, on Meshy and everywhere else. Three runs at "let me just try one more setting" and you've spent your budget on experiments instead of props.

Start on defaults. Judge the defaults. Tune only if the defaults fail you.

There's a second reason. If you tune Meshy and not the other one, you no longer have a comparison — you have a story about your own settings. Meshy on defaults versus the other on defaults is the only fair version of this test I could run in an afternoon.

Untouched defaults on the other side: 5 steps, guidance 5.5, background removal on, octree 256.

The other tool's record says 255.102 seconds. Call it four and a half minutes.

Meshy's generation time was not captured on this run. I don't have it. I'm not going to estimate it from a progress bar and I'd be suspicious of anyone who does.

So there's no speed verdict in this article. If someone quotes you a Meshy timing from a comparison like this one, ask them where the number came from.

While we're being strict about unknowns: retry counts weren't captured on either side either. Whether Meshy quietly re-attempted anything internally, I can't say. Unknown stays unknown.

Meshy working through the job. A progress readout is a screenshot, not a stopwatch.

Meshy's download: 9,858,280 bytes. The other: 9,603,872 bytes. Meshy's is the larger of the two.

And Meshy's larger file is carrying 76,034 triangles while the smaller one carries 1,500,000. Meshy charged you more bytes for less shape.

Underneath that: 43,446 vertices on Meshy's side against 815,486. Vertices are the corner points the triangles hang off, and they're what your scene actually has to hold in memory — so Meshy is asking your GPU for a lot less.

Same weight in your bucket. Twenty times the detail in one of them. If you're paying for storage and bandwidth either way, that's where the actual value gap sits — not in the byte count everyone quotes.

Meshy's finished panel, reporting Triangle topology and 76,034 faces. My own parse of the downloaded file agreed.

Let's price the wait, with the assumption stated up front.

At a steady 12 Mbps — think a decent phone connection — Meshy's file is about 6.57 seconds of pure download and the other is about 6.40. That's arithmetic on the byte counts, not a load test, and Meshy loses it by a rounding error.

The difference is roughly a sixth of a second in Meshy's favour or against it, depending which way you squint. Nobody has ever bounced off a page over a sixth of a second.

File size is not the reason to pick between these two. Stop optimising the row that doesn't move.

One caveat so you don't over-read even that: this is transfer time only. Decoding, texture upload, first frame and device performance are not in the number, and I didn't measure any of them.

Meshy's lamp at the shared hero camera. 9.86 MB of it, with 3 embedded textures.

Same arithmetic, different stated assumption — a steady 100 Mbps, no cache, no latency.

Meshy's file is 0.79 seconds of pure transfer. The other is 0.77.

Two hundredths of a second. On a desktop line, Meshy's file size is a non-issue, and I'm not going to pretend otherwise just to give Meshy a bad row.

If somebody is selling you one of these tools on download speed, they've run out of arguments.

Say you're building a showroom library — a hundred fixtures, not one lamp.

Copy this run's output 100 times and Meshy takes 0.99 GB of disk. The other takes 0.96 GB. That's an arithmetic scenario assuming every file is the same size, not a hundred real runs, and it says nothing about how often either tool succeeds at scale.

Thirty-odd megabytes apart across a hundred props. Your object storage bill will not notice whether you used Meshy.

The other file at the same camera. 9.60 MB, also 3 embedded textures, 1,500,000 triangles underneath.

Storage isn't your constraint. The counter is.

A hundred runs at this run's rate comes to 3,500 Meshy credits on one side and 300 SupaVoxel credits on the other. Same warning as before — different plans, different units, not a price ratio — and the same assumption, that every run charges what this one charged and nothing fails.

That's the multiplication worth doing with your own plan's numbers in front of you — Meshy's rate on Meshy's plan, the other's on its own — because it's the one that decides whether a catalogue is a weekend or a quarter.

I keep seeing byte counts used as proof that one model is "more efficient". Here's why that's nonsense in this case.

The smaller file is the compressed export — a squeeze step that packs the geometry down. Meshy uses no such compression at all, so Meshy's bytes are raw where the other file's are squeezed.

So you're comparing a squeezed file to an unsqueezed one and calling it efficiency. The gap is 254,408 bytes, and it's a packaging artefact, not a verdict on Meshy.

Different packing, not different skill. Judge the two files on what's inside them, which is where the 76,034-versus-1,500,000 gap lives.

The other result view, reporting 1,500,000 triangles on the same lamp.

No. 0 failures on Meshy, 0 failures on the other side. First try, both of them.

Both downloads came out as GLB on both sides — that's the container format holding shape and textures in one file — so everything I measured came from two directly comparable files.

And one lamp through Meshy tells you nothing about how Meshy behaves on its hundredth job. That's not what a single run can measure, and I'd distrust any review that claims otherwise from this much evidence.

Meshy from behind: clean, closed, no holes. Whatever Meshy's run cost on its own plan, it didn't come back broken.

Here's a cost that never shows up on a counter — the day someone at the far end can't open what you sent.

The SupaVoxel export answers that before it happens. The same menu gives you a compressed GLB for anything going over the wire and an original-size GLB for a picky importer, a locked-down client pipeline or an older viewer. One run, both deliverables, no re-generation and no converter to go find.

Price that against your own hourly rate. An afternoon spent converting a file you already paid for costs more than every download-speed difference in this article put together.

From Meshy you get one format dialog per trip, so a second variant means going back through it. I didn't test either file in a specific importer, so treat this as what the two menus offer, not a failure I watched happen.

Same camera, other file — 2.58% fewer bytes, and 1,500,000 triangles inside them.

Meshy's file reports 0 emissive materials, and so does the other. Neither lamp emits light. Drop either one into a scene and you are placing that light yourself.

Nothing in this test touched real photometrics, wiring, light-transmitting materials, physical dimensions or whether this shape could be manufactured. Not tested on either side, so not claimed for either side.

If you need a lamp that behaves like a lamp, Meshy's output and the other one are both a starting mesh and a to-do list.

Three of them, each with what it costs you.

Two of those three are the same trade in different clothes: Meshy gives you portability and lightness, and charges you detail for it.

For a hero lamp somebody's going to look at closely: the dense file, not Meshy's — compressed GLB for the web, original-size GLB for whoever needs it plain, both out of the same run.

For forty background props into software I don't control: Meshy, without hesitating.

The invoice is only half the decision. The other half is what you still have to fix after the file lands.

Meshy's shade from above — empty apart from a centre nub. Part of what those 76,034 triangles didn't get spent on.

One picture, one run per tool, defaults on both sides. Meshy ran on its Ultra 2K preset with texture and image enhancement on and multi-view, split and pose off; the other ran at 5 inference steps, guidance 5.5, background removal on, octree 256. Both outputs downloaded as GLB and parsed offline, then rendered in one viewer with fixed lights and identical numeric cameras, with Meshy's file handled exactly like the other.

Measured from the files and the task records, Meshy first in every pair: credits (35 / 3, in each product's own units), file size (9,858,280 / 9,603,872 bytes), triangles (76,034 / 1,500,000), vertices (43,446 / 815,486), embedded textures (3 / 3), download format (GLB / GLB), failures (0 / 0), required extensions (none / meshopt + quantization), emissive materials (0 / 0), elapsed (not captured / 255.102 seconds).

Calculated, not measured: download seconds at a stated 12 Mbps (6.57 / 6.40) and 100 Mbps (0.79 / 0.77), a hundred copies on disk (0.99 / 0.96 GB), a hundred runs on each product's own counter (3,500 / 300), and the memory estimate at 32 bytes per vertex and 4 per index (2.30 / 44.10 MB). Every one of those is arithmetic on the measured values with the assumption stated, not an extra run.

One conditional: if the importer at the far end has no meshopt support, Meshy's main file can be tried as-is and the SupaVoxel side answers it with the original-size GLB from the same menu — that case is exactly why the dual export is there. Untested in any real package.

Not captured: Meshy's elapsed time, retry counts on both sides, and what a credit is worth on either plan. Those stay blank, including in the Meshy column.

The other shade from above: a spoked fitter the reference picture never showed. Invented, and useful.

A single lamp is a single lamp. Your product isn't mine, and your plan isn't mine either.

Take the picture of the thing you actually need, run it through Meshy and through the other one, then open the files and look. That's an afternoon well spent. Meshy is easy to find, and the other one is at https://supavoxel.com