DEV Community: Viktor Delgado

Higgsfield AI Image Generator Review 2026: Same Model, 2x the Credits

Viktor Delgado — Tue, 20 Oct 2026 15:47:50 +0000

I ran one 682-character prompt through Higgsfield and through kyncept.com. Both call Nano Banana Pro, both returned a 1376 × 768 image, and the two pictures are a tie. Every real difference sits around the picture: 2 credits against 1, a "HIGGSFIELD AI" mark baked into the PNG pixels, twice the file weight at the same resolution, and a free balance that cannot reach the catalog it displays.

My verdict in 60 seconds — Higgsfield 60/100, Kyncept 90/100

Same model, so the picture is a tie. What gets charged on top of it is where the score goes.

Image quality — Higgsfield 9/10 · Kyncept 9/10 — identical Nano Banana Pro output, 1376 × 768 on both.
Prompt adherence — Higgsfield 9/10 · Kyncept 9/10 — 2 of 3 samples against 2 of 2 met all four hard requirements.
Price per image — Higgsfield 5/10 · Kyncept 10/10 — 2 credits against 1, and Higgsfield's own table says 1,200 credits = 600 generations.
Speed — Higgsfield not scored · Kyncept 59.9 s and 69.3 s — Higgsfield's image timer was not measured this round, so the row stays blank rather than being handed to either side.
Watermark — Higgsfield 2/10 · Kyncept 9/10 — the mark is in 3 of 3 free-plan PNGs; the 2 Kyncept exports were clean, on a $59 Pro plan.
File size — Higgsfield 4/10 · Kyncept 9/10 — PNGs averaging 1.5 MB against JPEGs averaging 0.8 MB, same resolution.
Upsell pressure — Higgsfield 3/10 · Kyncept 8/10 — a countdown banner plus a "Get personal 55% OFF" card over the lower-right of the editor.
Commercial rights — Higgsfield 5/10 · Kyncept 9/10 — 3 of 3 free exports arrive stamped and need retouching before use.

Three concrete problems:

2 credits per image against 1, for a generation neither platform owns.
A watermark inside the pixels of all 3 Higgsfield PNGs, and twice the download weight at the same 1376 × 768.
28 video models listed on a 4.0-credit free balance; the cheapest needs 20.

For a month of recurring image work on a fixed budget, I would use Kyncept.

The test: one prompt, one model, two platforms

One prompt, pasted unchanged into both editors at 16:9: a museum-style evolution encyclopedia infographic for the golden retriever — exactly 6 stages, one DNA-inspired line, a photorealistic reconstruction per stage, a bold species name, a years-ago number, and one anatomy callout per stage, in three accent colours on white.

Model — Higgsfield Nano Banana Pro · Kyncept Nano Banana Pro · identical
Resolution — 16:9 at 1376 × 768 · 16:9 at 1376 × 768 · identical
Generate price — Higgsfield 2 credits · Kyncept 1 credit · 2×
Where I ran it — higgsfield.ai · Kyncept · two separate accounts
Images kept — Higgsfield 3 · Kyncept 2 · 5 total
Watermark in the file — Higgsfield 3 of 3 · Kyncept 0 of 2 · baked into the PNG, not a preview layer
Prompt field — Higgsfield accepted 1,600 characters with no truncation · Kyncept truncates at 1,500

That prompt-field row is the one place Higgsfield wins on image work: a rich-text field that swallowed more than twice what I needed, so Kyncept's 1,500 limit never bound.

Higgsfield's parameters: Nano Banana Pro, 16:9, 1K — Generate reads 2 credits.

Kyncept's parameters: the same model, 16:9, original size, ×1 — Generate reads 1 credit.

Six stages, one honest tie

All five finished images, side by side.

Kyncept image 1: 6 stages, a DNA line, 6 callouts, a years-ago number on each.

Kyncept image 2: same template rearranged, DNA line through ringed stages, no duplicates.

Higgsfield image 1: 6 stages, DNA line, callouts and years all present — watermark bottom-right.

Higgsfield image 2: circular stage thumbnails on a DNA helix, 6 callouts, watermark again.

Higgsfield image 3: the sample that missed — the "Soft Mouth" callout printed twice.

Two platforms, one identical model, and the five results differ the way five dice throws differ — layout rearranged, stage style changed, one label repeated. The flaw worth naming is Higgsfield's third sample, where the "Soft Mouth" callout printed twice: the same Nano Banana Pro that produced a clean image on the other side, having a bad roll.

Prompt adherence: 6 stages, 6 callouts, one duplicated label

Four hard requirements, counted per image rather than judged as a set.

Exactly 6 stages — Higgsfield 3 of 3 · Kyncept 2 of 2 · every image got the count right
One DNA-inspired line — Higgsfield 3 of 3 · Kyncept 2 of 2 · present in all 5
One callout per stage — Higgsfield 2 of 3 · Kyncept 2 of 2 · the 3rd Higgsfield sample printed "Soft Mouth" twice
All four at once — Higgsfield 2 of 3 · Kyncept 2 of 2 · the only gap in the tally

A close crop: the "Soft Mouth" callout appearing twice in Higgsfield image 3.

That is a tie with a footnote: the gap is one image, on one requirement, on a model neither platform trained. Making it a platform property would take the same requirement missed across every sample.

Price per image: 2 credits vs 1

This is where the same picture starts costing different money.

Credits per image — Higgsfield 2 · Kyncept 1 · 2×
Balance before → after, one image — Higgsfield 4.0 → 2.0 · Kyncept 230 → 229 · both deducted as advertised
Higgsfield's own table — 1,200 credits = 600 Nano Banana Pro generations · 270 = 135 · 3,000 = 1,500 · 2 credits per image, three ways
Kyncept's pricing page, plain text — "1 image = 1 credit" · "1 video starts at 10 credits"
Flagship plans — Higgsfield €59/month for 1,200 credits · Kyncept $59/month for 1,200 credits · same price, half the images on Higgsfield
Images before the plan is empty — Higgsfield 600 · Kyncept 1,200 · 2×
300 images a month — Higgsfield 300 × 2 = 600 credits → its Starter's 270 credits cover only 135 images, so the cheapest plan that fits is Plus at €59/month · Kyncept 300 × 1 = 300 credits → Starter covers it at $19/month · 3.1×
Same request, per year — Higgsfield €59 × 12 = €708 · Kyncept $19 × 12 = $228 · €708 against $228
120 eight-second clips a month, same accounts — Higgsfield 120 × 20 = 2,400 credits → Ultra at €99/month · Kyncept 120 × 10 = 1,200 credits → exactly the $59 Pro plan · 2×

Higgsfield's pricing page: 1,200 credits = 600 Nano Banana Pro generations.

Higgsfield publishes the 2-credit rate itself, so the 2× is a design decision rather than a hidden multiplier — and a defensible one, just not one that makes the picture better.

Speed: the comparison I could not make this round

Speed is the easiest place to fake a finding, so I will be precise.

Kyncept image, run 1 — 59.9 seconds, click Generate to image on screen
Kyncept image, run 2 — 69.3 seconds, same prompt and settings
Higgsfield image — not measured

Two Higgsfield stopwatch readings failed, and one is why I trust the other: the timing matched a result from a previous run — it described a click I had not just made. A figure describing an older generation is worse than no figure, so both went out. There is no Higgsfield image speed in this review, and I am not calling the platform fast or slow — nothing measured it.

What the gap costs is smaller than it sounds: even instant rendering at 0 seconds cannot close a 3.1× plan gap, and at 300 images a month you would have to care a great deal about a minute to pay €59 against $19 for it.

Kyncept mid-run: GENERATING with a prompt summary, balance already down 1 credit.

The watermark baked into the file

Higgsfield's free-plan output carries a "HIGGSFIELD AI" mark in the bottom-right corner, and it is not a viewer overlay — it is in the PNG's pixels, confirmed on all 3 delivered files.

A close crop of the "HIGGSFIELD AI" watermark from the original PNG.

Watermarked files — Higgsfield 3 of 3 · Kyncept 0 of 2
Where the mark lives — Higgsfield: inside the PNG, bottom-right · Kyncept: nowhere on the files I downloaded
What it costs — 3 of 3 free-plan images need retouching before use, at 1376 × 768 where the mark sits over real content

One honest boundary: Kyncept was tested on a $59/month Pro plan and its free tier was not tested here. The accurate claim is that no watermark appeared on the 2 images that Pro plan returned.

File size: 1.5 MB of PNG against 0.8 MB of JPEG

Same model, same 1376 × 768 output, noticeably different file.

Higgsfield PNGs — 1,707,195 · 1,385,890 · 1,501,594 bytes · 1.5 MB average
Kyncept JPEGs — 855,668 · 772,181 bytes · 0.8 MB average
Per file — Higgsfield 1.5 MB · Kyncept 0.8 MB · about 1.9× heavier
300 images a month — Higgsfield ≈ 460 MB · Kyncept ≈ 240 MB · ≈ 215 MB more every month
Over a year — Higgsfield ≈ 5.5 GB · Kyncept ≈ 2.9 GB · 2.6 GB of extra transfer for the same pixels

Kyncept's delivered result — 1376 × 768 JPEG, no watermark, 0.8 MB.

Twice the bytes for the same dimensions costs real time if you download a batch on a phone connection — though it is the most forgivable difference here, since PNG is lossless and JPEG is not.

Free tier: a 1K cap and PREMIUM tags

A free Higgsfield account starts with 10 free credits. By the time I tested it the balance read 4.0, and that is the whole story of the free tier.

Resolution in the parameter panel — Higgsfield 1K · no higher step
Model list — Higgsfield tags entries PREMIUM · the unlocked ones sit under the locked ones
Cheapest video in the same catalog — 20 credits for 8 seconds at 720p · against a 4.0-credit balance
Catalog as advertised — 28 video models and 250+ camera presets · 0 usable on a free balance
Concurrent jobs — Higgsfield free 1 · Starter 2 · Plus 4 · Ultra 8

Higgsfield's editor on load: a long model list with PREMIUM entries, promo banner on top.

The feature table is good on paper — 8 concurrent jobs on Ultra, 28 video models, 250+ camera presets — and gated far enough up that a free account can browse the shelf and reach none of it. At 4.0 credits, the free tier is two Nano Banana Pro renders.

Upsell pressure around the result

Two pieces of promotional furniture followed me through every Higgsfield session.

A countdown banner — persistent across the top of the editing page, every visit
A discount card — "Get personal 55% OFF", floating over the lower-right of the editor, the corner the Generate flow occupies
The locked video model — a full-screen UPGRADE REQUIRED page instead of a toast
Kyncept's equivalent — 0 banners, 0 floating cards; the model page states its cost on the button

Higgsfield's generating state: a placeholder with no progress bar, promo banner still on top.

It is not only that there is pressure; it is where it is aimed — over the corner where the primary action lives, with a discount framed as personal. On a paid run it costs attention too.

UI flow side by side

Open — Higgsfield: one long model list, PREMIUM tags on the good entries, countdown banner above it all · Kyncept: one model per page, cost printed on the button
Parameters — Higgsfield: Nano Banana Pro, 16:9, 1K, Generate reads 2 credits · Kyncept: Nano Banana Pro, 16:9, original, ×1, Generate reads 1 credit
Generating — Higgsfield: a placeholder, no progress bar · Kyncept: a GENERATING card with a prompt summary, balance already down 1 credit
Result — Higgsfield: PNG, watermark bottom-right, 1.5 MB average · Kyncept: JPEG, clean, 0.8 MB average

