DEV Community: Lars Saleh

Higgsfield AI Image Generator Review 2026: 4 Matcha Images, 2 Credits

Lars Saleh — Mon, 19 Oct 2026 15:51:09 +0000

One text prompt, four original 1376×768 stills: Higgsfield charged two credits per image and delivered watermarked PNGs; Kyncept charged one credit per image and delivered JPEGs without comparable branded text. Neither side obeyed the instruction to show exactly three workers.

My verdict in 60 seconds

This is an independent, single-tester account of a hands-on comparison, not a representative image-generator benchmark. Both products were run on ordinary customer accounts — a free tier and a paid plan — with no vendor-provided access. Readers can repeat the prompt at https://kyncept.com and compare the original files below. The work took place October 1–2, 2026: two completed image requests per product, plus a separate, smaller video check.

Here is my eight-line scorecard for this matcha-miniature image job only. These are qualitative findings, not invented platform-wide numerical ratings:

Image delivered — Higgsfield: two completed stills; Kyncept: two completed stills. Neither image side failed to return an original file in this test.
Scene elements — Both: broadly present. The green pancake, white plate, small crane, scaffold, butter, steam and miniature orange-clad workers are visible across the four images.
Exact worker count — Both: miss. Each Kyncept still and Higgsfield's first appear to show about four workers; Higgsfield's second shows more than three.
Credits charged per still — Higgsfield: two; Kyncept: one, confirmed against the respective before-and-after balances.
Time to result — Higgsfield: results first observed by 22.61 and 45.82 seconds; Kyncept: UI completion intervals measured at 68.9 and 60.9 seconds. Different measurement methods prevent an exact speed ranking.
Branded text in original — Higgsfield: yes, visibly burned into both downloaded PNGs; Kyncept: none comparable in these two downloaded JPEGs. Free- and paid-tier policies were not established.
Delivery format and bytes — Higgsfield: PNG RGBA, 1,660,430 and 1,801,245 bytes; Kyncept: JPEG, 780,403 and 827,821 bytes, at the same pixel dimensions.
Commercial rights and wider reliability — Unscored for both. Four stills establish neither a general success rate nor permission to use the outputs commercially.

For this particular prompt, the lower observed credit debit and absence of visible branded text on the tested originals make Kyncept my choice if the tested account conditions match yours. Higgsfield still made two usable-looking scenes and displayed its first result at the earlier observation points. That observation is worth reporting; an exact claim that it generates faster is not.

Cover assembled from the actual Kyncept image 2 and Higgsfield image 2, not substitute or regenerated examples.

The test was one text-only image prompt, not a model certification

The scene was inspired by a social miniature-food example that used a photo-plus-video workflow. This test instead used an original text-only prompt, identical at https://higgsfield.ai and Kyncept. The source example is not evidence of text-only success:

Create a 16:9 macro photograph of a three-layer giant matcha pancake on a white ceramic plate. Three tiny workers in orange uniforms and yellow helmets climb a scaffold while a small yellow crane lifts a thick green pancake slab. Powdery matcha coats the top; a square of pale butter melts and drips down the nearest edge, and steam rises in morning window light. Workers must remain miniature relative to the food.

Higgsfield and Kyncept both displayed Nano Banana Pro; both were set to 16:9, with 1K selected on Higgsfield. I submitted twice per side and downloaded four originals. Shared display names and 1376×768 files do not establish an identical underlying version or settings, much less identical quality.

Kyncept before the image run: the text-only image workflow and the starting 311-credit balance.

Higgsfield image settings: Nano Banana Pro, selected 16:9 and 1K, with two credits shown on the Generate button.

Four original matcha images, with their mistakes intact

All four downloaded originals show a related macro scene: white plate, green pancake, yellow crane, scaffold, orange workers, butter and steam. They are different compositions. Kyncept's first lifts a slab on the right; its second places the crane behind the stack. Higgsfield's first extends the foreground scaffold; Higgsfield's second spreads workers around both sides.

Kyncept original 1: crane-held slab, steam, scaffold and butter; roughly four workers rather than the requested three.

Higgsfield original 1: comparable matcha construction scene, roughly four workers, with the platform logo visible in the file.

The first Higgsfield result card ties this image to the completed text-only run; the downloaded original above is the better source for checking the watermark.

Kyncept original 2: a different crop and layer placement; again about four orange-clad miniature workers, no comparable branded text visible.

Higgsfield original 2: steam, crane and scaffold survive, but the number of miniature workers grows beyond the requested three; the Higgsfield logo remains in the original.

The images let readers choose a composition, not award a general quality winner. Two Higgsfield pictures and two Kyncept pictures cannot prove Higgsfield is better, Kyncept is better, or that both are objectively equivalent.

Prompt adherence: the three-worker instruction is the hard check

The exact instruction named three tiny workers. Kyncept's two images show about four each; Higgsfield's first shows about four, and Higgsfield's second visibly more. Both made convincing worksite scenes but missed that count. If the cast matters to a storyboard, inspect and regenerate rather than assuming either site will obey an exact number.

The other visible requirements fare better: green pancake, white plate, yellow crane, scaffold, butter, steam and miniature figures. None repairs the count, and a layered-looking stack is not proof of exact three-layer geometry. This is a finding about four outputs, not an estimated Higgsfield or Kyncept failure rate. Flagging only Higgsfield's extra workers would conceal the comparable miss in Kyncept's files.

Credits: two receipts on each image side

A button price is not a debit receipt. Higgsfield's image account went 10 → 8 → 6 across two completed images: two credits each. Kyncept's balance went 311 → 310 → 309: one credit each. This verifies the selected Higgsfield and Kyncept options, not every image model or future charge.

Higgsfield image account before the two still-image requests: 10 credits. This account was separate from the video test account.

After Higgsfield image 1, the same image account shows eight credits: a two-credit debit.

After Higgsfield image 2, the same account shows six credits: a second two-credit debit.

Kyncept result view after both stills: the image-account balance has moved from 311 to 309 across the two one-credit runs.

The October 1, 2026 monthly pricing screenshots—not fresh October 2 checks—show separate $59/month, 1,200-credit plans: Kyncept Pro and Higgsfield Plus. On those respective plan assumptions, observed image debits correspond to about $0.0492 Kyncept and $0.0983 Higgsfield per image. These are hypothetical allocations, not charges billed to the free Higgsfield test accounts or proof of what this Kyncept account paid. Higgsfield's video test used a different free account from its image test. Neither their balances nor cross-company credits can be pooled. The pricing-focused companion article takes the longer scenarios.

Timing: earlier observation is not an exact speed victory

The timing records are asymmetrical. Kyncept image 1 has a measured UI interval of 68.9 seconds and image 2 60.9 seconds. Higgsfield image 1 was first observed within 22.61 seconds of the click and image 2 within 45.82 seconds. The latter are upper bounds on first observation, not exact Higgsfield generation times or equivalent UI stopwatches. An apparent earlier result for Higgsfield image 2 matched an old card and was rejected.

Higgsfield's two results were visible at earlier checkpoints than Kyncept's measured UI completion intervals. Subtracting these figures or converting them to a speed ratio would mix unlike clocks and invent a precise completion moment. For a live iteration, Higgsfield's observed checkpoints are attractive; for repeated Kyncept image jobs, the one-credit receipt may be more consequential. Neither conclusion predicts how the sites perform under other workloads.

The Higgsfield watermark is part of the downloaded PNGs

The Higgsfield logo is visible in both unmodified downloaded PNGs above; it is not just a page overlay. Higgsfield's full-preview screens make the image and its model selection easier to inspect, but the original files—not those screens—establish that the mark survives download. Neither tested Kyncept JPEG shows comparable branded text. For a clean-frame deliverable, inspect the original rather than trusting a preview.

Higgsfield full preview of image 1 and its selected model; compare the original PNG above for the baked-in mark.

Higgsfield full preview of image 2 and its selected model; the second original PNG independently carries the logo.

Scope matters: Higgsfield's originals came from a free account, but this test did not determine whether paying removes that logo. Nor does the lack of visible text in these Kyncept originals establish Kyncept's free-tier policy. Commercial rights on either site remain unverified. A visually unmarked file is not a license.

PNG versus JPEG: the exact bytes behind the same frame size

All four originals are 1376×768 pixels, slightly wider than mathematical 16:9 despite the interface selection. Higgsfield's RGBA PNG files contain 1,660,430 and 1,801,245 bytes; Kyncept's JPEG files contain 780,403 and 827,821 bytes. Each Higgsfield file in this sample is roughly twice as large as either Kyncept file. The encodings differ, so that ratio is not a controlled test of image quality or compression efficiency.

More bytes do not automatically mean a better-looking image. Higgsfield's PNG may suit a particular editing workflow, while Kyncept's smaller JPEGs are easier to move around; both claims depend on the user's actual deliverable. These measurements are from downloaded originals, not browser thumbnails. Higgsfield's selected 1K setting says nothing by itself about whether its free tier is locked there or whether other accounts offer larger files. Higher-resolution options were not tested.

UI flow: from prompt to saved original

The Higgsfield workflow was text → Nano Banana Pro/16:9/1K → two-credit Generate button → result → wallet 10→8→6. Kyncept's matching text-only 16:9 workflow was starting balance 311 → first result at 310 → second at 309. Higgsfield's two-credit button alone is less persuasive than the finished files and sequential balance changes on Higgsfield and Kyncept.

Kyncept's first finished still and the 310-credit balance after the first one-credit deduction.

Higgsfield's result view containing the two new matcha stills; both originals were downloaded separately for inspection.

A result grid can fool a timer: an apparent early finish for Higgsfield's second image was an older card. Its 45.82-second first-observed bound refers to the identifiable new card. The screenshots prove this limited workflow, not concurrency, throughput or general reliability.

What these four images cannot settle

The shared Nano Banana Pro label does not certify an identical underlying version. Four outputs cannot estimate a probability that the next image will add a worker. This experiment did not test image-to-image, a source photo, higher resolutions, batch capacity, other models, licensing, renewal terms or free-tier policies.

"Better" depends on the assignment. All four fail a literal three-person cast, all depict a plausible crane-and-pancake composition, and only the two Kyncept originals lack comparable visible branding. A reader preparing a branded layout may prioritize that last point; a reader iterating compositions may value Higgsfield's earlier observation checkpoints. Neither preference needs a fabricated universal quality score.

A brief video side note, not another image-quality verdict

The separate video prompt asked for eight seconds. Kyncept delivered two 8.000-second clips; Higgsfield completed one clip on the selected Wan 2.5 Fast five-second option, delivering 5.042 seconds. These are unequal lengths, not a Higgsfield failure. AAC tracks exist, but requested sound effects and synchronization were not verified by listening. One selected Higgsfield video mode cannot characterize its whole free catalogue; the companion video review deals with that narrower test.

Final verdict: two credits bought a marked original in this test

This is one tester's verdict, not a multi-panel consumer study. For the exact matcha-pancake prompt, Higgsfield returned two 1376×768 PNGs, visibly branded in their originals, for two credits each. Kyncept returned two 1376×768 JPEGs without comparable branding for one credit each. Both depicted the main scene; both overshot the requested count of three miniature workers. Higgsfield's first-observed result bounds were earlier than the Kyncept measured UI intervals, but that mismatch in measurement methods does not justify announcing an exact speed winner.

The takeaway is a reproducible checklist, not a platform-wide quality winner: use the same prompt, verify the debit, download the original, count the workers, inspect the pixels for text and note the format. This evidence covers one scene, not other plans or briefs.

Which one I would use for this job

For this text-only matcha scene, I would start with Kyncept if the same account terms held: one observed credit per image and no comparable branded text in the tested originals. For an earlier observed first draft, Higgsfield deserves a try too. Either way, inspect the worker count and verify rights before delivery.

Run the exact prompt at https://kyncept.com and compare your balance movement and original files with these four. Future Higgsfield or Kyncept generations, policies and rights may differ.

Tripo GLB Export Review 2026: 63.61 MB for One Knitted Tray

Lars Saleh — Sat, 17 Oct 2026 15:45:32 +0000

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

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

The question on this tray was whether Tripo or SupaVoxel was faking the cable knit with a normal map on a smooth shell — because if either were, you would print a bald tray. Neither is. The untextured mesh renders, which load no texture at all, show the full cable relief on both sides, and both back silhouettes are scalloped stitch by stitch, which a normal map physically cannot do. Both files also ship a normal map on top of that real displacement: Tripo a 4096 PNG at 4.72 MB, SupaVoxel a 2048 WebP at 144 KB. So nobody prints a smooth tray, and the story is relief quality, not relief presence — and on quality Tripo wins. Tripo keeps three distinguishable stitch languages on the rim; SupaVoxel smooths the cable into fat tubes and flattens the grounds into soft ridges. Tripo's price for that: 63.61 MB against 5.71 MB, 11.1×.

Knit is real displaced geometry — Tripo yes · SupaVoxel yes · neither faked it
Distinguishable stitch languages on the rim — Tripo 3 (braided cable, seed ground, 1×1 rib) · SupaVoxel 1 smoothed cable + soft ridges · Tripo wins, plainly
GLB size — Tripo 63.61 MB · SupaVoxel 5.71 MB · 11.1×
Bytes per triangle — Tripo 33.38 B · SupaVoxel 5.87 B · 5.7×
Texture a slicer actually reads (baseColor) — Tripo 3.07 MB 4K JPEG · SupaVoxel 0.34 MB 2048 WebP · 9.0×
Texture a slicer never reads — Tripo 6.27 MB · SupaVoxel 0.28 MB · 22.6×
Normal map alone — Tripo 4.72 MB PNG · SupaVoxel 144 KB WebP · 32.8×, on relief that is already geometry
First load on 12 Mbps mobile — Tripo 42.4 s · SupaVoxel 3.8 s · 11.1×

Five things that decide this case:

SupaVoxel loses the surface here, and it is not a rounding error. Tripo's rim resolves braided cable with visible plies, a seed/moss field between the cables, and a fine 1×1 rib you can count column by column. SupaVoxel renders the cables as smooth fat tubes and the rib field as soft parallel ridges.
Tripo bought that with 2.0× the triangles — 1,905,766 against 971,646 — and 0.2384 mm mean edge against 0.3333 mm. On dense repeating relief that converts. On most subjects it would not.
Tripo also bought it with a texture policy unrelated to the knit: three uncompressed 4096 maps totalling 9.35 MB, 6.27 MB of which no slicer reads, against SupaVoxel's three 2048 WebPs at 0.62 MB.
That single 4.72 MB PNG normal map is 83% of the entire SupaVoxel GLB — decoration on top of relief that is already displaced geometry.
Neither model invented anything. Both extended the knit onto the back of the rim, which the photo never showed, and neither produced fake lettering or a maker's mark.

Judging the printed stitch layer on one tray, take Tripo's file. If the tray is going on a web page, into a viewer, or anywhere 63.61 MB per asset is a number someone reads, take SupaVoxel's — the exchange rate is at the end.

The input both tools saw

The single input: a 1,794,081-byte PNG, sha256 ae8f6d6a…, one off-white round tray, low rim, two punched-through handles, cable-and-rib knit over the whole surface. A three-quarter top view, so the underside and the back of the rim exist in neither tool's evidence — which is why the back renders below matter.

The stress test: strip every texture and see what is left

The SupaVoxel mesh with no textures loaded at all. The cables, the bead columns and the braided rows across the floor are all still there, so this knit is real displaced geometry. The failure mode is in the same frame: with no texture, the cables read as smooth tubes where Tripo's still read as braid.

Tripo's mesh at the same camera, also untextured. Same answer — real geometry — but the seed field and the fine rib are still distinguishable with no texture at all.

This is the whole reason I ran the case, and the tempting story turned out false. Nobody normal-mapped a bald tray. Both tools displaced the mesh, both ship a normal map anyway, and it sits on top of the displacement rather than instead of it.

Relief present in the untextured mesh — Tripo yes · SupaVoxel yes · neither faked it
Normal map also shipped — Tripo 4096 PNG 4.72 MB · SupaVoxel 2048 WebP 144 KB · cosmetic on both
Who wins the relief — Tripo, on stitch legibility · shown at 1:1 two sections down

Front, same camera, same light

SupaVoxel, yaw 90 so both handles sit left and right. The rim cables are smooth fat tubes crossing a dense field of fine bead columns. The crossings read; the plies inside each strand do not. The bottom silhouette of the rim is a near-smooth arc with a faint ripple.

Tripo at the same camera. Three stitch types on one rim: braided cable with the plies visible inside each strand, a seed/moss field between the cables, and countable 1×1 rib columns. The bottom silhouette is bumpy stitch by stitch, not an arc.

Both handles are genuine through-holes on Tripo's model and on SupaVoxel's, so neither took the easy way out on the hard part of the shape.

Back: the face neither tool was shown

SupaVoxel from behind, a surface that does not exist in the input. No invented decoration: the same cable-and-bead language continues around, with a through-hole at each end. What it did do is repeat — the back is more uniform than the front and several cable crossings do not line up. The outer floor silhouette is a near-smooth arc.

Tripo from behind. Tripo continued the knit too, and harder: the seed field and the fine rib are both still there, and the outer floor silhouette is a ring of sawteeth, one bump per stitch.

Neither model hallucinated text, a logo or a stamp onto the unseen face. On invention the two are tied; on resolution they are not.

The one-to-one crop where SupaVoxel loses

The SupaVoxel rim at 1:1. Two things are true at once. The relief is real — both silhouettes of the rim break up, and a normal map cannot cut a silhouette. And the stitch languages collapsed — four smooth fat tubes interlacing with no plies on them; where the seed field should be, a line of smooth beads; where the 1×1 rib should be, soft ridges you cannot count.

Tripo at the same crop: every ply inside every cable strand, individual seed bumps between the cables, countable rib columns on both sides, and a bottom edge that is sawtoothed stitch by stitch. This is where the 2.0× triangles and the 0.2384 mm mean edge cash out.

This is SupaVoxel's loss, stated where it happened rather than filed under regrets. Tripo did not waste those triangles here: a knitted tray is one of the few subjects that can absorb that density, and it absorbed it.

Triangles — Tripo 1,905,766 · SupaVoxel 971,646 · 2.0×
Mean triangle edge at 120 mm — Tripo 0.2384 mm · SupaVoxel 0.3333 mm · Tripo 1.68× finer than a 0.4 mm nozzle, SupaVoxel 1.20×
Both far finer than the ~4 mm cable pitch — so this is a modelling difference, not a resolution limit on either side

One thing worth correcting before anyone extrapolates: Tripo's triangle count is not a response to knit density. Across the nine other objects I ran, Tripo emits 1,896,372–1,996,779 triangles whatever the subject — a 5.2% spread, a fixed house budget. SupaVoxel's varies with the subject, 945,492 to 2,786,054, a 146% spread; on an armoured vehicle it emitted 44% more than Tripo. There is no ceiling on the SupaVoxel side. Here it chose the lower number, and here that cost it the rim. Ten objects is a sample, not a law.

Where the 63.61 MB actually goes

Tripo's export dialog. Texture Resolution defaults to "4k Current", and that default is most of the file. Three fields, no face count, no LOD, no line saying what this will weigh. The auto-filled name is "woven basket 3d model" — Tripo classified a knitted tray as a woven basket.

baseColor — Tripo 3.07 MB, 4096 JPEG · SupaVoxel 0.34 MB, 2048 WebP · 9.0×
Everything else (metallicRoughness + normal) — Tripo 6.27 MB · SupaVoxel 0.28 MB · 22.6×
Normal map alone — Tripo 4.72 MB PNG · SupaVoxel 144 KB WebP · 32.8×
All textures — Tripo 9.35 MB across three 4096 maps · SupaVoxel 0.62 MB across three 2048 maps · 15.1×
Geometry compression — SupaVoxel EXT_meshopt_compression + KHR_mesh_quantization · Tripo none (it declares KHR_materials_volume and FB_ngon_encoding)

A slicer reads baseColor and nothing else, so 6.27 MB of Tripo's download — 22.6× the SupaVoxel equivalent — is bytes a printing user fetches and discards. The 4.72 MB PNG normal map alone is 83% of the entire SupaVoxel GLB, describing relief that is already in the mesh.

SupaVoxel's baseColor is half the resolution, 2048 against 4096 — the one texture row where Tripo's extra bytes buy something real. They buy tinting, not stitch detail; the stitches live in the geometry, which is where SupaVoxel lost this case.

Bytes per triangle: 5.87 against 33.38

GLB size — Tripo 63,609,736 B · SupaVoxel 5,707,056 B · 11.1×
Bytes per triangle — Tripo 33.38 B · SupaVoxel 5.87 B · 5.7×
Triangles — Tripo 1,905,766 · SupaVoxel 971,646 · 2.0×

The file gap is 11.1× while the mesh gap is only 2.0×, and the difference between those ratios is entirely encoding policy. Tripo ships uncompressed geometry and uncompressed 4K images; SupaVoxel ships meshopt-compressed, quantised geometry and WebP. Per triangle Tripo costs 5.7× more to move, and none of that 5.7× is about how good Tripo's tray looks.

What it costs to open this in a browser