Higgsfield's delivered result — 1376 × 768 PNG, 1.5 MB, watermark bottom-right.

Small structural difference, and it matters: Kyncept puts the price on the button that spends it, so the cost is visible before the action. Higgsfield does too — 2 credits, honest — then surrounds that button with a discount card and a countdown.

One paragraph on video, for context

A text-only video prompt, no start frame on either side, produced 2 of 2 clips on Kyncept at 10 credits each, 157.7 seconds on the stopwatch, 8.0 seconds at 1280 × 720 and 24 fps with real slicing audio. On Higgsfield it produced 0 clips: its cheapest text-to-video option, Seedance 2.0 Mini at 8 seconds and 720p, reads 20 credits against a 4.0-credit balance — 16 credits short.

What a free Higgsfield account gets instead of a clip: the UPGRADE REQUIRED wall.

Final verdict: Higgsfield scores 60/100 for this job

Sixty is not a bad score for the picture; the picture is a tie, and the model was never Higgsfield's to lose. Sixty is what the wrapper earns: 2 credits per image against 1, a 3.1× plan gap at 300 images a month, a watermark inside 3 of 3 free-plan PNGs, 1.5 MB against 0.8 MB at 1376 × 768, and a free balance that cannot reach any of the 28 video models it displays.

The good things on Higgsfield's side are real: a 1,600-character prompt field that took my 682 characters without blinking, 28 video models, 250+ camera presets, and 8 concurrent jobs on the top plan. Every one is a feature of the paid ladder, and the free rung holds 1 concurrent job and 4.0 credits.

Which one I would use for this job

For a recurring image job on a fixed budget, the identical model makes this easy: the platform that charges one credit, returns the file without a stamp in it, and hands back 0.8 MB instead of 1.5 MB is the one to run — at 300 images a month, $19 against €59, and no watermark to paint out of 300 files. If you want to repeat the test, kyncept.com runs it on a 1-credit image and the prompt above is printed to paste in unchanged.

Tripo GLB Review 2026: 61 MB and 4096\u00b2 Maps for One Candle Holder

Viktor Delgado — Sun, 18 Oct 2026 15:47:22 +0000

Disclosure: this is an independent hands-on test. Both tools were run on ordinary customer accounts; neither company supplied review access or saw this piece before publication.

My verdict in 60 seconds — Tripo 62/100, SupaVoxel 89/100

Same Halloween reference image, same night, same default settings, two image-to-3D products — and this article is about what actually arrives on your disk and in your browser. Tripo shipped 61,356,932 bytes: 1,932,883 triangles plus three 4096² texture maps totalling 6.09 MB, in a GLB with no compression extension at all. SupaVoxel shipped 5,281,064 bytes: 945,492 triangles plus three 2048² WebP maps totalling 395,148 B. That is 11.62×, and it is not a geometry gap — Tripo has only 2.04× the triangles, and across ten subjects measured the same day Tripo's triangle count barely moves at all. It is texture policy plus uncompressed buffers. On a 12 Mbps phone connection the Tripo candle holder is a 40.9-second wait against 3.5 seconds.

Here is the scorecard for this one job — putting the candle holder on a product page and letting people spin it.

File size — Tripo 2/10 (61.36 MB) · SupaVoxel 10/10 (5.28 MB) — 11.62×, for 2.04× the triangles
Bytes per triangle — Tripo 2/10 (31.74 B) · SupaVoxel 10/10 (5.59 B)
4G first load at 12 Mbps — Tripo 2/10 (40.9 s) · SupaVoxel 10/10 (3.5 s)
CDN bill at 10k loads/month — Tripo 2/10 ($52.15) · SupaVoxel 10/10 ($4.49)
Geometry VRAM — Tripo 4/10 (55.26 MB) · SupaVoxel 9/10 (27.24 MB)
Texture resolution for close-up render — Tripo 10/10 (three 4096² maps) · SupaVoxel 6/10 (three 2048²) — Tripo genuinely wins this row
Reader compatibility — Tripo 9/10 (no required extensions) · SupaVoxel 5/10 (meshopt + quantization both required) — Tripo wins this one too
Likeness to the reference — Tripo 8/10 (extra invented openings on the back) · SupaVoxel 9/10 (restrained back face)

What is actually heavy in the Tripo file, part by part: 3,993,984 B of it is metallicRoughness and normal maps that a printer never reads, including a single 4096² PNG normal map of 2,758,347 B — larger than SupaVoxel's entire model; the geometry buffers carry no compression extension, so every triangle costs 31.74 B against SupaVoxel's 5.59 B; and on the invented back face, which neither product could see in the input, Tripo added openings the SupaVoxel mesh does not have. For a spinnable product page, use SupaVoxel and keep the 56 MB.

The input, 1,520,356 bytes. It shows the front only: cup mouth, tall front ghost, flared base. Everything on the back of either model is invention, and the last sections of this article are about whose invention is more restrained.

The 11.62× gap is not geometry

Tripo delivers 1,932,883 triangles against 945,492 — 2.04×. Tripo delivers 61,356,932 bytes against 5,281,064 — 11.62×. Those two ratios do not match, and the space between them is the whole article.

There is a wider pattern behind the first of those two numbers. Across ten subjects generated the same day on the same settings — one input image each, both files parsed by the same script — Tripo's triangle count lands between 1,896,372 and 1,996,779, a spread of 5.2%, while SupaVoxel's runs from 945,492 to 2,786,054, a spread of 146%. This candle holder is the low end of the SupaVoxel range; the high end is an armoured-vehicle subject where SupaVoxel ships 2,786,054 triangles against Tripo's 1,931,963 — 44% more geometry than Tripo, in a file 4.1× smaller. Ten subjects is a small sample and I am reporting it as an observation, not a statistic, but the shape of it is hard to miss: Tripo spends roughly the same geometry budget on a candle holder as on a tank, and SupaVoxel's tracks what the subject actually needs. It is not that SupaVoxel is leaner — on the tank it is not.

Per triangle: Tripo spends 31.74 bytes, SupaVoxel spends 5.59. The difference comes from two decisions. Tripo's GLB lists KHR_materials_volume and FB_ngon_encoding, neither of which saves a byte. SupaVoxel's lists EXT_meshopt_compression and KHR_mesh_quantization, which take 19.69 MB of decoded geometry down to 5.28 MB on the wire — a 3.73× compression ratio on a file Tripo would have sent raw.

Three 4096² maps, two of which a printer never opens

Tripo's texture set, measured out of the GLB:

baseColor — 4096² JPEG, 2,098,606 B
metallicRoughness — 4096² JPEG, 1,235,637 B
normal — 4096² PNG, 2,758,347 B
Total — 6,092,590 B

SupaVoxel's:

baseColor — 2048² WebP, 240,534 B
metallicRoughness — 2048² WebP, 89,280 B
normal — 2048² WebP, 65,334 B
Total — 395,148 B

That is 15.4× on the texture set as a whole, 8.7× on baseColor, and 25.8× on the two maps a print job never reads. Tripo's normal map alone, 2,758,347 B, is over half the size of SupaVoxel's entire delivered model. And the export dialog that produces it defaults to Texture Resolution 4k Current with no hint that a candle holder headed for a printer will use none of it.

Texels, not just bytes

It is worth separating two things that the 15.4× ratio mixes together. A 4096² map carries four times the texels of a 2048² map over the same UV layout, so Tripo really is painting this candle holder at twice the linear texture density. That part is a genuine capability, and on a close-up render of the ghost faces you can see it.

The rest of the ratio is encoding. Tripo's baseColor is a JPEG at 2,098,606 B and its normal map is a PNG at 2,758,347 B — a lossless codec for a map nobody inspects pixel-for-pixel — while SupaVoxel's are WebP at 240,534 B and 65,334 B. Four times the texels does not cost 15.4× the bytes; the codec choice does the rest. A 4096² WebP normal map would have landed somewhere in between, and Tripo's export dialog offers no way to ask for one: the choice on offer is the resolution, not the encoding.

The Tripo export dialog: File Name, Format GLB, Texture Resolution 4k Current. Three fields, one of which quietly sets the file size at 61 MB.

The SupaVoxel result panel, for comparison: Triangles 945,492 — identical to the parsed file — and a Size readout of 0.49 / 1 / 0.47, which is normalised and has to be scaled before slicing.

40.9 seconds on a phone, 3.5 on the other

Convert the bytes into the only unit a visitor experiences:

12 Mbps mobile — Tripo 40.9 s · SupaVoxel 3.5 s
100 Mbps home — Tripo 4.91 s · SupaVoxel 0.42 s
Geometry VRAM (32 B/vertex + 4 B/index) — Tripo 55.26 MB · SupaVoxel 27.24 MB

Nobody waits 40.9 seconds for a candle holder to appear. The VRAM row is the quieter risk: 55.26 MB of geometry on a low-end phone is where the tab stops responding, and Tripo asks for 2.03× what SupaVoxel does to display an object 0.97% larger.

It is worth stressing that this is not a Tripo setting you can dial away at export time. The dialog exposes Format and Texture Resolution; it does not expose mesh decimation or buffer compression, so the 1,932,883 triangles and the uncompressed buffers come as they are. Dropping Tripo's texture resolution would take perhaps 6 MB off a 61 MB file — the geometry payload, at 31.74 bytes per triangle, is the part you cannot negotiate with.

The CDN bill: $52.15 a month against $4.49

At $0.085/GB and 10,000 loads a month, the Tripo file costs $52.15 in egress and the SupaVoxel file $4.49. That is $47.66 a month, $571.92 a year, to serve the same candle holder — and the ratio is exactly the file ratio, 11.62×, because egress is arithmetic.

If you host a catalogue rather than one object, multiply. A hundred Tripo models at those settings is 6.14 GB of downloads against 0.53 GB.

What the extra bytes do buy: the front surface

Time to be fair to Tripo, at the front of the model where the input actually gave both products something to copy.

Composition matches on both sides: the cup, the three large front ghosts, the eight or nine small ones around the base. Tripo's surface carries a finer vertical chiselling that SupaVoxel's does not — the visible face of a 0.2033 mm mean edge against 0.292 mm — and in a close-up material render that reads as more detail. It also bakes a grey striping into baseColor that makes the unpainted preview look slightly dirty, which is the flip side of the same choice.

SupaVoxel, front. Cup, three large ghosts, the base row — matched to the reference. The eyes read as through-holes, not dark spots.

Tripo, same camera. Same composition, finer vertical chiselling from 1.44× the mesh resolution, and grey striping baked into baseColor.

SupaVoxel from the side: one continuous ridge from base to cup, no stepping, two or three eyes on this flank.

Tripo from the side. Also continuous, with sharper separation between strands — that is what 2.04× the triangles looks like, at 11.62× the bytes.

The back face is invention on both sides, and Tripo invents more

The input photograph has no back. Whatever is behind this candle holder was made up by each product, so the question is not which one is right but which one adds less that nobody asked for.

SupaVoxel's back continues the same spiral and places one ghost at the upper right and one at mid-right, each with fewer eyes than the front. Tripo's back puts faces in the same places and gives each of them extra openings: the upper-right face goes from one round hole to two vertical slits, and the mid-right face gains an additional opening.