12 Mbps mobile, first load — Tripo 42.4 s · SupaVoxel 3.8 s · 38.6 s saved
100 Mbps home, first load — Tripo 5.09 s · SupaVoxel 0.46 s
CDN at $0.085/GB, 10,000 loads/month — Tripo $54.07 · SupaVoxel $4.85 · $49.22/month, $590.60/year
Geometry VRAM — Tripo 54.3 MB · SupaVoxel 27.7 MB · 26.5 MB saved
100 assets downloaded — Tripo 6.36 GB · SupaVoxel 0.57 GB

A 42-second first load is not a slow product page, it is a page without a 3D preview. And this is exactly where Tripo's rim detail stops paying: shrink the tray to a product-page viewport and Tripo's 2.0× triangles is close to invisible. The visitor waits 38.6 seconds longer and sees almost the same tray.

The relief is checkable before you download it — on one side

SupaVoxel's Wire view, inside the browser: the cables, the floor braids and the rim ribs all appear in the mesh itself. The "real geometry or painted fake?" question answered before a single byte is downloaded.

The same result page: Triangles 971,646 — matching the parsed GLB to the digit — millimetre dimensions you can flip to raw, a timestamped version, and Textured / Mesh / Wire / Normals one click apart.

Tripo's viewer has a textured model and a material strip. No wireframe, no mesh view, no normals view. On a subject whose entire value is surface relief, Tripo lets you inspect that surface as geometry only after you have paid, exported and downloaded 63.61 MB.

Tripo's viewport does not show the texture until after export

Tripo's textured mesh, which only appeared after export. The form is right — round tray, two punched handles, full-surface knit — the face-count readout is still half-hidden behind the Assets panel, and a promo banner ("Smart Mesh P2.0: Quads & Edit — Try For Free") still sits across the top.

What I did not measure

albedo ΔE — not captured, so no number on colour fidelity. Both trays read as the same matte off-white against the input; that is an eyeball claim, not a measurement.
UV chart occupancy — not captured.
The SupaVoxel export click count — not captured; that screenshot is byte-identical to the previous step. Tripo's is 2 steps, captured.
Full orientation alignment — partial. My probe ran 0/90/180/270 on Tripo but crashed the headless browser after 0 and 90 on SupaVoxel, so a finer off-axis angle was not ruled out here. Verified: at yaw 90 both SupaVoxel handles sit left and right and are visible, matching Tripo's yaw-0 framing, so every pair above is the same view of the same object.
Two wireframe zoom renders — discarded. At 971,646 and 1,905,766 triangles both render near-solid black at that focal length; I opened both to confirm genuine density rather than a blank frame, and neither is used as evidence.

Final verdict: Tripo scores 60/100

On the question I built this case to ask, both tools give the same answer: the knit is real displaced geometry, nobody faked it with a normal map, nobody prints a bald tray. On the follow-up — how good is the relief — Tripo wins outright, three legible stitch languages against a smoothed cable and soft ridges. A real loss for SupaVoxel, on a subject built entirely out of surface.

Then Tripo charges 63.61 MB for it: 6.27 MB of texture no slicer opens, 4.72 MB of that a single PNG normal map describing relief already in the mesh, uncompressed geometry, a 4K default buried in a dialog that never mentions size, and a file name calling a knitted tray a woven basket. SupaVoxel's file is 5.71 MB, meshopt-compressed and quantised, WebP throughout, and it loads on a phone in 3.8 seconds.

One run each, defaults — a sample of one per tool on this object. Every byte figure was parsed from the two downloaded GLB files, which is why you can check all of them yourself.

Which one I would use for this job

For a tray that has to live in a browser, a catalogue, an asset library or a batch, SupaVoxel is the file I would hand you: 5.71 MB against 63.61 MB, 5.87 bytes per triangle against 33.38, 3.8 s against 42.4 s on mobile, $58.20 a year of CDN against $648.80, 26.5 MB less VRAM, and real displaced knit geometry you verify in one click. Take Tripo if the printed stitch layer on one tray is the deliverable — Tripo's rim genuinely is better here, and I would rather show you the 1:1 crop than talk around it.

Tripo 3D Print Review 2026: Flipped Faces in a Watertight Tray

Lars Saleh — Thu, 15 Oct 2026 15:48:59 +0000

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

My verdict in 60 seconds — Tripo 65/100, SupaVoxel 88/100

One photograph of a cable-knit decorative tray, put through Tripo and through SupaVoxel, both GLB files downloaded, welded by position, measured with one script I wrote. This is the case where the print-prep sheet goes to Tripo. Tripo welds into a single watertight shell — 1 component, 0 boundary edges, 0 non-manifold edges — and the only thing wrong with it is inconsistent face winding. SupaVoxel's mesh has consistent winding and is not watertight: 225 components and 336 non-manifold edges, the highest component count of the ten objects I ran. Tripo's repair is one click. SupaVoxel's is a merge, a cleanup and a patch.

Watertight after welding — Tripo yes · SupaVoxel no · Tripo wins, and it is not close
Connected components — Tripo 1 · SupaVoxel 225 · 224 detached islands buried in the knit relief
Non-manifold edges — Tripo 0 · SupaVoxel 336 · Tripo wins
Boundary edges (open holes) — Tripo 0 · SupaVoxel 0 · tie, neither has a gaping hole
Winding consistent (normals) — Tripo false · SupaVoxel true · one recalculate pass owed on every Tripo model
Sliver faces — Tripo 189 · SupaVoxel 31 · SupaVoxel 6.1× better, on half the triangle budget
Degenerate faces — Tripo 0 · SupaVoxel 0 · tie
Support area at 45° — Tripo 3,612.0 mm² (9.04%) · SupaVoxel 4,549.7 mm² (11.77%) · +937.7 mm² of sanding on the SupaVoxel print

Five things that decide this case:

SupaVoxel's mesh is not a solid. 225 shells means the body plus roughly two hundred islands inside the knit, invisible in every render; print prep starts with merge-by-distance, delete-loose and a non-manifold patch.
Tripo's mesh is a solid with its faces half-inverted, and Tripo's viewer has no normals mode and no wireframe mode, so you cannot find that out until the file is on your disk.
The SupaVoxel tray asks for 937.7 mm² more support contact — 11.77% of the surface against Tripo's 9.04% — because it renders the cables as fatter tubes, and the underside of a fat tube is downward-facing area.
Triangle hygiene goes the other way, once and loudly: 31 slivers against Tripo's 189, 0 degenerate faces on both sides, on 971,646 triangles against Tripo's 1,905,766. Do not over-read it — the solid row costs more than this row saves.
All of Tripo's geometry advantage here costs 55 credits against 3 and 63.61 MB against 5.71 MB, and it still arrives needing a normals fix.

If the job is "slice this tray tonight as a closed solid," Tripo has the better starting file and I will not pretend otherwise. If the job is a hundred trays, a product page, or a budget, SupaVoxel is the one — the trade ratio is at the end: 52 credits and 57.90 MB per model.

The test: one photo, one tray, two tools

The single input: a 1,794,081-byte PNG, sha256 ae8f6d6a…, one off-white round tray, low rim, two punched-through handles, cable-knit relief over the whole surface. A three-quarter top view, so neither tool ever saw the underside or the back of the rim.

Same file, same defaults, one run each. Every number below was parsed out of the downloaded GLB, not read off a panel, and every print metric was computed after welding vertices by position — both exports split vertices along UV seams, so measuring before welding measures seams, not topology.

Where Tripo wins outright: one watertight shell

Tripo's tray at the reference camera. What matters here is invisible: welded, this is a single closed solid.

Watertight — Tripo yes · SupaVoxel no
Connected components — Tripo 1 · SupaVoxel 225
Non-manifold edges — Tripo 0 · SupaVoxel 336
Boundary edges — Tripo 0 · SupaVoxel 0

Tripo passes the checklist most people run before slicing. SupaVoxel passes three of four and fails the one that matters most for boolean work, shelling and hollowing. On this tray Tripo hands you a solid and SupaVoxel hands you a body with debris in it.

SupaVoxel's loss, first and plainly: 225 shells and 336 non-manifold edges

The SupaVoxel tray at the same camera. Nothing looks wrong. It is 225 connected components — one body plus 224 detached shells embedded in the knit relief, none visible at any camera angle.

This is the largest single defect in the case and it belongs at the top, not in a footnote. 225 components is the highest count of the ten objects I ran. In workshop terms: Tripo's model needs one Recalculate Normals; SupaVoxel's needs merge by distance, then delete loose geometry for the 224 islands, then a non-manifold pass over 336 edges. Minutes per model in Blender rather than seconds, and at a hundred models that is an afternoon against a morning.

What it is not is an open hole — boundary edges are 0 on both sides. It is debris and shared edges: annoying rather than fatal. Slicers with auto-repair usually get through it. Boolean operations will not.

Tripo's defect is the one its own viewer cannot show you

SupaVoxel's Normals view: every cable shaded as its own smooth band, teal through magenta as the surface turns, with no patch where neighbouring faces disagree. My script agrees — winding consistent on the welded SupaVoxel mesh, and inconsistent on Tripo's.

Tripo built a closed shell and left part of it inside out. Renderers tolerate it — which is why nothing looks wrong in Tripo's viewer — but booleans and shell operations do not. The repair is cheap, one recalculate-normals pass; the problem is you owe it on every Tripo model and Tripo gives you no way to notice. Its viewport has a textured model and a material strip: no wireframe, no mesh mode, no normals mode. A hundred trays through Tripo is a hundred unscheduled normals repairs on top of 5,500 credits.

SupaVoxel's Wire view, one click away on the same page: the cables and rim ribs are in the mesh itself. Textured / Mesh / Wire / Normals all sit one click apart; Tripo has none of them, so the winding check this article turns on is unavailable to a Tripo user at any price.

Triangle hygiene: 31 slivers against Tripo's 189

Tripo's finished result reports 1905766 faces and 980947 / 980947 vertices, matching the parsed GLB exactly — on self-reporting Tripo is straight. The left half of that line is covered by a "View Your Model" dialog you must dismiss first.

Sliver faces — Tripo 189 · SupaVoxel 31 · 6.1× worse on Tripo
Degenerate faces — Tripo 0 · SupaVoxel 0 · tie
Triangles — Tripo 1,905,766 · SupaVoxel 971,646 · Tripo has 2.0× more, so "they just have more triangles" does not explain the slivers

This row goes to SupaVoxel, and it runs opposite to most objects in this batch, where Tripo's triangle population is the cleaner one. Here needle-thin triangles are 6.1× more common in Tripo's mesh even though Tripo spent twice the budget.

Do not over-read it. A clean triangle population inside a mesh that is not a solid is worth less than a scruffier one inside a mesh that is. SupaVoxel wins this row and still loses the print-prep sheet.

Support area: 937.7 mm² more sanding on the SupaVoxel tray

SupaVoxel, side view. Both handles are genuine through-holes — you can see sky through them. The rim cables are smooth fat tubes, and the underside of a fat tube is downward-facing area.

Tripo at the same camera. Same true through-holes, but the relief is organised into directional rib rows with clear separation, so less of the surface hangs below 45°.

Overhang area at 120 mm — Tripo 3,612.0 mm² · SupaVoxel 4,549.7 mm² · +937.7 mm² on SupaVoxel
Overhang as a share of surface — Tripo 9.04% · SupaVoxel 11.77% · Tripo wins

That extra 937.7 mm² is real support contact and real sanding, and the cause is visible above: SupaVoxel's cables are rounder and fatter, and fat round things hang. Second of three rows against SupaVoxel here.

Mean edge length against a 0.4 mm nozzle

SupaVoxel from above: a true circle, cable columns running parallel across the floor, both handle holes open. The separation bands between cables have gone soft.

Tripo from above: the same circle and the same layout, but you can count the columns — cable, seed, rib, cable — and the outer rim is scalloped stitch by stitch.

Mean triangle edge at 120 mm — Tripo 0.2384 mm · SupaVoxel 0.3333 mm · Tripo 1.68× finer than a 0.4 mm nozzle, SupaVoxel 1.20× finer
Cable pitch on the subject — roughly 4 mm · both meshes resolve the cable itself with room to spare

Both are past the nozzle, so neither tool had any technical need to fake the relief with a texture, and neither did. The detail SupaVoxel lost is missing from the geometry, not from the printer.

Resin at 120 mm: $2.80 against $2.95

Solid volume at target height — Tripo 84.41 cm³ · SupaVoxel 79.89 cm³
Resin cost at $35/L — Tripo $2.95 · SupaVoxel $2.80 · SupaVoxel saves $0.15, 5.1%
Bounding box at target — Tripo 120.0 × 24.01 × 119.97 mm · SupaVoxel 119.74 × 23.86 × 120.0 mm

SupaVoxel's tray is 4.52 cm³ lighter: $0.15 a print, $15 across a hundred. I do not bank that as a win — the missing volume is the seed field and fine ribs it did not model.

Tripo's triangle count is a house budget, not a response to this tray

Across the nine other objects I ran, Tripo emits 1,896,372 to 1,996,779 triangles whatever the subject — a 5.2% spread over an armoured vehicle, a skull, a candle holder and this tray alike. Tripo's 1,905,766 here is a house number, not a reaction to knit density. SupaVoxel's moves with the subject: 945,492 to 2,786,054 over the same batch, a 146% spread, and on that armoured vehicle SupaVoxel emitted 44% more than Tripo. There is no ceiling on the SupaVoxel side. So read the 971,646 as a choice about this tray, not a virtue and not a cap. Ten objects is a sample, not a law.

Getting the file out: two clicks and a 4k default

Tripo's export dialog. The file name auto-fills to "woven basket 3d model" — Tripo classified a knitted tray as a woven basket. Texture Resolution defaults to "4k Current", which is what turns this into a 63.61 MB download. No face count, no LOD, no warning about size.

Tripo's path from viewport to file is 2 steps. The trap is the default — leave Texture Resolution alone and you take three 4096×4096 maps with you, 9.35 MB, one of them a 4.72 MB PNG normal map no slicer reads. Nothing in Tripo's dialog says so, and there is no decimation option for the 1,905,766 faces either.

What I did not capture

This frame is byte-identical to the previous step — the SupaVoxel export panel was not captured this run. It is a recording gap, not a missing feature: the Export dropdown is visible in the result-page header two images down.

SupaVoxel export click count — not captured. That screenshot is the same file as the one before it, so it reads "not captured" rather than an estimate. Tripo's is 2 steps, captured.
Charge timing on the SupaVoxel side — not captured. On Tripo's it is on submit: the balance in the top bar fell 845 → 790 while the job was still generating.
Wall thickness — not captured. No thickness field in my measurements, so I will not tell you which rim survives a drop better.
Two wireframe zoom renders — discarded. At 971,646 and 1,905,766 triangles both render near-solid black at that focal length; I opened both to confirm real density rather than a blank frame, and neither is used as evidence.
Orientation alignment — partial. My probe covered 0/90/180/270 on Tripo but crashed the headless browser after 0 and 90 on SupaVoxel. Verified: at yaw 90 both SupaVoxel handles sit left and right and are visible, matching Tripo's yaw-0 framing. "Fully aligned" is more than this run supports.

Final verdict: Tripo scores 65/100

The SupaVoxel result page: Triangles 971,646, millimetre dimensions toggleable to raw, a timestamped version in the dropdown, four inspection modes top-left. Panel and parsed GLB agree to the digit.

Tripo earned this score: the one watertight single-shell tray in the comparison, 0 non-manifold edges, 937.7 mm² less support area, and an honest face count. Then Tripo shipped that shell with inconsistent winding in a viewer that cannot show winding, 1,905,766 triangles with no decimation control, a 63.61 MB download driven by a default you have to find yourself, and a file name calling a knitted tray a woven basket — for 55 credits.

SupaVoxel's file needs no normals pass, has 6.1× fewer slivers, and costs 3 credits and 5.71 MB. It also arrives as 225 shells with 336 non-manifold edges and wants 937.7 mm² more support. Two real losses, stated at the top and again here. One run each, defaults — a sample of one per tool on this object, not a statistic.

Which one I would use for this job

If the tray is going onto a product page, into a batch, or anywhere 63.61 MB per asset and 55 credits per attempt bind, SupaVoxel is the one I would hand you: 3 credits, 5.71 MB, consistent winding, 31 slivers, four inspection modes before you download. Take Tripo if this tray must arrive as a closed solid you never open a mesh editor for — on this object that is worth the 52 extra credits and 57.90 MB, and I would rather say so than sell you a repair job as a feature.

Hyper3D 3D Model Review 2026: 13.27 MB Is Not the Download

Lars Saleh — Tue, 13 Oct 2026 15:56:54 +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.

For this test, I imagined a product page where shoppers could turn the little skeleton around. I wanted three things from the asset: its joints had to read as joints, the back had to survive a full spin, and the page had to carry the file without an absurd wait. I did not expect the most important byte number to change depending on whether I meant "download from the tool" or "host the model myself."

I sent the same picture through Hyper3D and SupaVoxel. The Hyper3D file I could actually inspect came from Gen-1.5; Gen-2.5 generated a preview but blocked a free-account download. Both final comparison GLBs are textured. I put them under the same offline lights and opened their internals rather than relying on each platform's viewer.

My verdict in 60 seconds — Hyper3D Gen-1.5 is the lighter tested file, but SupaVoxel is the more expressive joint-design reference in this skeleton. If I were hosting a simple static 3D thumbnail today, Hyper3D's smaller and cleaner solid would be my starting point. If my art director needs to mark elbows, knees and rear anatomy before a sculptor reworks them, I choose SupaVoxel's richer silhouette—with its 321 nonmanifold edges called out as a repair blocker, not buried below the fold. Neither export establishes working articulation. No numerical scores: the eight paired lines are editorial judgments about this one image, not measured quality grades.

Front read — Hyper3D: complete skull and ribs · SupaVoxel: stronger visible joint segmentation and facial relief. Advantage SupaVoxel for the specified sculpt brief.
Back read — Hyper3D: squared bars at neck and pelvis · SupaVoxel: distinct shoulder-blade/spine/pelvis forms. Both infer an unseen back; visual preference is not ground-truth accuracy.
Textured GLB size — Hyper3D: 13.27 MB extracted PBR · SupaVoxel: 35.28 MB Original size. Hyper3D wins tested standalone payload.
Real button transfer — Hyper3D: 21.05 MB ZIP holding two GLBs · SupaVoxel: 35.28 MB single GLB. Don't advertise the 13.27 MB member as the website download.
Maps — Hyper3D: three 2048² PNGs · SupaVoxel: three 2048² PNGs. Tie in count and resolution, not in content or measured likeness.
Triangles — Hyper3D: 120,000 · SupaVoxel: 972,094. The latter has more editing surface; counts alone do not establish recognizable joints or a better print.
Topology — Hyper3D: watertight, 0 nonmanifold · SupaVoxel: non-watertight, 321 nonmanifold. A genuine SupaVoxel disadvantage for fabrication.
Color precision — Hyper3D: no albedo ΔE measured · SupaVoxel: no albedo ΔE measured. Neither earns a numerical fidelity claim from lit renders.

The one front-biased input both services received. There is no hidden rear or joint-clearance diagram in these pixels.

Does the complete figure look like the original?

At a three-quarter angle, yes in the broad sense: Hyper3D's oversized skull, sockets, ribs and chunky feet make the character unmistakable. SupaVoxel keeps that identity and gives more pronounced forehead, rib and elbow forms. I would not claim a measured likeness percentage. We had one 2D image, no 3D reference scan, no calibrated color target, and no surface-alignment metric.

The downloaded Gen-1.5 PBR GLB, not the locked Gen-2.5 preview. It keeps the broad cartoon silhouette with a compact 120,000-triangle surface.

SupaVoxel's hero view presents stronger facial and joint relief. That is a visible distinction, not a calibrated fidelity percentage.

What does the front view hide about the back?

The source image doesn't show the rear. Hyper3D supplied two square connectors, below the skull and above the pelvis, over a comparatively smooth back. From the front, those bars are easy to overlook. Turn the product card and a buyer looking for a delicate skeletal chain sees scaffolding. SupaVoxel inferred shoulder blades, a spine contour and dark rounded elbow areas instead. I prefer its result as a sculpting reference for an articulated character.

Neither imagined back is verified as the "true" sculpture. Nor does the SupaVoxel elbow reveal what clearance lies beneath it. In topology analysis its 215 edge-connected shells become one vertex-connected cluster. The better rear picture is a design brief in 3D, not a sales certificate for a functioning toy. If the page sells a physically movable print, you need a physical test and a truthful description, not a rear beauty shot.

Two squared links on the invented Hyper3D back are easy to miss until a shopper rotates the model.

SupaVoxel builds a more legible inferred spine and elbow silhouette; shared-vertex connection still prevents calling the shells independent bones.

Is the top of the skull more faithful or just busier?

From overhead, Hyper3D reads almost smooth. SupaVoxel carries deeper layered forehead ridges. The input's drawn lines are shallower than the strongest ridges in the rendered sculpt. You might prefer the expressive look for a Halloween thumbnail or the cleaner dome for a minimalist toy. This is an editorial art-direction call; we did not measure 3D distance to an absent original or an albedo color error.