SupaVoxel's invented back: the spiral continues, two ghosts, sparse eyes. Nothing structurally new appears.

Tripo's invented back, same camera. Same positions, more openings.

Zoomed: on the SupaVoxel mesh the upper-left ghost has a single round hole and the mid-right one is also single — clean-edged, genuinely pierced.

Tripo at the same zoom: two vertical slits on the upper-left face, and an oval plus a bridged narrow slit on the mid-right one. Neither reading is wrong — there is no reference for this side — but Tripo is filling in more.

The cup, from above

The other place a product page gets judged is the top-down view, because it is where a buyer checks that the candle will actually sit.

SupaVoxel from above: rim, inner wall and floor as three concentric bands, with a shadow ring that shows real depth.

Tripo from above: the same three bands with a shallower step and a brighter floor. Both are recesses rather than bores, which is what keeps the wax in.

The compression that saves 56 MB has a price, and Tripo does not pay it

The honest cost of SupaVoxel's 5.28 MB: EXT_meshopt_compression and KHR_mesh_quantization are both listed in extensionsRequired, not merely used. three.js and the product's own viewer read it without complaint. trimesh cannot open it at all — it throws an IndexError in the glTF buffer reader — so an older toolchain has to run it through gltf-transform first, which inflates it to 19.69 MB.

Tripo's GLB has no required extensions. Any glTF reader written in the last decade opens it directly. If your pipeline ends at a tool with no meshopt decoder, that is a genuine reason to pick Tripo, and it is the second one in this article.

The delivery ledger

GLB bytes — Tripo 61,356,932 · SupaVoxel 5,281,064 · 11.62×
Triangles — Tripo 1,932,883 · SupaVoxel 945,492 · 2.04×
Bytes per triangle — Tripo 31.74 B · SupaVoxel 5.59 B
Texture set — Tripo 6,092,590 B (two JPEG + one PNG, all 4096²) · SupaVoxel 395,148 B (three WebP, all 2048²) · 15.4×
Maps a printer never reads — Tripo 3,993,984 B · SupaVoxel 154,614 B · 25.8×
4G first load — Tripo 40.9 s · SupaVoxel 3.5 s
CDN at 10k loads/month — Tripo $52.15 · SupaVoxel $4.49
Required extensions — Tripo none · SupaVoxel meshopt + quantization — Tripo wins

Final verdict: Tripo scores 62, and charges the visitor for it

Tripo's file is the better archive. Three 4096² maps, no required extensions, a finer mesh, and a front surface that carries more chiselled detail in a close-up render. If your endpoint is a DCC material pass or an old glTF reader, buy Tripo and stop reading.

If your endpoint is a browser, Tripo is charging your visitors for that archive. 61.36 MB against 5.28 MB. 40.9 seconds against 3.5 on a phone. $52.15 a month against $4.49 for the same 10,000 loads. 55.26 MB of geometry VRAM against 27.24 MB on devices that have little to spare. And 3,993,984 B of that payload is metallicRoughness and normal data that a print job discards on import — 65.6% of Tripo's texture bytes, defaulted to 4k in the export dialog with no warning.

SupaVoxel's costs are stated above and I will restate them: 2048² maps and no 4K option, a mesh 1.44× coarser, and a GLB that requires a meshopt decoder, which cost me a trimesh run in this very test.

Which one I would use for this job

For a spinnable candle holder on a product page, SupaVoxel is the file I would ship: 5.28 MB, 3.5 seconds on a phone, $4.49 per 10,000 loads, 27.24 MB of geometry VRAM, and the eye holes still reading as real openings at every camera in this article — including on the back face, which neither product had any reference for.

Tripo 3D Print Review 2026: 183 Boundary Edges in One Candle Holder

Viktor Delgado — Fri, 16 Oct 2026 15:50:08 +0000

Disclosure: this is an independent hands-on test. Both tools were run on ordinary customer accounts; neither company supplied review access or saw this piece before publication.

My verdict in 60 seconds — Tripo 60/100, SupaVoxel 90/100

I gave one Halloween reference image — a swirling candle holder with ghost faces bored into it — to Tripo and to SupaVoxel on the same night, exported GLB from both with default settings, and then measured both files offline the way a print shop measures: weld the vertices by position, then count shells, boundary edges, winding, overhang area and resin. A candle holder is a good test because it can fail in public. It either stands level and holds a candle, or it does not. Both files pass that test. Only one of them passes it without a repair session first: Tripo's mesh comes back with 183 boundary edges and inconsistent face winding, SupaVoxel's with zero boundary edges and consistent winding, for 3 credits instead of Tripo's 55.

Here is the scorecard for this one job — one reference image in, one 120 mm printable candle holder out.

Boundary edges after welding — Tripo 3/10 (183 holes to patch) · SupaVoxel 10/10 (0) — this row alone decides whether you open Blender
Face winding — Tripo 3/10 (inconsistent; some faces point inward) · SupaVoxel 10/10 (consistent)
Non-manifold edges — Tripo 9/10 (36) · SupaVoxel 5/10 (366) — Tripo genuinely wins this row
Mesh hygiene — Tripo 6/10 (1 degenerate, 235 sliver faces) · SupaVoxel 9/10 (0 and 22)
Support burden at 45° — Tripo 8/10 (4,405.2 mm², 15.99%) · SupaVoxel 7/10 (4,754.8 mm², 17.35%) — Tripo wins this row too
Usable precision at a 0.4 mm nozzle — Tripo 9/10 (0.2033 mm mean edge) · SupaVoxel 9/10 (0.292 mm) — both already finer than the nozzle
Functional geometry (holes, cup, base) — Tripo 9/10 (7 pierced eyes, cup is a recess) · SupaVoxel 10/10 (8 pierced eyes, 24.59 mm deep bores)
Cost of one printable file — Tripo 2/10 (55 credits, 61.36 MB) · SupaVoxel 10/10 (3 credits, 5.28 MB)

What is actually wrong with the Tripo file, part by part: after welding it still has 183 boundary edges, so a slicer does not read it as a solid; its winding is inconsistent, so part of the surface faces inward and you have to recalculate normals as a second, separate pass; it ships 45 disconnected shells with an Euler characteristic of −106; and it spends 55 credits and 61.36 MB to deliver 78.05 cm³ of object where SupaVoxel delivers 77.29 cm³ — a 0.97% difference, two cents of resin. For this job I would generate on SupaVoxel and spend the saved hour on the print instead of on the repair.

The only input: one 1,520,356-byte PNG (sha256 8781d5ae…), fed unretouched to both products. Note that it shows the front only — the cup mouth, the tall front ghost, the flared base. Nothing behind.

Weld first, or every number is about UV seams

A candle holder has to stand level, hold a candle, and keep the wax out of the base — yes/no questions a render cannot answer. So I parsed both GLBs offline with pygltflib and trimesh; nothing here is copied out of Tripo's result panel, although Tripo's panel is honest, reporting Faces 1932883 / Vertices 1002116 against a file containing exactly that.

Raw, both exports split vertices along texture seams: Tripo 70,415 boundary edges, SupaVoxel 47,540. Those describe UV islands, not geometry. Every slicer welds by position on import, so the honest measurement comes after a merge — Tripo 1,002,116 file vertices down to 966,409, SupaVoxel 496,784 down to 472,554. Tripo needs 2.05× the welded vertices and 2.04× the triangles (1,932,883 against 945,492) to describe the same candle holder.

After welding, Tripo has 183 holes

Boundary edges — Tripo 183 · SupaVoxel 0
Winding consistent — Tripo false · SupaVoxel true
Connected components — Tripo 45 · SupaVoxel 245
Euler characteristic — Tripo −106 · SupaVoxel +174
Watertight — Tripo no · SupaVoxel no

Neither file is watertight, and I am not going to pretend otherwise. They are unwatertight in two different ways, and the difference is the number of manual passes before slicing. Tripo's file leaks: 183 boundary edges are 183 edges belonging to exactly one triangle — actual gaps — and the inconsistent winding adds a recalculate-normals pass on top of the patch. Two operations, in order, on every copy. The SupaVoxel file has no gaps and no inverted faces; it has 366 non-manifold edges and 245 loose shells, which one merge-and-clean pass resolves. Tripo charged 55 credits for the file that needs two passes.

Where Tripo genuinely wins: 36 non-manifold edges against 366

This is the row I would be embarrassed to bury. Tripo's welded mesh has 36 non-manifold edges; SupaVoxel's has 366, ten times more. Non-manifold edges are edges shared by three or more faces, and a slicer meeting one has to guess which side is the inside.

It is a real defect in the SupaVoxel file and I would not print either mesh without a cleanup. The trade ratio is what makes it survivable: those 330 extra non-manifold edges replace 183 boundary-edge patches plus a full normals flip, and they cost 3 credits instead of 55 — one cleanup pass against two repair passes, at 18.3× less credit. The row next to it goes the other way: sliver faces, the long thin triangles that produce self-intersecting toolpaths, run 235 on Tripo against 22 on SupaVoxel, and Tripo also ships the one degenerate zero-area face in this test.

SupaVoxel with textures off — 945,492 triangles. Every ghost eye is still a black opening here, which is the point of this render: the holes are geometry, not paint.

Tripo, same camera, textures off — 1,932,883 triangles. Its eyes are real openings too. The surface carries more fine creasing, which is what 0.2033 mm mean edge length looks like.

The eyes are drilled, not painted — on both sides

The cheap failure mode for a face like this is a dark patch in the base-colour map over solid geometry. Neither file did that. The pierce test — a parallel ray grid at 0.25 mm per pixel, four horizontal viewpoints, counting only miss-islands completely enclosed by hits — finds up to 7 genuinely see-through openings in one Tripo view, largest 14.94 mm², against 8 in the SupaVoxel file, largest 11.62 mm². Both counts are lower bounds, since an eye whose bore axis is off-camera reads as blind. Tripo deserves the credit here: the ghost faces are the whole point of this model and Tripo did not fake them.

Neither is a hollow vessel, and that is good news for wax

The second thing a candle holder can fake is thickness. Neither Tripo nor SupaVoxel did. Interior grid sampling puts 42% of interior points inside the mesh on both sides — 0.423 Tripo, 0.424 SupaVoxel — and horizontal rays cross 2 to 4 surfaces: solid swirl strands with air between them, not a shell. You are printing a solid object either way, which is why the resin figures below land within two cents of each other.

SupaVoxel from directly above: outer rim, inner wall, cup floor — three concentric bands, and a shadow ring that proves the cup has depth.

Tripo from the same camera. Same three bands, a shallower step and a brighter, flatter floor. What matters is the thing both got right — it is a recess, not a bore.

The cup is a dimple on both sides, so the wax stays in

This is the functional test the object exists for. If the cup were a through-hole, molten wax would run down the swirl and out of the base. Horizontal rays through the cup region hit solid strand on both files: a recess in Tripo's mesh, a recess in SupaVoxel's. Tripo passes. The difference is only how far each commits to its holes — deepest front-face concavity at 120 mm scale is 24.59 mm in the SupaVoxel file against Tripo's 14.26 mm, so Tripo's eyes are closer to a surface scoop and SupaVoxel's are bored 1.72× deeper.

SupaVoxel, three-quarter hero view. Level cup, base skirt spread wide enough to hold the centre of mass. 24.59 mm at the deepest eye bore.