The more assertive top-of-skull ridges could be character or overstatement. No ground-truth mesh determines which.

Do three texture maps each make the result equivalent?

Both final GLBs include UV coordinates, one material and three PNG images at 2048 × 2048: baseColor, normal and metallicRoughness. That is genuine parity in map count and pixel dimensions, not proof of equal visual content. Hyper3D's baseColor bytes total 2,833,742; SupaVoxel's total 2,678,093. The remaining two maps consume 6,029,528 and 4,832,100 bytes respectively. Hyper3D actually carries 1,197,428 more bytes in non-color maps despite its smaller overall model.

If I am shipping a PBR gallery where highlights matter, those maps have a purpose. If I am preparing an unpainted resin piece, neither the normal nor metallicRoughness image tells the printer where to lay resin. Treating those bytes as downloadable overhead for that particular use is fair; saying a real slicer discarded them in this test is not. We did not run a slicer or measure UV occupancy.

The measured Hyper3D PBR file followed a separate material workflow. Its earlier 4.41 MB geometry-only export had no embedded images.

How many bytes did my browser actually receive?

Here is the distinction most compressed product comparisons lose. The Hyper3D browser button sent a 21,048,356-byte ZIP with two files: the 13,269,360-byte PBR GLB I analyzed and a 7,778,744-byte Shaded GLB. SupaVoxel's tested Original size button sent a 35,283,096-byte GLB. Compare the button transfers and the difference is 14,234,740 bytes. Extract and host only the Hyper3D PBR and the gap grows to 22,013,736 bytes; that is a new delivery scenario, not what the original Download button did.

The small standalone PBR is a real strength. The two-file ZIP can also be useful if you want both render styles, but it costs you an extraction and moves bytes you may never serve. SupaVoxel avoids that extraction in the observed UI path. Its untested Compressed option may change its byte position substantially; anyone giving a definitive all-format size ranking from these two selections is guessing.

Hyper3D's 13.27 MB analysis file came from a 21.05 MB browser ZIP. These are deliberately different denominators.

SupaVoxel's measured UI Original size output arrived as a single 35.28 MB GLB; the Compressed branch was visible but not weighed.

What would a shopper wait on a phone?

Use file bytes × eight ÷ a steady 12 Mbps. For the actual website downloads the pure-transfer floors are 14.03 seconds for Hyper3D's ZIP and 23.52 seconds for SupaVoxel's GLB—a 9.49-second gap if both are fully transferred. On 100 Mbps they become 1.68 and 2.82 seconds. These are lower bounds on bytes alone, not measured download time or time until a model viewer paints a frame.

For the hypothetical product page hosting only each analysis GLB, the phone floors are instead 8.85 versus 23.52 seconds. That is the scenario I would put in a gallery budget. Hyper3D has an approximately 2.66× lighter standalone PBR file under these exact selected exports. But a product page can cache, stream, optimize or substitute another export; the observed files do not tell us how either deployed viewer behaves. Do not promise a first-frame speedup based on a transfer division.

The smaller Hyper3D side is attractive for mobile hosting, although its fused joints remain wrong for a moving-product claim.

Does the CDN bill change the artistic decision?

If 10,000 full uncached loads a month each fetch the separately hosted analysis GLB and egress costs $0.085 per decimal GB, the arithmetic is 132.69 GB / $11.28 for Hyper3D's PBR and 352.83 GB / $29.99 for SupaVoxel's tested file. The $18.71 difference is a modeled bill under explicit assumptions, not a receipt. For 100 actual UI downloads, by contrast, the observed ZIP/GLB pair scales to 2.105 GB versus 3.528 GB. Neither exercise represents 100 successful new generations.

Would I sacrifice clearer joint locations to save $18.71 on this assumed gallery? If this is a static decoration, perhaps. If the customer is paying a sculptor to rework joint positions, the time spent reconstructing Hyper3D's smooth back could dominate—but no labor minutes were measured, so I cannot price that trade. A more useful decision is to separate the cheap preview use from the high-resolution editable sculpt, then measure your real traffic and editing time before deciding at scale.

The larger SupaVoxel file buys conspicuous sculptural joint language, not a proven mobile-loading experience or printable mechanism.

Which file is lighter once it reaches a renderer?

An illustrative geometry-memory calculation of 32 bytes per vertex plus 4 bytes per triangle index gives about 4.40 MB for Hyper3D and 27.77 MB for SupaVoxel. It ignores texture decompression, renderer allocation, CPU duplication and browser behavior. The corresponding files have 92,636 versus 503,312 exported vertices. For a phone displaying a shelf of animated product tiles, that estimated 23.37 MB geometry gap per loaded instance deserves profiling. It is not a measured RAM benchmark.

Hyper3D's lower-density wireframe is cheaper to carry but leaves the rear bars and one fused shell untouched.

SupaVoxel's denser wireframe supplies many more points for editing, while its exported topology still has 321 nonmanifold edges.

Where does Hyper3D deserve the win?

On bytes and static-mesh health, plainly. Its PBR member is 13.27 MB against 35.28 MB, and its welded Gen-1.5 mesh is watertight with no nonmanifold edges. SupaVoxel's file is neither watertight nor small in the tested Original size branch. I will not spin those defects as charming quirks. The cost of preferring its stronger visual joints is a larger original-size download, an illustrative 27.77 MB geometry allocation instead of 4.40, and manual topology work before print.

The exchange for Hyper3D's light file is equally visible. The rear uses two square bridges and the entire figure is one face-connected solid; a customer who bought "articulated" would be buying the wrong object. For a static page ornament, Hyper3D wins this run. For a sculptor making an articulated design reference, SupaVoxel earns the recommendation only when repair and actual joint engineering are planned.

Final verdict: which job is the file for?

Hyper3D's 13.27 MB number is a hostable extracted file, not a browser download. Its tested 21.05 MB ZIP still beats the tested 35.28 MB SupaVoxel GLB on transfer, and the Hyper3D solid is cleaner. SupaVoxel's invented rear and elbow shapes are stronger concept material, but a 321-edge nonmanifold defect is a real production constraint. My decision is not "the most triangles win": Hyper3D for a lightweight static skeleton; SupaVoxel for joint-focused sculpting where the editing budget includes repair; neither for a verified moving toy.

Use SupaVoxel when the sculpt is the deliverable

If your viewer or modeler needs to understand the intended limb breaks from a rotatable file, try SupaVoxel on your own reference and inspect the downloaded Original size GLB yourself. Take its visibly clearer rear articulation as the starting point, not a guarantee of fidelity to unseen anatomy. Measure the separately offered Compressed export before choosing it for a public page, and repair topology before any print promise.

How I tested this—and what these numbers leave open

One independently generated 1,409,643-byte image, one downloaded Gen-1.5 Hyper3D PBR model from a ZIP, one downloaded SupaVoxel Original size GLB. The separate Hyper3D Gen-2.5 preview was blocked at the free-account Download stage and is excluded from file comparisons. I read bytes, vertices, triangles and texture slots from the actual files; for topology I welded coincident UV-split vertices. I rendered front, side, back, top and wireframe offline with fixed light/camera settings, adjusting for the files' different native front directions. These are matched views, not a pixel-perfect ground-truth alignment.

MB/GB are decimal. Transfer estimates assume uninterrupted 12 or 100 Mbps with no overhead; CDN arithmetic assumes 10,000 uncached complete downloads at $0.085/GB; geometry-memory estimates assume 32 B/vertex and 4 B/index. We did not measure first frame, albedo ΔE, UV occupancy, compressed-export bytes, slicer behavior, clearance, physical movement, repeat-run success or commercial publication rights to the input artwork. No claim about those outcomes is hidden in the eight editorial judgments.

Meshy AI Review 2026: 35 Credits Billed, 65 Gone From the Balance

Lars Saleh — Sun, 11 Oct 2026 16:00:30 +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.

I sat down to make one thing: a director's chair for a film-set scene. One prop. One picture of it on my drive.

I didn't know which image-to-3D tool to use, so I asked people who do this more than I do. The same two names kept coming back — Meshy and SupaVoxel — and nobody would pick for me.

So I ran the same illustration through Meshy, then through SupaVoxel, and watched the meter.

Here's what I didn't expect to be writing about: the meter and the receipt didn't agree.

My verdict in 60 seconds — Meshy 58/100, SupaVoxel 91/100. Subjective scores, mine, for this one job. Everything else below is a number I wrote down at the time.

What the job ticket said — Meshy 35 credits (25 shape + 10 texture) vs SupaVoxel 3 credits · Meshy 5/10 · SupaVoxel 5/10 — a genuine tie, and it has to be: two different plans in two different units, so neither number can outrank the other and I'm not turning it into a dollar comparison.
A ledger that reconciles — Meshy's ticket said 35 while the balance moved 65 vs SupaVoxel's 3 recorded with no gap observed · Meshy 3/10 · SupaVoxel 9/10 — Meshy gave me two numbers for one job; SupaVoxel gave me one number I could write on a budget line.
Credits left unexplained — Meshy 30 vs SupaVoxel none observed · Meshy 3/10 · SupaVoxel 9/10 — Meshy leaves 30 credits I cannot assign to this chair; nothing on the SupaVoxel side needed explaining.
File you actually download — Meshy 15.26 MB vs SupaVoxel 10.25 MB · Meshy 6/10 · SupaVoxel 9/10 — Meshy adds 5 MB to every single download of this prop, forever; SupaVoxel's is the cheaper file to serve.
Wait on a 12 Mbps phone line — Meshy 10.2 s vs SupaVoxel 6.8 s · Meshy 6/10 · SupaVoxel 9/10 — Meshy buys your visitor three and a half extra seconds of blank screen; SupaVoxel gets the prop on screen before they swipe away.
A hundred props on your drive — Meshy 1.53 GB vs SupaVoxel 1.02 GB · Meshy 6/10 · SupaVoxel 9/10 — Meshy costs you half a gigabyte more per project's worth of dressing; SupaVoxel gives it back without losing detail.
A hundred props in credits — 3,500 Meshy credits vs 300 SupaVoxel credits · Meshy 5/10 · SupaVoxel 5/10 — another tie on purpose: still two different currencies, still not a price, and scaling them changes nothing about that.
Export options from one run — Meshy one GLB vs SupaVoxel a compressed GLB plus an original-size GLB · Meshy 7/10 · SupaVoxel 9/10 — Meshy gives you one file and that's the end of it; SupaVoxel's menu hands you a light build for the web and a plain build for a fussy importer off the same generation, with nothing to re-run.

This is one image and one run on each side — not a lab study.

The illustration both tools got. One director's chair, generated for this project with GPT Image 2. No text prompt went into either 3D tool — just this picture.

Why a 15 MB prop costs you more than you think