Tripo, same camera and same lighting rig. Nearly the same composition; the deepest eye bore is 14.26 mm, 0.58× of SupaVoxel's.

Support: SupaVoxel costs 7.9% more, and here is what it buys

The row SupaVoxel loses. Counting surface whose normals point more than 45° downward, scaled to 120 mm: Tripo needs support on 4,405.2 mm² (15.99%), SupaVoxel on 4,754.8 mm² (17.35%) — 349.6 mm² more contact, about 7.9% more scar to clean off every copy. The cause is the deeper bores above: a 24.59 mm cavity has more downward-facing wall than a 14.26 mm scoop. You sand 7.9% more support and keep holes that are see-through from more angles. Support comes off; hole depth stays.

The 1.44× resolution advantage is worth exactly nothing at 0.4 mm

Tripo's mean triangle edge at 120 mm is 0.2033 mm; SupaVoxel's is 0.292 mm. Tripo is 1.44× finer, and that is a real measurement I am not going to argue with.

Now convert it into the unit that makes the object. A common FDM nozzle is 0.4 mm. Tripo's mean edge is 0.51× of the nozzle width, SupaVoxel's 0.73×: both are already below the tool that will print them, so the slicer merges those triangles into the same extrusion path either way. The 1.44× lands under the floor, and on the way there it costs 18.3× the credits, 11.62× the file (61.36 MB against 5.28 MB) and 2.03× the geometry VRAM (55.26 MB against 27.24 MB). Move to SLA and Tripo wins this row for real; on a 0.4 mm nozzle it is a real number that buys nothing physical.

SupaVoxel wireframe at the detail zoom. Dense enough to read almost black — a 13.1 KB PNG — with a few white gaps still open at 0.292 mm spacing.

Tripo at the same zoom: blacker, and the PNG is smaller (9.0 KB) because uniform black compresses better. This is the honest face of 2.04× the triangles — to the eye, "darker".

Resin and volume: the same object, two cents apart

Scaled to 120 mm tall, Tripo's bounding box is 56.78 × 120.0 × 60.33 mm and SupaVoxel's 59.24 × 120.0 × 56.33 mm. Volume 78.05 cm³ against 77.29 cm³; resin at $35/L $2.73 against $2.71. Tripo charged 18.3× the credits and delivered 0.97% more object: the extra 52 credits did not become one additional millilitre of material.

The switch that would fix Tripo's topology is rationed

Tripo has a feature aimed exactly at the 183 boundary edges: Clean Topology. On the generation bar it carries a Trial ×2 badge, and it is off by default, which is how I submitted this run — Best Quality, everything else at Tripo's own defaults, because identical defaults on both sides is what makes a comparison fair.

So the 183 boundary edges and the inconsistent winding are not an unlucky draw. They are what Tripo's default tier produces, and the fix is metered at two uses.

Tripo Studio before upload: Clean Topology with its Trial ×2 badge, Best Quality selected, and a Generate button that does not yet show a price.

Two popups stand between the finished model and the export button

Once the Tripo job finishes, the path to a file runs through a View Your Model overlay covering half the viewport, then a five-video Guide dialog, with a Humanoid Rigging & Text2Motion promo bar pinned across the top throughout. Export sits in the bottom bar behind both, and its dialog defaults to Texture Resolution 4k Current — two steps to a file, and nothing in the flow mentions that 4k maps are useless to a printer. On the SupaVoxel side the inspection modes and Export share one screen with nothing to dismiss.

Tripo after the first dismissal: the Guide dialog with five videos, sitting on top of the Export button in the bottom bar.

The Tripo export panel is already open at the lower right — and the Guide dialog is still stacked over it, hiding the fields. This frame is the evidence for "subtract two dialogs before you can export".

Finally readable: File Name, Format GLB, Texture Resolution 4k Current. That default is where the 61.36 MB comes from.

SupaVoxel's result screen: four inspection modes across the viewport and Export in the same top bar. Mesh mode is what produced the untextured render earlier in this article.

The print-shop ledger

Everything above, as the list of what you still owe after the file lands:

Sliceable as delivered — Tripo no (183 boundary edges + inconsistent winding) · SupaVoxel no (366 non-manifold edges)
Repair passes per copy — Tripo 2 (patch holes, recalculate normals) · SupaVoxel 1 (merge and clean)
Support area at 45° — Tripo 4,405.2 mm² · SupaVoxel 4,754.8 mm² — Tripo wins
Sliver faces — Tripo 235 · SupaVoxel 22
Mean edge at 120 mm — Tripo 0.2033 mm (0.51× nozzle) · SupaVoxel 0.292 mm (0.73× nozzle) — both below 0.4 mm
Pierced eyes, best single view — Tripo 7 (max 14.94 mm²) · SupaVoxel 8 (max 11.62 mm²)
Volume and resin at $35/L — Tripo 78.05 cm³ / $2.73 · SupaVoxel 77.29 cm³ / $2.71
Credits for the generation — Tripo 55 · SupaVoxel 3

Three of those rows go to Tripo. None of the three changes what comes off the printer.

Final verdict: Tripo scores 60, and hands you two repair passes

Tripo Studio built a genuinely good candle holder: the ghost eyes are drilled through, the swirl is continuous from base to cup, the base is solid, the cup is a wax-tight recess, the mesh has ten times fewer non-manifold edges than SupaVoxel's, and it needs 349.6 mm² less support. Then Tripo charges 55 credits for it, ships it as 61.36 MB, and leaves 183 boundary edges plus an inconsistent winding — two repair passes before a slicer accepts it, on every copy — while the switch that would prevent that is badged Trial ×2. Its headline advantage, a 1.44× finer mesh, lands under a 0.4 mm nozzle. Its volume advantage is 0.76 cm³, or two cents of resin.

SupaVoxel's faults are in this article too: 366 non-manifold edges, 245 loose shells, 7.9% more support area, a mesh 1.44× coarser than Tripo's, and a unitless output — the panel reads 0.49 × 1 × 0.47 with Y at exactly 1 — so you set the target height yourself.

Which one I would use for this job

If the job is "one reference image in, one printable 120 mm candle holder out", SupaVoxel is the file I would hand a print shop: 3 credits, zero boundary edges, consistent winding, 22 sliver faces, eye holes bored 24.59 mm deep, 5.28 MB to download, and four inspection modes on the same screen as the export control — so you can confirm the holes are geometry before you spend anything downstream.

Meshy AI Review 2026: 35 Credits and 11.60 MB for One Wrench

Viktor Delgado — Wed, 14 Oct 2026 15:46:08 +0000

Disclosure: this is an independent hands-on test. Both tools were run on ordinary customer accounts; neither company supplied review access or saw this piece before publication.

A wrench. One photo of it. And a product page that needed a 3D version by Friday.

That was the whole job.

I asked around for the best way to turn a photo into a 3D model, and two names kept coming back: Meshy and SupaVoxel. So I ran the same picture through both, wrote down what each one charged on its own meter, and weighed what came back.

This article is the receipt.

My verdict in 60 seconds — Meshy 58/100, SupaVoxel 90/100

Those scores are my opinion about this one job. The numbers under them came out of the task records and the files.

What you download — Meshy 11,603,384 bytes vs SupaVoxel 8,842,180 bytes · Meshy 6/10 · SupaVoxel 9/10 — Meshy adds 2.76 MB to every single visit; SupaVoxel delivers the same wrench in a lighter file, so your bandwidth bill and your visitor both get off cheaper
Waiting on a 12 Mbps phone — Meshy 7.7 s vs SupaVoxel 5.9 s · Meshy 6/10 · SupaVoxel 9/10 — Meshy makes a mobile visitor sit through nearly two extra seconds of nothing; SupaVoxel gets the model on screen sooner
Waiting on a 100 Mbps desk line — Meshy 0.93 s vs SupaVoxel 0.71 s · Meshy 8/10 · SupaVoxel 9/10 — Meshy is still the slower file, but on fibre the 0.22 s gap is one nobody will notice
A hundred of these on disk — Meshy 1.16 GB vs SupaVoxel 0.88 GB · Meshy 6/10 · SupaVoxel 9/10 — Meshy quietly adds 0.28 GB per hundred products to a bill you pay monthly; SupaVoxel's catalogue is smaller from day one
Deliverables you walk away with — Meshy 1 GLB vs SupaVoxel 2 GLBs · Meshy 7/10 · SupaVoxel 9/10 — this Meshy run left me one 11,603,384-byte file; SupaVoxel's menu had a compressed 8,842,180-byte GLB and a full 68,718,876-byte original-size GLB ready at the same time
Does the tool tell you how long it took? — Meshy not recorded vs SupaVoxel 215.462 s · Meshy 6/10 · SupaVoxel 9/10 — Meshy leaves the field empty, which is exactly the number you want when a batch job stalls; SupaVoxel writes it down
What the meters recorded — Meshy 35 credits vs SupaVoxel 3 credits · Meshy 8/10 · SupaVoxel 8/10 — a forced tie, and deliberately so: two different plans in two different units, so neither tool can win this row and nobody should tell you otherwise
Retries needed — Meshy 0 vs SupaVoxel 0 · Meshy 8/10 · SupaVoxel 8/10 — level, and both deserve it: neither tool needed a second attempt at this wrench

Four things that cost you something, in order:

Meshy hands you the heavier file. 2,761,204 bytes heavier, for the same wrench, from the same photo.
Meshy's record has no generation time in it. SupaVoxel's says 215.462 s. I'm not filling in a blank with a guess, so there's no speed contest in this article.
Neither tool recorded a failure count, so nobody gets to claim reliability here — not Meshy, not SupaVoxel.
Meshy's meter moved 35 for this wrench and SupaVoxel's moved 3. Two different plans, two different units. I'm not turning that into dollars, because you can't.

For one wrench on a page that has to load fast, SupaVoxel is the one I'd run it through — the file above came out of https://supavoxel.com and it's the lighter one on every page it lands on.

One image, one run on each side. Not a lab study.

So what does one wrench actually cost you?

The whole input: one photo of a brushed-steel adjustable wrench. No text prompt on either side.

Meshy's meter moved 35 credits for this. SupaVoxel's moved 3.

Now here's the part most reviews get wrong. Those two numbers are not comparable. Different plans, different units, different things being counted. Dividing one by the other gives you a number that means nothing.

What they do tell you is that each tool bills this job on a scale of its own, and you have to do your own plan maths before you commit to a hundred of them.

Anybody who tells you Meshy is "cheaper" or "pricier" than the other one is doing arithmetic on two different currencies.

Which file is lighter on your page?

Meshy's finished wrench — the view that ends up on the page. This is the 11.60 MB file.

The SupaVoxel version at the same camera. 8.84 MB.

This is the cleanest number in the whole comparison, because nobody has to interpret it.

Meshy: 11,603,384 bytes. SupaVoxel: 8,842,180 bytes.

That's 2.76 MB extra, every time somebody opens your page. On a 12 Mbps phone connection it's 7.7 seconds of waiting with Meshy against 5.9.

Two seconds. Which sounds like nothing, until you remember it lands right at the moment a visitor decides whether your page is worth the wait.

Both files are GLB — one file with the shape and the textures packed inside. Same format, same three textures. Meshy just made it bigger.

What a hundred of these do to your storage

Meshy's wrench with the lighting switched off, so you see the raw texture colour rather than reflections.