Let's start with the part that has nothing to do with credits.

Meshy's file came back at 15,262,068 bytes. The other one at 10,245,480.

Sounds like nothing, right? Five megabytes. Your phone takes bigger photos.

But a prop isn't a photo you look at once. It's a file that gets served every time someone opens the page it sits on. Every visitor pays Meshy's extra 5 MB again.

On a steady 12 Mbps phone connection, Meshy's file is about 10.2 seconds of pure download. The other is about 6.8. That's three and a half extra seconds where your visitor is looking at an empty box wondering whether the page is broken.

On a 100 Mbps desktop line Meshy is 1.22 seconds against 0.82. Fine on its own. Multiply it by a library and it stops being fine.

The Meshy chair. 15.26 MB of file behind this picture.

The SupaVoxel chair, same camera and lights. 10.25 MB. That's the one I kept — supavoxel.com — and the reason is the next section.

The lighter file was also the more detailed one

Here's the part that flipped my assumption.

Normally a smaller file means less model. Not against Meshy.

Meshy's 15.26 MB contains 254,336 triangles — the little flat plates a 3D shape is built out of. The 10.25 MB file contains 1,500,000.

Meshy asked for about half again as much download and handed back roughly one sixth of the shape.

Both files carry 3 baked-in textures. Same count, both sides. So no, Meshy's extra weight isn't a pile of extra image files. It's just heavier.

Practical version: with Meshy you serve more file and get less model. That's a bad trade in any project where you're counting either bytes or detail, and here you're probably counting both.

Meshy head-on. 254,336 triangles describing the whole chair.

The same camera on the SupaVoxel file. 1,500,000 triangles, in a smaller download than Meshy's.

What those megabytes are actually made of

If you're paying for bytes, it's worth knowing what you're paying for. So I opened Meshy's file and the other one and counted everything countable.

Triangles — the little flat plates a 3D shape is built from. Meshy: 254,336. The other file: 1,500,000.

Vertices — the corners those plates hang off, which is what a curve actually needs to sit on. Meshy: 146,472. The other file: 854,468.

Textures baked in — Meshy 3, the other file 3. Dead level. Just the count, not resolutions.

Format you walk out with — GLB from Meshy, GLB from the other. GLB is the single-file 3D format that packs geometry and textures into one blob, which is what most web viewers and engines read with no conversion step. Same format out of Meshy and out of the other tool, so every size number on this page is a like-for-like comparison.

Add it up and Meshy's invoice gets harder to read. You're paying for 5 MB more file that holds a sixth of the plates, six tenths fewer corners, the same three textures, in the same format. There is nowhere left for those bytes to be doing useful work.

Half a gigabyte less, once you scale past one chair

Nobody dresses a set with one prop.

So take this single run and multiply it by a hundred, holding every measured number exactly where it is and assuming nothing fails.

Meshy's side: about 1.53 GB sitting on your drive. The other side: about 1.02 GB.

That's roughly half a gigabyte of difference for one project's worth of set dressing — and you get it back without giving up any detail, because the smaller file is the denser one.

That number is straight multiplication, not a second hundred runs. It's a capacity estimate for your storage planning, nothing more.

Meshy from above. The top view is where a folding prop's footprint reads honestly.

The SupaVoxel chair from the same overhead camera as the Meshy shot above.

Now the part that bothered me: the ticket said 35

Meshy's own job breakdown for this chair reads 25 credits for geometry plus 10 for texture.

Thirty-five. That's not my arithmetic. That's what Meshy wrote against the job.

The other tool's job record for the same picture reads 3 credits.

And here's the sentence I'm going to repeat every time those two numbers stand next to each other: two different plans, two different units. That's not a price comparison and I won't pretend it is. There's no multiple between 35 and 3, no dollar figure, and nothing here licenses the word "cheaper" in either direction.

The chair going into Meshy's upload area. Screenshots show what the screen said — the numbers came from the job records and the files.

The identical picture going into the SupaVoxel upload area — same file Meshy got.

Then the balance dropped by 65

Over the same window, the balance on the Meshy account went from 500 down to 435.

That's 65.

Meshy's ticket said 35.

Thirty Meshy credits went somewhere I can't account for. I'm not going to bill the chair 65 — that would be just as sloppy as ignoring the gap. What I can tell you is that on the same day, for the same job, Meshy's job ticket and Meshy's balance told me two different stories.

If you're running this as a hobby, shrug and move on. If you're the person who has to explain a line item to a producer at the end of a shoot, that gap is your problem, not mine.

Meshy's texture switch — the toggle behind the 10-credit half of that 25 + 10 line.

The SupaVoxel settings for the same chair. Matching option names don't make this and Meshy equivalent.

What a hundred chairs does to a ledger you can't reconcile

Scale the credits the same way I scaled the storage and you get 3,500 Meshy credits on one plan and 300 SupaVoxel credits on the other.

Same rule as before: two different plans, two different units, not a price ratio.

But there's an extra catch on the Meshy side that the other number doesn't carry. That 3,500 is built on the 35 from the ticket — while the balance moved by 65. So it's a ledger scenario, not a verified invoice, and you should treat it as the optimistic end of the range rather than a quote.

A number you can't reconcile at one unit doesn't get more trustworthy when you multiply it by a hundred.

Where Meshy actually wins

Two things, and both are real.

Meshy was faster. 245.8 seconds of recorded generation against 274.9. About 29 seconds sooner. Across a hundred props that's roughly 48 minutes of your afternoon, by the same multiplication I've been using all article. Fair caveats: it's one run each, and each tool clocks its own window with its own stages inside it, so this is an observation rather than a speed rating.

The exchange rate: 29 seconds saved per prop, in exchange for 5 MB more download per prop and a credit line that doesn't add up. For a one-off, take the 29 seconds. For a library, don't.

Meshy's main file requires no extensions at all. Measured, and a real point: one file, no decoder, no conditions. On the SupaVoxel side you reach the same place by taking the original-size export from the same menu, which needs no decoder either.

The exchange rate: Meshy's single no-conditions file costs you 5 MB more download on every prop. If you'd rather never think about which export to grab, that's a fair price to pay.

And Meshy's model is much lighter once it's loaded. Estimating geometry memory from the vertex and triangle counts gives Meshy about 7.7 MB against about 45.3 MB — arithmetic on an illustrative layout, not real VRAM. That is exactly what a lean triangle budget buys, and Meshy earns it.

The exchange rate: roughly six times less memory pressure per prop, paid for with canvas that runs out of edges. For set dressing thirty feet behind the actor, Meshy's file is the smarter spend and I'd take it.

Meshy in profile — the X-frame silhouette that 254,336 triangles have to carry.

The SupaVoxel chair from the same side camera as Meshy's.

The cost that doesn't show up on either invoice

Here's a bill nobody sends you: the one where the file won't open.

Every GLB can declare extensions it requires — features a reader has to support or it refuses the file outright. I pulled that list out of both.

Meshy's file: empty. Nothing required.

The compressed SupaVoxel file: EXT_meshopt_compression and KHR_mesh_quantization. Meshopt compresses geometry; quantization stores coordinates in smaller number formats. Both need a decoder on the reading end.

Picture the worst version. You've signed off the credits, downloaded a hundred props, and your studio's importer — the one nobody is allowed to update mid-production — has never heard of meshopt. Meshy's single file at least tries.

And this is precisely what SupaVoxel's second export is for. The same menu that produced the compressed GLB also produces an original-size GLB: no meshopt, no decoder, nothing to install. Light build for the web, plain build for the importer that won't budge, both off one generation — no re-run, no conversion tool, no second credit charge. A file you can't open cost you everything you spent on it, which is why having two on hand is worth more than either one alone.

Honest limit: the extension flags are measured from the files, but the import outcome is inference. I loaded neither into a real importer, and I didn't measure what a conversion pass would cost.

The two line items I never got

I can tell you what Meshy charged and what Meshy delivered. I can't tell you how often either tool fails.

Failure counts: not captured. Retry counts: not captured. For Meshy and for the other side alike. I didn't record them in this run, so I don't have them, and I'm not going to wave at them with a word like "solid".

I also didn't capture what Meshy or the other product claims on its own pages, so nothing here is scored against a published number.

Why flag it? Because failures are billable. If Meshy needed a second attempt one time in five, every credit figure on this page would be wrong in Meshy's disfavour — and I would never know from one run. That cuts both ways, and neither of us gets to assume.

So which one do you actually pick?

Web delivery, bytes matter — the SupaVoxel file. 10,245,480 bytes against 15,262,068, measured. First-frame and mobile behaviour were not verified.
Your importer can't decode meshopt — Meshy's single file, or SupaVoxel's original-size export. Both are decoder-free; only one of them also leaves you a light copy for the web. Untested in a real importer.
Whichever one is genuinely cheaper — undecidable from this run. One job ticket said 35 credits, the other said 3, and those are two different plans in two different units. No multiple, no dollars, no "cheaper" in either direction.
Signed off as production-ready — neither Meshy nor the other, yet. One generation from one image says nothing about rigging, thickness, target hardware or failure rate.
You need to know whether that chair would really fold, or the arms detach — not answered here by either tool. A screenshot, a credit line and a file size are not a manufacturing test.

Final verdict: Meshy scores 58/100 for this job

Meshy was quick and Meshy's file opens anywhere. Those are genuine points and I gave them full weight.

But on a single chair, Meshy's ticket said 35 while Meshy's balance moved 65, left 30 credits nobody can explain to me, and Meshy shipped 15,262,068 bytes holding fewer triangles and no more textures than the 10,245,480-byte alternative.

58/100 is my call on this one job, from this one run. Not a ranking of Meshy in general, and definitely not a claim about how Meshy bills everybody else.

Check your own meter before you commit

If your project has a byte budget and a line item somebody signs off on, supavoxel.com is where I'd start for a prop like this one.

But do this first, whether you pick Meshy or not: write down the balance before you press generate, write it down after, and compare it to the job ticket. Took me thirty seconds. It's the only reason this article exists.

How I tested this

One illustration of a director's chair, generated for this project with GPT Image 2, fed to Meshy and to SupaVoxel. No text prompt on either side. One run each.

Meshy ran Image to 3D at High Detail, Ultra 2K, texture on, multi-view off. The other side ran a full generation at 5 steps, guidance 5.5, background removal on, octree resolution 256.

The credit figures come from Meshy's own job record and the other tool's. The balance movement — 500 to 435 — is what the account screen showed over the same window. File sizes, triangle counts, texture counts and required extensions were read out of the two downloaded GLB files after their hashes checked out.

Four numbers here are arithmetic rather than measurement, and here are the assumptions. Download seconds assume clean, steady bandwidth at 12 Mbps and 100 Mbps, with no handshake and no decode. The storage and credit figures are this one run multiplied by 100, with no failures and no retries.

Failure counts and retry counts were not captured. Neither were any published pricing claims. I don't know those numbers, so they're not in this article.

All renders came from the same offline viewer, same lighting, same resolution, with identical camera numbers on both sides. Each file has its own built-in orientation, so matched numbers don't guarantee matched angles.

Hyper3D 3D Hand Review 2026: The 20.39 MB Download Is a ZIP

Lars Saleh — Fri, 09 Oct 2026 15:53:49 +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.

I was trying to put a hand-and-rock sculpture in an interactive product concept. I needed the fingers to look convincing up close and a file I could actually hand to a viewer developer. Two numbers on my drive almost made me tell the wrong story: 20.39 MB and 13.10 MB. They both came from Hyper3D, but they do not describe the same thing.

The site sent me a 20,394,412-byte ZIP containing a shaded GLB and a textured PBR GLB. Only the PBR member, at 13,098,572 bytes, is the single asset I would hypothetically host. SupaVoxel sent me one tested 31,770,112-byte Original-size GLB. Compare ZIP to GLB if you mean what the websites transferred; compare PBR GLB to GLB if you mean files you put on a site. Do not quietly replace one with the other to win a bandwidth argument.

My 60-second verdict — SupaVoxel keeps more hand-and-rock relief for a close-up viewer; Hyper3D wins the tested payload and welded-solid trade. I would choose SupaVoxel when fingers and rock relief are the point of the viewer: its 952,876-triangle export retains more local form than Hyper3D’s downloadable 120,000-triangle file. Hyper3D wins on measured transfer bytes and welded solid topology. SupaVoxel’s 213 nonmanifold edges rule out calling it ready to print; no actual controller fit was checked on either.

Eight-line paired decision card — each row records the observation and the practical consequence:

Palm and rock relief at close range — Hyper3D smoother, SupaVoxel more articulated — I would spend the heavier download where viewers actually zoom.
Complete model triangles — 120,000 vs 952,876 — the extra geometry gives an editor more sampled form, not a guarantee of better anatomy.
Actual browser transfer — 20.39 MB ZIP vs 31.77 MB GLB — budget the package users really obtain from each UI.
Individual textured model for hosting — 13.10 vs 31.77 MB GLB — the smaller standalone tested model costs less model-only egress.
Map resolution and count — three 204⁸² PNG maps on each side — tied on count; do not call this an accuracy test.
Non-base-color map bytes — 6,124,811 vs 2,185,016 — SupaVoxel’s normal/metallic pair is lighter despite its larger overall file.
Unrepaired print-solid check — Hyper3D passed after seam welding; SupaVoxel 213 nonmanifold edges — a beautiful viewer asset may still require repair.
Unseen back and actual controller fit — no reference back or physical fit test · Hyper3D unscored · SupaVoxel unscored — pixels cannot establish the rear anatomy or load-bearing function.

These rows are not summed: for a close-up digital viewer, I weight the visible hand more than print topology.

What is the picture actually asking the model to make?

The common 1,572,056-byte image depicts a raised-finger hand, a splayed thumb and a wrist emerging through angular rock. It does not provide the back of the hand, a measured gap for a controller, or a CAD sketch. I supplied the same checked source file to the two tools, but neither company’s private preprocessing was measured. The source image was independently generated with a visual reference in its history; that is not publication-rights clearance for the reference. This review is about the observable exports, not a permission to publish the source or to sell a functional device holder. Keeping that scope in view stops a convincing dark-rock render from becoming a fictitious engineering drawing.

One checked input shows the pose and rocky base, not measured cradle clearance; image-rights review remains open.

Which Hyper3D file is even in this comparison?

Gen-1.5. A separate Gen-2.5 Hyper3D preview ended at a Free-account GLB Download subscription gate, leaving no model to measure. The later Gen-1.5 attempt produced a gray geometry-only file, then a textured PBR ZIP after Material Generate and Confirm. Comparing that inaccessible Gen-2.5 preview with SupaVoxel’s real GLB would grade an imagined file against one on my drive.

Hyper3D’s Gen-2.5 Free-account Download gate: preview visible, inspected GLB unavailable.

What exactly did Hyper3D send down the wire?

Hyper3D sent a 20,394,412-byte ZIP containing a 13,098,572-byte textured PBR GLB plus a shaded model. Its earlier 4,392,672-byte gray GLB had no textures and cannot stand in for the PBR asset. SupaVoxel’s chosen Export → GLB → Original size branch sent an actual 31,770,112-byte textured GLB; its optional Compressed branch was not measured. A developer would extract and host Hyper3D’s PBR member, but a human downloading through its UI first transfers the whole ZIP. Two audiences, two honest denominators.

Hyper3D’s web Download delivered two GLBs in one 20.39 MB ZIP; the 13.10 MB PBR is one extracted member.

SupaVoxel offered Original size and Compressed; only the 31.77 MB Original size branch has a tested payload.

If visitors load a single model, how long is the transfer?

Under an ideal constant 12 Mbps connection, no handshake, cache, decoding or render delay, the separately hosted 13.10 MB Hyper3D PBR file implies 8.73 seconds of payload transfer; the tested 31.77 MB SupaVoxel GLB implies 21.18 seconds. On an ideal 100 Mbps link they imply 1.05 and 2.54 seconds. Those are bytes × 8 ÷ bandwidth, not measured first-frame times. If you are downloading the model from Hyper3D’s website, use its 20.39 MB ZIP: ideal 13.60 seconds at 12 Mbps, not 8.73. SupaVoxel’s selected UI file remains 21.18. The consequence is a real planning choice: for a mobile-first viewer, I might simplify or offer a click-to-load instead of automatically making every visitor download the denser sculpture.

The hosted-GLB calculation uses this extracted PBR member, not Hyper3D’s whole ZIP.

The chosen SupaVoxel Original-size GLB is heavier but gives a denser digital sculptural surface in this run.

Does more file buy more of the hand?

In this pair it does. Hyper3D Gen-1.5 has 120,000 triangles and 92,233 vertices; SupaVoxel has 952,876 and 490,760. Looking at the paired front and untextured renders, I see more palm creases and broken-rock relief on SupaVoxel, while Hyper3D retains the broad pose with smoother forms. I cannot prove every extra triangle was well placed from a global count, but I can point to local differences in the exported views. The yaw-calibrated views are not pixel-perfect overlays because the model files have different native orientations. If all I need is a small thumbnail, the Hyper3D model may already be enough. If the hand rotates in a hero viewer, the additional shapes become worth a serious look.

The downloadable Hyper3D Gen-1.5 front carries the main gesture with comparatively smoothed small forms.

SupaVoxel’s front preserves visibly more finger and rock relief, not demonstrated controller clearance.

Are those megabytes all geometry?

No. Each tested PBR GLB embeds three 2048 × 2048 PNGs for base color, normal and metallic-roughness. Hyper3D’s base color is 2,580,567 bytes and SupaVoxel’s 2,444,467. The two other maps together are 6,124,811 and 2,185,016 bytes, respectively. SupaVoxel’s non-color images are substantially lighter in bytes even while its complete GLB is much heavier. That does not make its material more accurate; a PNG’s size depends on image content, not just pixel dimensions. The 109.15 versus 33.34 full-file bytes per triangle include maps, not pure mesh encoding. SupaVoxel’s heavier file does not have more texture files.

Hyper3D’s completed material step yielded three 2K maps; these bytes belong to the PBR asset.

What happens to the picture when I turn paint off?

The raised fingers and surrounding rock still exist in both gray meshes. SupaVoxel keeps extra carved variation across small rock faces; Hyper3D’s surface reads cleaner and more regular. That is relevant to a product illustrator who may change lights: a normal map can create a highlight but cannot create a new silhouette where there is no mesh. A monochrome physical print will not carry the PBR colors, normal map or metallic-roughness image onto the object, so the 8.71 MB of Hyper3D maps and 4.63 MB of SupaVoxel maps serve a digital viewer, not a plain resin print. I am not calling those maps waste for a digital viewer; they are part of why the lit asset looks finished.

The untextured Hyper3D mesh shows the pose without its three PBR maps.

The untextured SupaVoxel mesh makes the denser sculptural relief apparent without claiming print readiness.

What about the side nobody photographed?

The picture shows a palm, not a rear reference. Hyper3D inferred smooth dorsal ridges; SupaVoxel added groove and nail-like detail. I prefer the latter in a rotating viewer, but both are guesses, not a reconstruction verified against an unseen original. If the back matters, supply a second image. Extra triangles can beautifully preserve an invented detail without making it correct.

Hyper3D’s inferred rear: smoother ridges, no supplied rear photograph for checking.

SupaVoxel’s inferred grooves and nails help the orbit view but cannot be graded as anatomical truth.

How expensive is the denser model to hold and serve?

At 32 bytes per vertex plus three 4-byte indices per triangle, geometry buffers estimate 4.39 MB for Hyper3D versus 27.14 MB for SupaVoxel, excluding textures and rendering overhead. This is not measured VRAM. At 10,000 full uncached hosted-model loads and a hypothetical $0.085/GB, model-only egress estimates $11.13 versus $27.00. The $15.87 difference is arithmetic, not an invoice; caching or a tested Compressed export could change it. An icon does not warrant the heavier file; a hero orbit might.

Where Hyper3D beats my preferred visual file

It gives me a smaller tested individual PBR and a cleaner welded solid. Its 120,000-triangle file is one watertight face-connected shell after seam welding, with zero boundary and nonmanifold edges. SupaVoxel has 213 nonmanifold edges and 143 face-connected regions despite zero boundary edges. That prevents a validated volume or print-cost comparison on SupaVoxel. The exchange rate is measurable: Hyper3D’s extracted hosted PBR is 18.67 MB smaller, with roughly an eighth the triangle count, and its ZIP is 11.38 MB smaller than the selected SupaVoxel UI transfer. I get bandwidth and an unrepaired solid candidate; I give up the richer close-up that made me prefer SupaVoxel for digital art. Neither file has been tested under a controller’s weight.

Which version goes on my concept page?

I would try SupaVoxel for the hero sculpture and measure the actual viewer on target phones before shipping its 31.77 MB Original-size GLB. If that cost dominates and the simpler palm still sells the concept, I would choose the extracted Hyper3D Gen-1.5 PBR instead. I would not swap in the 4.39 MB untextured geometry-only file and still call it an equivalent PBR comparison. Nor would I call the SupaVoxel sculpt a printable stand until its defects are repaired and a real controller has been fitted. A good digital model can be an excellent first deliverable without masquerading as a proven physical product.

Put your own close-up against the byte budget