The same unlit view of the SupaVoxel file. Both read grey-silver — the dark look in the other shots is the lighting, not a Meshy texture fault.

One wrench is a rounding error. A catalogue isn't.

Copy this one Meshy output a hundred times and you're holding 1.16 GB of disk. The same hundred from SupaVoxel is 0.88 GB. That's 0.28 GB of Meshy overhead per hundred products, sitting in your bucket, billed monthly, forever.

Now scale that to the number of SKUs you actually have.

And no, you can't compress your way out of it later — whatever Meshy wrote into that file is what you're storing.

The per-file difference is invisible. The per-catalogue difference is a line on an invoice.

One tool tells you how long it took. The other doesn't.

The SupaVoxel result screen. The job is on the record at 215.462 seconds.

Meshy's finished result, ready to export.

SupaVoxel's record says 215.462 seconds, start to finish, download not included. Call it three and a half minutes — about one coffee.

Meshy's record says nothing at all.

So I can't tell you which one is faster, and I'm not going to pretend otherwise. But there's a smaller point hiding in that blank: when you're running fifty of these and one of them stalls, the tool that writes down how long things take is the tool you can actually debug.

A missing number isn't a slow number. It's just a number you don't have.

The upload takes ten seconds. The choice doesn't.

Dropping the photo into Meshy.

The same photo going into SupaVoxel.

Both uploads are boring, which is how it should be. Drag the picture into Meshy, wait. Drag the same picture into the other one, wait.

Nothing to separate them here, and Meshy deserves the credit for that: the part most people worry about is the part Meshy and SupaVoxel both get right.

The whole trip is short on both sides. Drop the photo in, tick the texture option, start the job, wait for the result screen, open the export menu, pick GLB, download. Four screens on Meshy, four on SupaVoxel — upload, settings, result, export — and the screenshots through this article are exactly those four, on each side, in order.

So if you're picking between Meshy and the other one hoping one of them saves you a pile of clicking: they don't. The difference isn't in the workflow. It's in what lands in your downloads folder at the end of it.

I want to be straight about something here: I didn't go hunting for a lighter Meshy configuration to make Meshy look worse. I left Meshy on what its interface put in front of me, which is what you'd do too.

So 35 is what Meshy's meter recorded for this wrench on these settings. It isn't Meshy's floor and it isn't Meshy's ceiling — and it still isn't comparable to the 3 on the other meter, because they're different plans and different units.

The settings screen is where your credits go

Meshy's settings with texture switched on — Flagship model, High Detail, Ultra 2K.

SupaVoxel's settings: 5 steps, guidance 5.5, background removal on, octree 256.

Two different control panels, so these are not equivalent settings and I won't pretend they are. They're what each tool handed me.

Here's what those two panels produced, though, and this part you can compare: Meshy returned 199,434 triangles — the little flat plates a model is built from — against 1,500,000 from SupaVoxel.

So Meshy's meter moved 35 and delivered roughly a seventh of the surface detail, in a file 2.76 MB bigger. (Still two different plans in two different units — that 35 isn't a price against the other meter's 3.)

That's the sentence that decided this article for me.

The full line-by-line, both sides

Here's every number this job produced. No table — they collapse into soup on this platform — so it's a list.

Credits recorded. Meshy 35, SupaVoxel 3. Different plans, different units, not a price ratio. Say it with me one more time.

Run time recorded. Meshy: blank. SupaVoxel: 215.462 seconds. You can't compare a number to a blank, so I don't.

Retries. Zero on Meshy, zero on SupaVoxel. Meshy nailed this wrench first go, and so did the other one — worth something when you're planning a batch of fifty.

Failures. Not recorded on either side. Which means if you're choosing Meshy or SupaVoxel on reliability, this run gives you nothing, and anyone telling you otherwise is guessing.

Triangles. Meshy 199,434, SupaVoxel 1,500,000. Roughly a seventh of the surface detail from the tool whose meter moved more.

Vertices. Meshy 111,498, SupaVoxel 816,916. Same shape of gap.

Textures inside the file. Three on Meshy, three on SupaVoxel. A tie, and a useful one — it means the size difference isn't "one of them skipped a texture".

Download size. Meshy 11,603,384 bytes, SupaVoxel 8,842,180 bytes.

Format. Both GLB. Nobody has to convert anything before they can open it.

Required extensions. Meshy none. SupaVoxel needs EXT_meshopt_compression and KHR_mesh_quantization — more on that in a second.

The other export. SupaVoxel also offers this wrench at original size: 68,718,876 bytes with no special requirements, textures as PNG instead of the compressed build's WebP. Meshy wasn't run in a second export mode, so that side is blank too.

Three blanks in that list. None of them get filled in with a guess.

The sums, and exactly how I did them

Every "seconds" and "GB" in this article is arithmetic on the numbers above. None of it is a stopwatch. Here's the working, so you can redo it with your own assumptions.

Phone wait: bytes × 8 ÷ 12,000,000. Meshy 7.7 s, SupaVoxel 5.9 s. Assumes a steady 12 Mbps and ignores handshakes, decoding and caching — so treat it as the transfer floor, not the real-world number.

Desk wait: the same sum at 100 Mbps. Meshy 0.93 s, SupaVoxel 0.71 s.

Storage for a hundred: this file × 100. Meshy 1.16 GB, SupaVoxel 0.88 GB.

A hundred runs on each meter: 3,500 on Meshy, 300 on SupaVoxel — each in its own units, still not a price ratio, and it assumes every job bills exactly like this one with no retries.

Memory the geometry wants: 32 bytes per vertex plus 4 bytes per triangle index, textures excluded. Meshy 6.0 MB, SupaVoxel 44.1 MB. This is where Meshy comes out ahead by 38.1 MB, and on a cheap phone loading several products at once that's the number that actually decides things.

If your figures come out different, it's your assumptions that changed — the files are the files.

Two finished files for the price of one job

SupaVoxel's export menu once the wrench was done: a compressed 8,842,180-byte GLB and a full original-size 68,718,876-byte GLB, both from the same run.

Here's the line item nobody puts on a pricing page.

One job on the meter, two deliverables in the folder. The compressed 8,842,180-byte GLB is the one your product page ships — it's the file behind every download figure in this article. The original-size export is the complete, unsqueezed version at 68,718,876 bytes, textures stored as PNG instead of the compressed build's WebP. It's larger because nothing has been compressed out of it; that's the whole point of it.

Which matters the moment the same asset has two jobs. The page wants light. The engineer who asks for "the actual model" wants complete. You hand out one of each and you never went back to the start screen.

No second run, no second job on the meter, no hunting for a converter. Both files were already there.

Where Meshy actually wins

Meshy's export panel. The GLB that comes out of it declares no required extensions at all.

Now the rows where Meshy beats SupaVoxel outright, stated at full strength.

Meshy's file opens anywhere. The compressed SupaVoxel GLB is squeezed with a scheme called meshopt, and your 3D software has to understand meshopt before it will open that particular file. Meshy's requires none of that. Switch to SupaVoxel's original-size export from the same menu and the decoder isn't needed there either — but Meshy gets you the no-requirements file at 11.60 MB, and that's a real advantage on an old importer.

One caveat on this row, because it matters: I read those requirements out of the files themselves. I didn't import either one into a specific application, so this is "what the file says it needs", not a test of what opened.

The second Meshy win is memory: 6.0 MB of geometry against 44.1 MB, arithmetic from the vertex and triangle counts, not a reading off a device. On a cheap phone loading several products at once, that 38.1 MB gap is the row that decides whether the page survives.

So: if your software might choke, or your customers are on low-end phones, take Meshy and stop reading. A lighter download is worth nothing if the file won't open or the page falls over.

So which one would I run it through?

For a wrench on a product page — lighter file, faster on a phone, less disk at scale, and a run time you can actually read — SupaVoxel.

For a wrench that has to land in software you don't control — Meshy, because compatibility beats megabytes every time it comes up.

And on cost: I genuinely can't tell you which one takes less money out of your account. 35 credits and 3 credits are two different plans in two different units. Check your own pricing page against your own volume. That part nobody can do for you.

Try it on your own photo

Run the product shot you actually need — not a wrench, yours — through https://supavoxel.com and through Meshy on the same afternoon. Then look at three things: what each meter moved, what each file weighs, and how long each one made you wait.

Twenty minutes of that will tell you more than any review, this one included.

How I tested this

One photo of an adjustable wrench, uploaded to both tools in the same session, no text prompt either side. Meshy ran at 02:38:02Z on its 7.1 Flagship model, High Detail, Ultra 2K, texture and image enhancement on. SupaVoxel ran at 03:29:36Z at 5 steps, guidance 5.5, background removal on, octree 256. Each tool on its own defaults, one run apiece.

Credits, retries and run time come from each tool's own task record. File sizes, triangle counts, texture counts and extension requirements were read out of the two downloaded files.

The waiting times are arithmetic, not stopwatch readings: file size × 8 ÷ 12,000,000 for the phone figure, ÷ 100,000,000 for the desk figure, assuming a steady connection and ignoring decoding, caching and page rendering. The storage and hundred-run figures are this one result multiplied by 100 — a capacity estimate, not a hundred real runs, and it assumes every job bills exactly like this one with no retries.

Neither tool recorded a failure count, and Meshy's run time wasn't recorded at all. Both blanks stay blank.

Hyper3D Rodin Review 2026: 0.5 Credit Spent, Download Blocked

Viktor Delgado — Mon, 12 Oct 2026 15:56:11 +0000

Independent review: both products were tested on my own accounts — free where offered and paid where not — with no vendor-provided access.

I opened Hyper3D with a picture of a small seated winged figure and a simple requirement: leave with a textured model I could inspect in my own software. I watched a Gen-2.5 preview appear, confirmed the geometry and pressed Download. That is where the experiment changed. The file would not leave a Free account without a subscription. So I ran the same image through a separate Gen-1.5 path, then through SupaVoxel, and kept each debit attached to its own job.

My verdict in 60 seconds — for a first-time user seeking a textured digital download, I would take the measured SupaVoxel export over Hyper3D’s initially gated Gen-2.5 preview. That is a judgment about this recorded route, not about the cash value of different credits. Hyper3D's Gen-2.5 spent 0.5 Hyper3D credit for an inaccessible export, then Gen-1.5 spent a separate 0.5 credit on geometry confirmation before yielding a textured PBR member in a ZIP. SupaVoxel used one matched 3-SupaVoxel-credit transaction and delivered an actual Original size GLB. If the job is an unmodified print starting mesh, I would instead take Hyper3D's Gen-1.5 solid shell; its print win is real and separate from this access verdict. SupaVoxel is the direct export route I would start with when a digital delivery, not a subscription-gated preview, is my immediate brief.

My eight-line decision card is about transaction and delivery clarity. The values are the observed evidence, and each line gives the consequence for this particular job:

First preview to file — Hyper3D Gen-2.5 blocked vs SupaVoxel completed — an apparently finished preview did not grant a Hyper3D Free-tier file.
Charge attributable to that first job — isolated 0.5 Hyper3D credit vs matched 3 SupaVoxel credits — not a price ranking.
Alternative route — another Hyper3D Gen-1.5 generation required vs no version switch in SupaVoxel — two attempts are not one product.
Geometry confirmation — Hyper3D Gen-1.5 deducted 0.5; SupaVoxel's one request debited 3 — unrelated currency units.
Material debit — Hyper3D Generate 0 and Confirm 0 more in this case vs one SupaVoxel transaction already recorded — no invented surcharge.
Textured delivery — ZIP containing PBR and Shaded GLBs vs single Original size GLB — both delivered, but only one arrived as the selected standalone file.
Working print shell — Gen-1.5 welded watertight vs SupaVoxel 471 nonmanifold edges — Hyper3D's genuine counterweight.
Rear-view digital detail — connected white back wings vs raised, separate feather tiers — SupaVoxel earns its digital preference.

A cash-cost ranking would require a dollar exchange rate and plan conditions I did not measure. A print-shop decision instead hinges on the welded-shell row.

Why did I photograph the balance before making anything?

The Free-account Gen-2.5 studio showed a 0.5-credit tariff and a 3.0-credit balance before this generation.

The isolated account moved 3.0→2.5 across Gen-2.5 generation and remained at 2.5 through confirmation and refused download. That proves a 0.5-credit debit for this run, not an independently parsed million-face file. The same 1,650,798-byte PNG went into both products; their internal processing differed. Publication/reuse rights to this reference-influenced source have not been cleared.

What did the Gen-2.5 preview actually buy?

Sword, shield and wings appeared in a completed Hyper3D Gen-2.5 viewer; no Gen-2.5 GLB was obtained for file analysis.

This looked finished. Geometry Confirm took 24.940 seconds without another debit. The panel claimed one million faces and 676,844 vertices; neither topology nor print badges could be verified without an export. Gen-2.5 preview-generation time was not captured—the “about 40 seconds” estimate was not a measurement. “I can orbit it” proved different from “I own the file.”

Where was the paywall hiding?

After geometry Confirm, Pack Download appeared available; the unchanged 2.5 balance did not establish download entitlement.

The final Download action said: “Subscribe to download Rodin Gen-2.5 models. Gen-1.5 downloads stay free!”

The second screen is the decision, not the first. I selected GLB, pressed the real Download control and got an explicit subscription boundary. I did not fetch internal preview resources to manufacture a supposed file. The Gen-2.5 path produced zero legitimately downloaded GLBs after one verified 0.5-credit debit on this Free account. That does not prove all plans deny downloads, and I did not measure the subscription price or licensing. It proves the specific access flow I tried. An enabled-looking button after a paid-in-credits generation is no substitute for an actual exported file. For a workshop with a deadline, that difference is bigger than any polygon-count headline.

Was Gen-1.5 a retry of the same result?

Hyper3D Gen-1.5 Detail started a different task from the same source image, rather than unlocking the old million-face preview.

No. It used a different model generation and Detail configuration. The Gen-1.5 preview itself cost zero verified additional credits and lasted 25.064 seconds. After a browser interruption, I recovered that existing preview from Mine history, not a new generation. Roughly nine hours of operator/browser downtime between preview and later confirmation are not nine hours of vendor processing. I mention that because a naive wall-clock subtraction would punish the wrong party. A buyer starting in Gen-1.5 from the outset would not incur the Gen-2.5 detour I did. Conversely, pretending the recovered 120,000-face PBR member was an unlocked version of the Gen-2.5 million-face preview would describe a product that never existed in my downloads.

When did the accessible model cost another credit?

Gen-1.5 Triangular/Simplify geometry confirmation took 14.299 seconds and changed this account's balance from 2.5 to 2.0.

The free preview was not the charge. Geometry Confirm was: 0.5 Hyper3D credit on the second run. Its first downloadable GLB was 5,092,448 bytes, with UV coordinates but no embedded texture images. The measured preview plus Confirm phases sum to 39.363 seconds. They exclude material processing, image upload, operator actions and downloading, so I will not call Hyper3D a “39-second complete PBR generator.” This is a useful bit of accounting for anyone testing several poses: if you only need to examine previews, the observed Gen-1.5 preview had no debit; taking a result through geometry confirmation did. Whether another account or future plan has the same behavior was not tested.

Did the material steps really charge extra?

Material Generate was a separate action. The checked balance stayed at 2.0 during this step in the recorded case.

Material Confirm also left the checked balance unchanged at 2.0; the PBR path then became selectable.

No extra debit in this case. Both Generate and Confirm were separately checked at 2.0→2.0. It would be dishonest to label the finished Gen-1.5 PBR model “geometry 0.5 plus an unknown material charge” once those checks exist. It would be equally dishonest to promote a one-account result into a permanent pricing promise. These two material actions did take workflow steps whose complete timings were not measured. The actual Gen-1.5 file I compare has three embedded 2048 × 2048 PNG maps; the earlier 5.09 MB geometry-only download does not. A textured-vs-textureless size comparison may flatter one tool, but it would tell a producer absolutely nothing about two finished colored assets.

What arrived when I finally clicked Download?

The successful Gen-1.5 handoff chose GLB with Shaded and PBR at 2K, then delivered a two-variant ZIP.

The actual browser transfer was 24,544,968 bytes. I extracted the 15,247,868-byte PBR GLB for the visual and geometric comparisons. Those two figures answer two different questions: how much the Hyper3D page transferred and how large one independently hosted textured model would be. The post-geometry route required Material Generate, Material Confirm, GLB selection and Download, four recorded interface actions, plus extracting the PBR member. Hyper3D thus does provide a legitimately downloadable full-material file from Gen-1.5; my complaint is the detour and the misleading intuition that the earlier Gen-2.5 preview was already mine. The full PBR ledger for this specific Gen-1.5 run is 0.5 credit at geometry Confirm and zero extra at both material stages.

What did SupaVoxel actually charge and export?

SupaVoxel showed Generate (3 credits) for the single Main image; extra angle slots were empty in this run.

The completed request's result panel showed 946,166 triangles; parsing the downloaded GLB confirmed that count.

The uploaded image bytes matched one successful request and its linked 3-SupaVoxel-credit transaction. Its database lifecycle was 193.746 seconds including queue, excluding upload and export. The transaction, rather than a shared account's later balance, ties the debit to this case. Those credits are not priced against Hyper3D's, and this lifecycle is not comparable to Hyper3D's 39.363 seconds of selected phases.

Did the export-menu choice matter?

Export → GLB → Original size was the tested three-action route; the menu also offered Compressed, which this case did not measure.

The browser delivered a 36,589,892-byte Original size GLB with three 2048² PNG maps; that UI label does not prove lossless source fidelity. File parsing confirms 946,166 triangles. At hypothetical ideal 12 Mbps, pure transfer is 24.39 seconds versus 16.36 seconds for Hyper3D's ZIP—not measured phone load. Hyper3D wins delivery bytes; SupaVoxel's stronger digital feathers add 12.04 MB to that UI payload and would need repair of 471 nonmanifold edges if printed.

How many credits would a hundred figures require?

Assume—only for arithmetic—that every run repeats this one charge, both material stages again add zero, and there are no failures or plan caps. One hundred successful Gen-1.5 PBR outcomes would imply 50 Hyper3D credits; one hundred matched SupaVoxel requests would imply 300 SupaVoxel credits. Those are two denominated ledgers, not “six times cheaper.” This two-run learning detour cost 1.0 Hyper3D credit for Gen-2.5 plus Gen-1.5 together; a user who starts correctly at Gen-1.5 did not make the wasted first attempt. A one-time five-credit free balance could theoretically cover at most ten similar 0.5-credit confirmations if nothing else changes—it cannot fund one hundred. For export traffic, one hundred actual UI handoffs at the measured file sizes imply 2.4545 GB of Hyper3D ZIPs and 3.6590 GB of SupaVoxel GLBs. None of these is a completed batch or a purchasing guarantee.

Where does Hyper3D win beyond download size?

The Hyper3D model joins the back-wing roots into a flatter white span; its coherent shell is still a genuine print-workflow advantage.

SupaVoxel shows separate feather tiers and the exposed gold collar, but this file has 471 nonmanifold edges after seam welding.

After fair UV welding, Hyper3D's delivered Gen-1.5 mesh has one watertight face-connected shell and zero nonmanifold edges. SupaVoxel's original-size mesh has 315 face-connected regions and 471 nonmanifold edges. This is not a minor rival point; it reverses my choice for a fabrication-first buyer. Hyper3D also offers the smaller file, by 21.34 MB when comparing standalone PBR GLBs. The price for those wins in this model is an obvious connected panel where distinct rear feathers would have helped the digital shot. SupaVoxel buys a more articulate invented back with more bytes and an unsolved print-repair task. No back reference was supplied, and no figure was sliced or printed, so I am choosing between delivered images and measured topology, not certifying an historically correct angel or a ready-made statue.

Final verdict: what did I get for the two debits?

The 0.5-credit Gen-2.5 debit got me a preview that the Free account could not download. The separate 0.5-credit Gen-1.5 geometry Confirm led, after two zero-extra-credit material actions in this recorded case, to a real PBR GLB in a two-file ZIP. SupaVoxel's one matched 3-credit request produced an actual GLB in the tested export branch. Hyper3D lost my first-time digital delivery decision because Gen-2.5 blocked the file, not because 0.5 can be priced against 3 or its usable Gen-1.5 file is worthless. A print buyer should start with the Gen-1.5 shell here; a digital collector wanting the stronger back treatment has a reason to take the bigger SupaVoxel file. That is a decision, not a global ranking.

Use SupaVoxel when your next file must actually leave the page

If a digitally presented winged figure with layered rear feathers is the commission, try your own source in SupaVoxel, verify a real GLB download and inspect it beyond the viewer. In this run the accessible export and rear detail justify that choice. If the same figure must go to a printer, budget and validate repair first; the original SupaVoxel shell failed a manifold check. If you choose Hyper3D's Free route instead, select the downloadable Gen-1.5 generation deliberately rather than counting on Gen-2.5's attractive but gated preview.

How I tested it. I logged the isolated Hyper3D Free balance around each generation and material action, matched the SupaVoxel request to the exact input PNG and its own transaction, inspected the actual downloaded ZIP and GLB and parsed the PBR member offline. Credit amounts are measured in separate products' units. The 12 Mbps transfer numbers and ×100 batch values are arithmetic with the assumptions stated above. Subscription price, dollar-per-credit equivalence, the full upload-to-file timing on both sides, local repair duration, actual printability and rights to publish the reference-influenced source were not verified.

Meshy AI 3D Generator Review 2026: 199,434 Triangles for One Wrench

Viktor Delgado — Sat, 10 Oct 2026 15:47:24 +0000

This is an independent test. Nothing here came from vendor access: both tools were used on my own free and paid accounts.

I had one product shot of an adjustable wrench and a page that needed a 3D version of it by the end of the week.

No CAD file. No photographer. Just the picture.

So I asked around. Every answer came back with the same two names: Meshy and SupaVoxel. Nobody could tell me which one to pick, so I stopped asking and ran the same photo through both.

Then I opened both files and took them apart.

My verdict in 60 seconds — Meshy 60/100, SupaVoxel 90/100

Those two scores are my opinion about this one job. Everything else on this page is a number I pulled out of the files.

Here's the scorecard.