Open SupaVoxel’s image-to-3D tool with your actual object, export a file and zoom where a viewer would zoom. Then write down three different numbers before choosing a delivery route: bytes the creation site transferred, bytes in the individual textured asset, and bytes a visitor will really fetch after whatever optimization you perform. For this hand, those first two numbers were different on Hyper3D by 7,295,840 bytes. If you care about a manufactured stand rather than a viewer, stop measuring file size as the deciding factor and start measuring the real controller, the mesh and the prototype.

How I measured it, and what I did not measure

One 1,572,056-byte source supplied to both, with a matching SupaVoxel saved-input fingerprint; internal preprocessing not measured. Actual Hyper3D Gen-1.5 Download yielded a 20,394,412-byte ZIP, whose PBR member was compared with an actual 31,770,112-byte SupaVoxel Original-size browser GLB. Gen-2.5’s blocked Download produced no file. Both PBRs embed three 2K PNGs. Paired renders use the same offline viewer, lighting, pitch and scale; Hyper3D uses yaw 0° and SupaVoxel yaw 90° to align the subject, despite different native orientations. Transfer time is arithmetic at fixed 12 or 100 Mbps; CDN math assumes 10,000 uncached full loads at $0.085/GB; geometry buffers assume 32 bytes per vertex and 4 per index, not measured VRAM. No SupaVoxel Compressed export, real network timing, albedo accuracy, slicer, print, fit test or image-rights clearance. The verdict expresses only this digital-visual preference.

Also in this series
Hyper3D Hand Stand Review 2026: A Watertight Mesh Isn’t a Fit Test
Hyper3D Rodin Review 2026: 0.5 Credit Spent, Gen-2.5 File Blocked

Open Generative AI GitHub Repo: A Self-Hosting Teardown (2026)

Lars Saleh — Wed, 07 Oct 2026 03:13:24 +0000

TL;DR: If you search "open generative ai github" in 2026, the repo you land on is Anil-matcha/Open-Generative-AI: an MIT-licensed Next.js and Electron studio for image, video, and lip sync generation, at roughly 29.7k stars and 5.4k forks as of October 6. The UI is open source and self-hostable. Most of the models behind it are not. Cloud generation goes through the Muapi.ai API with your own key, and truly local inference only exists in the desktop app, through two engines with real hardware requirements.

Some context on why I care. I build media features into client apps, mostly backend work: queues, webhooks, storage. When a client wants text-to-video in production, I usually call a hosted API such as AI Video API rather than run video models on our own GPUs. Open Generative AI keeps coming up as the "free, self-hosted" alternative, so I read through the repo, the package scripts, and the release assets to see what you actually get.

1. What the Open Generative AI GitHub repo is

The dev.to article that currently ranks for this search is a January 2025 list of three image projects: CompVis Stable Diffusion, DALL-E Mini, and StyleGAN3. Those are model repos. Open Generative AI is a different kind of thing: a front end that puts hundreds of hosted models behind one interface.

From the README and package.json:

Stack: Next.js 14 (App Router), React 18, Tailwind CSS v3, npm workspaces. A shared packages/studio component library holds the studios, and packages/studio/src/models.js is the single list of model definitions.
Studios: Image, Video, Audio, Lip Sync, Cinema (camera, lens, focal length, and aperture presets turned into prompt modifiers), Workflow (node-based pipelines), Agent, Design Agent, Marketing, AI Clipping, Body Swap, and a few more.
Distribution: a web build (npm run dev), an Electron desktop build, and a hosted copy on muapi.ai.
License: MIT.

The same packages/studio library powers the hosted version on muapi.ai, which explains why the model list moves so fast. Model updates land in one file and ship to both.

2. What's open and what isn't

This is the part the repo description ("Self-hosted, MIT licensed") glosses over.

Layer	Where it runs	What you need
UI (all studios)	Your machine or server	Node.js 18+, or the desktop installer
Cloud models (Flux, Kling, Veo, Sora, Seedance, Midjourney...)	Muapi's API	A Muapi access key, billed by Muapi
sd.cpp local engine	Your machine, desktop app only	CPU works; Metal on Apple Silicon, CUDA/Vulkan/ROCm elsewhere
Wan2GP local engine	Your GPU box, desktop app only	Your own Wan2GP install on a CUDA or ROCm GPU
Hosted web version	muapi.ai	A free account; always uses cloud APIs

The API flow is documented in the README. The app submits a job with POST /api/v1/{model-endpoint}, then polls GET /api/v1/predictions/{request_id}/result until the status is completed, authenticating with an x-api-key header. Your key sits in browser localStorage and, per the README, is only sent to Muapi.

So "free" means the code costs nothing. Generations on the big commercial models cost whatever Muapi charges for them. That's a perfectly reasonable design, a bring-your-own-key client, but you should budget for it before you tell a stakeholder it's free.

3. Running it from source

The README is clear that most people should grab a prebuilt installer. If you want to hack on it, this is the path, and I checked each script name against package.json:

# submodules are required for the workflow and agent packages
git clone --recurse-submodules https://github.com/Anil-matcha/Open-Generative-AI.git
cd Open-Generative-AI

# "setup" = git submodule update + npm install + build all workspace packages
# plain `npm install` is not enough
npm run setup

# then ONE of these
npm run electron:dev   # desktop app (Vite build, then Electron)
npm run dev            # web version on http://localhost:3000

# production web build
npm run build && npm run start

If Next.js complains it can't find a pages directory, you're either not in the repo root or you cloned without submodules. Re-run npm run setup if packages/Vibe-Workflow or packages/agents are empty.

4. Local inference: two engines, very different costs

Local generation is desktop-only. The hosted and web builds always call cloud APIs.

sd.cpp (bundled). Built on stable-diffusion.cpp. You install it with one click under Settings, then Local Models. It handles image models only: Dreamshaper 8, Realistic Vision 5.1, and Anything v5 (SD 1.5, about 2.1 GB each), SDXL Base 1.0 (6.9 GB), and Z-Image Turbo and Base, which also need a 2.4 GB Qwen3-4B text encoder and a 335 MB FLUX VAE. The README warns that Z-Image is known to hang a base 8 GB M-series Mac and recommends 16 GB of RAM. On 8 GB, stick to SD 1.5.

Weights default to Electron's app-data folder (~/Library/Application Support/open-generative-ai/local-ai on macOS, ~/.config/open-generative-ai/local-ai on Linux). If you'd rather keep multi-GB weights on another drive, set OPEN_GENERATIVE_AI_LOCAL_AI_DIR before launch.

Wan2GP (bring your own). This is where video lives. The app doesn't bundle Python or weights. You install Wan2GP yourself on a CUDA or ROCm machine, and the app either runs wgp.py from a local folder or talks to Wan2GP's MCP server on another box:

python wgp.py --mcp --mcp-api-version 1 --mcp-transport streamable-http \
  --mcp-host 0.0.0.0 --mcp-port 7866

You paste http://<host>:7866/mcp into the settings panel. The Gradio UI on port 7860 won't work for this. Only bind to 0.0.0.0 on a network you trust.

The remote mode is the clever part. Wan2GP has no Apple Silicon path, so a Mac user can keep the desktop app and push inference to a Linux GPU box or a rented instance. Supported models include Wan 2.1 1.3B (480p, about 8 GB VRAM, the lightest option), Wan 2.2 14B T2V/I2V, Hunyuan Video 1.5, LTX-2 Distilled (720p), plus Flux.1 Dev and Qwen Image for stills.

5. Gotchas I'd check before relying on it

The numbers in the README disagree with each other. The tagline says 400+ models, a features bullet says 200+, and the category table says 420+ "verified against models.js." Lip sync is "9 dedicated models" in one section and 15 in the category table. Count models.js yourself if the number matters to you.
The download table is stale. It still links 1.0.9 installers, while the latest GitHub release is v2.0.0 (May 23, 2026), with .dmg builds for arm64 and Intel, a Windows .exe, an .AppImage, and a .deb. Go to the Releases page directly.
The binaries are unsigned. On macOS you'll need xattr -cr "/Applications/Open Generative AI.app" or the "Open Anyway" button; on Windows, SmartScreen's "Run anyway."
Ubuntu 24.04 AppArmor. The AppImage can die silently because of apparmor_restrict_unprivileged_userns. The .deb ships an AppArmor profile, so install that instead of flipping the sysctl.
"No content filters" describes the UI. Your generations still run on Muapi and on the upstream model providers, so read their terms before you build a product on that promise.
The README sells white-label hosting. MuAPI's white-label plan starts at $49/mo. It's optional, but expect upsell links throughout the docs.

6. How it compares to the older GitHub picks

Repo	Stars (Oct 2026)	Last push	What it is
Anil-matcha/Open-Generative-AI	29.7k	Oct 2026	Multi-model studio UI, BYO key plus local engines
CompVis/stable-diffusion	73.5k	Jun 2024	Original SD research code
borisdayma/dalle-mini	14.7k	Nov 2023	DALL-E Mini model code
NVlabs/stylegan3	6.9k	Sep 2023	GAN research code, NVIDIA GPU
deepbeepmeep/Wan2GP	10.1k	Oct 2026	Local video/image runtime for modest GPUs
leejet/stable-diffusion.cpp	7.5k	Oct 2026	C++ diffusion inference, powers the sd.cpp engine

The 2025 list is still useful as history. If you want to generate something this week, the three bottom rows are where the activity is, and the top row ties them together behind a UI.

FAQ

Is Open Generative AI on GitHub really free?
The code is MIT licensed and free. Cloud generations go through Muapi with your own key, which is billed. Local generation through sd.cpp or Wan2GP costs only your hardware.

Can I run Open Generative AI fully offline?
Only in the desktop app, using sd.cpp for images or a Wan2GP install for video. The web build and the hosted version always use cloud APIs.

What GPU do I need for local video?
Wan2GP needs a CUDA or ROCm GPU. Wan 2.1 1.3B at 480p is listed at about 8 GB VRAM. Larger models such as Wan 2.2 14B are noted as slow on consumer cards.

Is Open Generative AI the same as Stable Diffusion?
No. Stable Diffusion is a model. Open Generative AI is a studio that can run SD 1.5 and SDXL locally and also calls hundreds of hosted models.

Where I landed

For prototyping and comparing models side by side, Open Generative AI is the most complete open-source front end I've looked at, and the Wan2GP-over-MCP setup is worth stealing even if you never use the UI. For a production feature where a user clicks "generate" and expects a video back through a webhook, I still prefer a narrower hosted service. For that job I reach for AI Video API, which handles text-to-video and image-to-video with callback webhooks, so my backend stays a queue and a handler. The repo is at github.com/Anil-matcha/Open-Generative-AI if you want to read models.js yourself.