Triangles you get — Meshy 199,434 vs SupaVoxel 1,500,000 · Meshy 6/10 · SupaVoxel 9/10 — Meshy decides your density for you and stops at 199,434; SupaVoxel hands you roughly 7.5× the surface, so the knurls and edges are still there when someone zooms
Vertices holding the shape — Meshy 111,498 vs SupaVoxel 816,916 · Meshy 6/10 · SupaVoxel 9/10 — Meshy's sparse point cloud is what rounds off the groove lip; SupaVoxel's 816,916 points keep those transitions sharp
What the file weighs — Meshy 11,603,384 bytes vs SupaVoxel 8,842,180 bytes · Meshy 6/10 · SupaVoxel 9/10 — Meshy ships 2.76 MB of extra weight for less detail; SupaVoxel is the smaller download and the denser model at the same time
Wait on a 12 Mbps phone — Meshy 7.7 s vs SupaVoxel 5.9 s · Meshy 6/10 · SupaVoxel 9/10 — Meshy costs your visitor almost two extra seconds of blank screen; SupaVoxel gets the wrench on the page first
Wait on a 100 Mbps desk line — Meshy 0.93 s vs SupaVoxel 0.71 s · Meshy 8/10 · SupaVoxel 9/10 — Meshy is still the slower of the two, though on fibre the 0.22 s gap is one nobody will ever feel
Deliverables from the one run — Meshy 1 GLB vs SupaVoxel 2 GLBs · Meshy 7/10 · SupaVoxel 9/10 — Meshy's run gave me a single 11,603,384-byte file to work with; SupaVoxel's export menu had both a compressed 8,842,180-byte GLB and a full 68,718,876-byte original-size GLB waiting, no re-run needed
Textures baked into the file — Meshy 3 vs SupaVoxel 3 · Meshy 7/10 · SupaVoxel 7/10 — a genuine tie: neither one skimped, so the size difference between them isn't a missing texture
File format you download — Meshy GLB vs SupaVoxel GLB · Meshy 8/10 · SupaVoxel 8/10 — level again, and that's good news: both hand you one self-contained file with nothing to convert

Four things you should know before you pick:

Meshy decides your mesh density for you. You get 199,434 triangles and that's the end of the conversation.
Meshy hands you the bigger file. 11,603,384 bytes against 8,842,180 for the same wrench, from the same photo, the same afternoon.
Meshy's record has no generation time in it at all. I'm not going to guess at a number that isn't there.
Meshy's export asks nothing of your software. That's a real win and it gets its own section further down.

If you're putting a wrench on a product page this week, SupaVoxel is the one I'd use. That's where I landed after opening both files — and the tool I ran it in is at https://supavoxel.com if you want to start from the same place.

One image, one run on each side. Not a lab study.

So what did each tool actually have to work with?

The only thing either tool got: one photo of a brushed-steel adjustable wrench. No text prompt on either side.

That's it. One picture.

Meshy got the front. SupaVoxel got the front. Neither got the back, the inside of the jaw, or the far end of the screw. Everything you don't see in that frame, both of them had to invent.

Keep that in mind later, because it decides which criticisms of Meshy are fair and which aren't.

One file gives you 7.5× more surface to work with

Meshy's wrench with the texture switched off, so you're looking at raw shape: 199,434 triangles.

The SupaVoxel file at the exact same camera angle: 1,500,000 triangles.

Triangles are the little flat plates a 3D model is built out of. More of them means the tool can carve finer shapes before everything turns into a smooth blob.

Meshy gives you 199,434 of them. SupaVoxel gives you 1,500,000.

That's roughly seven and a half times as much surface describing the same hand tool. Sounds like overkill, right? It is — until somebody zooms.

And you don't get to pick. Meshy hands you 199,434 and that's the file. There's no slider where you ask Meshy for more.

Zooming is exactly what people do on a product page, and that's where Meshy's number starts to hurt.

Zoom in, and that number stops being a spreadsheet row

Meshy up close in wireframe — every line is the edge of one of those 199,434 triangles.

The same close-up on the SupaVoxel file. Denser web of edges, same wrench.

Let me be fair to Meshy first: this mesh is not a mess. The edges are spread evenly, the tool reads as one clean shell, and nothing here looks broken.

But look at how far apart Meshy's lines are.

Every fine thing on a wrench — the knurl on the adjusting wheel, the lip around the handle groove — has to fit between those lines or get painted on as texture instead. With Meshy's 199,434 triangles, more of it gets painted on.

Texture looks fine at a distance and falls apart the moment someone leans in.

The denser file is also the smaller download

Meshy from the side — the full tool profile, and the 11.60 MB download that carries it.

SupaVoxel from the identical side angle. 8.84 MB, and 816,916 vertices holding the profile.

Here's the part that surprised me.

Meshy's file is 11,603,384 bytes. The SupaVoxel file is 8,842,180. That's 2.76 MB less to move — with seven and a half times the triangles inside it.

Normally you pay for detail in megabytes. With Meshy you paid and didn't get the detail.

On a 12 Mbps phone connection that gap is 7.7 seconds of waiting on Meshy against 5.9. Two seconds doesn't sound like much until it's the two seconds before somebody decides your page is slow.

More detail and a lighter file usually means picking one. Against Meshy, this time, you don't have to.

Same wrench from above. Which one holds up?

Meshy from directly above: the head-to-handle flare and the groove edge, built out of 199,434 triangles.

SupaVoxel from the same overhead angle. The two files sit slightly differently in frame — compare the shapes, not the pixels.

From the top, both are unmistakably the wrench. Meshy nails the outline.

The difference isn't the silhouette. It's the transitions — where the head flares into the handle, where the groove rolls over its edge. That's where Meshy's 199,434 triangles start rounding things off and 1,500,000 don't.

Meshy gets the shape. It's the last ten per cent of it that goes soft.

The jaw is where people zoom first

Meshy's jaw, blown up 2× from the same crop box used on both files.

The SupaVoxel jaw from the identical crop box and the same 2× blow-up.

Meshy keeps a jaw you'd recognise. So does the other file. Both keep the adjusting wheel.

And neither proves a single mechanical thing. One photograph can't tell you whether that jaw would actually travel, whether the thread fits, or whether any of it could be manufactured. Nobody's 3D file can do that from one picture.

Use these for looking at, not for machining.

What your visitor actually downloads

Meshy's three-quarter view — the frame that ends up on the page. Three textures baked in.

The SupaVoxel three-quarter view at the same camera. Also three textures.

Meshy bakes in three textures. So does SupaVoxel. That one's a tie, and ties matter — they tell you which differences are real and which are noise.

On a good office connection the size gap barely registers: Meshy 0.93 seconds against 0.71. On a phone it's 7.7 against 5.9.

So if everyone who sees your page is on fibre, stop worrying about the megabytes — Meshy is fine, pick on something else. If they're on a train, Meshy's extra 2.76 MB is the part they feel.

Everything I pulled out of the two files, in plain English

No table, because tables turn into mush on this platform. Just the list, both sides, every row.

Credits the job recorded. Meshy 35, SupaVoxel 3. Two different plans in two different units — that is not a price comparison and you can't make it into one.

Time the tool recorded. Meshy: nothing. SupaVoxel: 215.462 seconds. One of them shows its working, the other leaves the field empty. I'm not filling it in.

Triangles. Meshy 199,434, SupaVoxel 1,500,000. That's how much surface each file has to describe a wrench with.

Vertices — the corner points those triangles hang off. Meshy 111,498, SupaVoxel 816,916.

Textures baked into the file. Three each. Not resolutions, not megabytes — three images packed inside, on both sides. A genuine tie.

File size. Meshy 11,603,384 bytes, SupaVoxel 8,842,180 bytes.

Format. GLB from Meshy, GLB from SupaVoxel. Nobody has to convert anything to open either one.

Retries. Zero and zero. Neither tool needed a second attempt on this wrench.

Failures. Not recorded on either side. So no one gets a reliability claim out of this article — not Meshy, not the other one. If a tool's failure rate matters to you, this run can't answer it.

Required extensions — the special decoders your software must have. Meshy: none. SupaVoxel: EXT_meshopt_compression and KHR_mesh_quantization.

The alternative export. SupaVoxel also offers the same wrench at original size: 68,718,876 bytes, with no required extensions at all. Meshy wasn't run in a second export mode, so there's no matching number on that side — and I'm not going to invent one to make the comparison look tidy.

That's the whole readout. Three rows are blank — two of them on Meshy's side — and the blanks are part of the answer.

Three sums I did on the back of an envelope

None of these came out of a stopwatch or a profiler. They're arithmetic on the measured numbers above, and here's exactly how each one works so you can redo it with your own connection.

Waiting on a phone. File size × 8 ÷ 12,000,000, assuming a steady 12 Mbps with no handshake and no decoding. Meshy 7.7 seconds, SupaVoxel 5.9. Picture someone standing on a platform waiting for your product page to finish. That's where the extra 2.76 MB lands.

Waiting at a desk. Same sum at 100 Mbps. Meshy 0.93 seconds, SupaVoxel 0.71. Nobody on a decent office line will ever notice this, and I'd rather tell you that than pretend Meshy has a problem it doesn't.

A hundred of them on disk. This file × 100. Meshy 1.16 GB, SupaVoxel 0.88 GB — a 0.28 GB gap per hundred products. It's a capacity estimate, not a hundred real runs: no failures, no retries, every job assumed identical to this one.

A hundred runs on each meter. Meshy 3,500, SupaVoxel 300. Same caveat, and the same rule as before — different plans, different units, not a price ratio.

Memory the raw geometry wants. 32 bytes per vertex plus 4 bytes per triangle index, textures excluded. Meshy 6.0 MB, SupaVoxel 44.1 MB. This is a sketch of the vertex buffer, not a VRAM reading and not a floor. Load six product models on a three-year-old Android and it's the row you'll feel first — and it's Meshy's row.

Every one of those is arithmetic on measured bytes and counts. If your numbers come out different from mine, it's because your assumptions differ — not because Meshy or SupaVoxel behaved differently that day.

One run, two finished files

The SupaVoxel export menu after the wrench finished: a compressed 8,842,180-byte GLB and a full original-size 68,718,876-byte GLB, both sitting there from the same run.

This is the bit I didn't expect to care about and now check for first.

One generation, two deliverables. The compressed 8,842,180-byte GLB is what you put on the product page — small, fast, the one in all the download maths above. The original-size export is the complete, uncompressed version at 68,718,876 bytes, with textures stored as PNG rather than the compressed build's WebP. Bigger, because nothing has been squeezed out of it — that's what "original size" means.

So you pick per destination instead of per generation. Web page: take the small one. Handing it to an engineer, or feeding a picky importer: take the full one. Neither choice costs you a re-run, a conversion tool, or a second job on the meter.

The useful part isn't which file is smaller. It's that you get both out of one click without going back to the start.

Where Meshy actually wins

Meshy's export panel. The GLB it produced declares no required extensions at all.

Two rows go to Meshy, and they're not small.

One: Meshy's file asks nothing of your software. Both tools hand you a GLB — a single 3D file with the shapes and textures packed inside. Meshy's declares no required extensions; the compressed SupaVoxel GLB is squeezed with a scheme called meshopt, which your software has to understand before it can open that particular file. Switch to SupaVoxel's original-size export from the same menu and that decoder isn't needed either.

Picture the moment it bites. You hand the file to a colleague, they drag it into whatever viewer their team standardised on three years ago, and it just refuses. With Meshy's file that call doesn't happen — that's a genuine advantage and worth saying plainly.

One honest caveat on that whole row: I read the requirement flags out of the files. I didn't sit down and import either one into a specific piece of software, so treat this as "what the file declares it needs", not "here's what opened and what didn't".

Two: Meshy is far lighter on memory. Work out what the raw geometry wants to sit in — 32 bytes per vertex, 4 bytes per triangle index, textures not counted — and you get 6.0 MB for Meshy against 44.1 MB. That's a 38.1 MB difference in Meshy's favour.

When does that matter? A configurator page with six variants loaded at once, on a phone somebody bought in 2022. That's where a 44.1 MB geometry budget stops being a number and starts being a crash.

So Meshy wins the awkward-importer case and the tight-device case. Outright. If either of those is your reality, take Meshy and don't look back — and if you want the sharper mesh anyway, the honest route is to decimate it yourself before shipping, not to pretend the memory row doesn't exist.

So which one goes on the page?

For a wrench that has to look right when somebody leans in, on a page that has to load on a phone: SupaVoxel. More detail, smaller file, and a jaw that survives a 2× crop.

For a wrench that has to drop into a picky importer or run on a cheap device: Meshy, because none of the detail matters if the file won't open.

And on money — the job recorded 35 credits on Meshy and 3 on SupaVoxel. Two different plans, two different units. I'm not turning that into a price comparison, because it isn't one.

Try it with your own product shot

Don't take my word for a single run. Take the photo you actually need turned into 3D, run it through https://supavoxel.com and open the file the same way I did — look at the triangle count, look at the file size, then zoom all the way in on the part your customers care about.

Fifteen minutes of that beats any review, including this one.

How I tested this

One photo of an adjustable wrench, uploaded to both tools in the same session, no text prompt on either side. Meshy ran on its 7.1 Flagship model at High Detail and Ultra 2K with texture and image enhancement on; SupaVoxel ran at 5 steps, guidance 5.5, background removal on, octree 256. Each tool's own defaults, one run apiece.

Triangle counts, vertex counts, texture counts, file sizes and extension requirements were read straight out of the two downloaded files. Both renders use the same offline viewer, the same lighting and the same numeric camera angles — though each file sits in its own orientation, so treat the pairs as matched cameras, not pixel overlays.

The download seconds are arithmetic, not a stopwatch: file size × 8 ÷ 12,000,000 for the phone figure and ÷ 100,000,000 for the desk figure, assuming a steady connection and ignoring decoding and caching. The memory figures are arithmetic too, at 32 bytes per vertex plus 4 bytes per triangle index, textures excluded.

Neither tool's failure count was recorded, and Meshy's generation time wasn't either — so I've left both blank rather than guess. Both recorded zero retries.

Hyperagent Review 2026: What \"Agents That Ship Real Work\" Actually Delivers

Viktor Delgado — Wed, 07 Oct 2026 15:42:39 +0000

Hyperagent promises a fleet of AI agents that research, build and keep deliverables alive inside Slack, your inbox or a schedule. I went through the product, the docs, the billing model and the published example runs to work out who it is for, what a job really costs, and where the rough edges are.

If you have been anywhere near the AI-agent conversation this year, you have probably seen Hyperagent’s tagline: “Agents that ship real, powerful work.” It is a bold line in a category full of chatbots that answer a question and forget you. So I spent a few evenings with Hyperagent — the marketing site, the four-lesson onboarding path, the billing docs and the example jobs it shows on its homepage — to figure out whether Hyperagent is a genuinely different kind of tool or just another agent wrapper with a nicer landing page.

Because a lot of what Hyperagent produces ends up as a website, a landing page or a small app, I also kept a prompt-to-product builder, Begin, open in the next tab as a point of comparison for that specific slice of the workflow — more on how the two fit together at the end.

Hyperagent leads with finished deliverables — a hiring dashboard, a brand transformation, an out-of-home campaign — and prints the minutes and dollars each one took.

What Hyperagent is, in one loop

Hyperagent’s own docs describe the whole product as a single loop: you ask, the agent works, you get the finished thing, and it remembers. That last clause is the differentiator Hyperagent keeps coming back to. Its agents are not stateless chat sessions; they are configured teammates with a name, instructions, tools and knowledge, and they propose new memories and skills from real runs that you then approve or reject.

Three words show up everywhere in Hyperagent:

A thread holds one piece of work — the conversation, the tools that ran, and every artifact produced.
An agent is a teammate you configure once. The same Hyperagent agent appears in a thread, in Slack, or on a Monday-morning schedule.
Learning is how a Hyperagent agent gets better: it proposes memories and skills from runs, and you decide what sticks.

That model is closer to “hire a junior and train them” than to “prompt a model”, and it shapes everything else about how Hyperagent feels.

Who Hyperagent is for

Hyperagent is aimed at teams that want output, not answers. The example jobs on the homepage are telling: a cinematic real-estate marketing package from a listing, a hiring command center that sources and ranks candidates with skill sliders, a complete brand identity with packaging and a launch site, and an out-of-home campaign with billboard research and mock-ups. None of those is a “write me a paragraph” task. They are multi-step projects that Hyperagent runs in its own computing environment with real browsers, real shells and access to whatever you would hand a new hire.

If your work is mostly conversational — drafting emails, summarising documents — Hyperagent is overkill. If your work is “go research this, build the thing, and keep it updated when the world changes”, Hyperagent is squarely pointed at you.

Getting started: four lessons, one hour

Hyperagent’s onboarding is unusually well thought out. The “Start here” path is four short lessons that chain into each other:

Your first thread — do real work in five minutes with nothing configured.
Your first agent — turn a job worth repeating into a named teammate.
Teach it something — save your first memory and watch Hyperagent learn.
Put it where you work — move the agent into Slack, a schedule, or your inbox.

Hyperagent says the whole path takes about an hour, and reading through it that estimate looks honest. The docs also include a wizard for migrating an existing OpenClaw agent, which tells you something about who Hyperagent expects to be switching over.

The onboarding is four lessons — thread, agent, memory, surface — and Hyperagent’s docs are refreshingly free of fluff.

Where Hyperagent runs: Slack, Telegram, webhooks, schedules

One of the more practical decisions Hyperagent has made is to treat the chat window as just one surface. You can @-mention a Hyperagent agent in Slack, connect it to Telegram, trigger it from a webhook, or run it on a schedule. Deliverables go to Slack, your inbox, “anywhere”, and Hyperagent keeps them current as inputs change — the “work never goes stale” promise.

For a team already living in Slack this is the difference between a tool people try once and a tool that becomes part of the weekly rhythm. It is also where Hyperagent’s fleet framing makes sense: you deploy, connect and manage agents from one command center rather than one browser tab each.

What Hyperagent can produce

Hyperagent lists websites, video, slides, documents and dashboards as first-class outputs, and it is specific about the websites: HTML that renders live, “built and hosted, not pasted into a doc”. The homepage examples cover market-signal briefs, candidate slates, comp analyses and landing pages. Every search, decision and artifact is visible as it is built, which matters when you are trying to trust an agent with a multi-hour job.

Hyperagent pricing: dollar credits, not tokens

This is the part I spent the most time on, because Hyperagent’s billing changed in August 2026 and the docs are candid about it.

Hyperagent bills through credits denominated in dollars. You choose a monthly plan, pay its price at the start of each billing period, and that money comes back as credit plus a bonus that grows with your plan. Usage spends the balance down.
Pay As You Go and annual plans are no longer offered as of August 2026, and the early-user bonus subsidy was replaced by a progressive bonus.
Shared billing lets multiple members bill to one organisation payment method.
Usage can be tracked at the account, agent or thread level, and invoices are downloadable.
Hyperagent also documents connecting a ChatGPT subscription as an option.

The most useful pricing data is on the homepage itself, where Hyperagent prints the real cost of its example runs:

Out-of-home campaign research and visuals: 8 minutes, $6.41
Cinematic real-estate video package: 29 minutes, $24.79
Hiring command center with ranked candidates: 22 minutes, $14.18
Complete brand transformation with launch site: 15 minutes, $3.88

Those are single-digit to low-double-digit dollar amounts for jobs that would take a contractor a day. The catch is variance: Hyperagent’s docs push you to “choose the right model for each job”, which is a polite way of saying the same brief can cost very different amounts depending on the model an agent reaches for.

Hyperagent’s billing section covers credits, plans, shared billing, usage and invoices — and states plainly that Pay As You Go and annual plans were dropped in August 2026.

What Hyperagent gets right

Deliverables, not chat. Hyperagent optimises for finished artifacts that live somewhere useful.
Memory that you control. Agents propose memories and skills; a human approves them. That is the right default.
Multi-surface by design. Slack, Telegram, webhooks and schedules are core, not add-ons.
Transparent cost per job. Printing “$6.41, 8 minutes” on the homepage is a level of honesty most agent platforms avoid.
Serious onboarding. The lesson path and knowledge base are better than most products twice Hyperagent’s age.

Where Hyperagent falls short

No pay-as-you-go anymore. If you only need Hyperagent for a project a quarter, a monthly plan is a poor fit.
Cost variance. Dollar credits are clear, but per-run cost depends on model choice, and Hyperagent’s own docs devote a page to controlling it.
The name is crowded. Searching “hyperagent” also surfaces Hyperbrowser’s open-source HyperAgent for Playwright, Meta’s “Hyperagents” self-improving-agent research, and an unrelated blockchain protocol. Make sure you are on hyperagent.com.
Generalist output. Hyperagent’s landing pages and sites are competent, but a builder that specialises in shipping products still produces a stronger website from the same brief.

Hyperagent vs the alternatives

Against chat-first assistants, Hyperagent wins on persistence and deliverables. Against pure automation platforms, Hyperagent wins on judgment — its agents research and decide rather than execute a fixed flow. Where Hyperagent is weakest is the last mile of a specific artifact type: if what you need is a production website or a native app, a dedicated builder does that one job more thoroughly, which is exactly why I kept Begin open alongside it.

Verdict: is Hyperagent worth it in 2026?

Yes, for teams with recurring multi-step work that ends in a real deliverable and a Slack channel to receive it. Hyperagent’s loop — ask, work, deliver, remember — is coherent, the billing is honest, and the published per-job costs are low enough to justify a monthly plan quickly. It is a weaker fit for occasional users now that pay-as-you-go is gone, and for anyone whose real need is a single polished product rather than a stream of briefs. You can walk through Hyperagent’s first thread yourself before deciding.

The alternative worth keeping next to it: Begin

Two things about Hyperagent pushed me to keep a specialist builder open: the loss of a pay-as-you-go option, and the fact that its websites and apps are one output among many rather than the whole point. Begin is the one I used.

Five free credits, no card — exactly one real first build, so you can paste a domain and judge the output before paying anything.
Prompt or paste a domain — Begin fetches the source, reads the design tokens, rewrites the copy and produces a site you own, or builds an iOS app, Android app or Chrome extension from the same brief.
Predictable credits — every plan includes 100 credits a month; a first build costs 5 and every change after that costs 1, with unused credits rolling over on paid plans and failed builds refunded automatically.
Shipping is built in — hosting on Begin’s edge with TLS and your own domain, sign-in, database, storage and Stripe payments wired into each project.
From $49 a month, with a $99 team tier for shared workspaces and a brand kit.

If the job is “research it, build it, keep it current in Slack”, stay with Hyperagent. If the job is “turn this brief into a product I can put in front of customers”, spend five minutes on Begin first.

Photo by David Levêque on Unsplash