DEV Community: Tessa Mori

Higgsfield AI Image Generator Review 2026: Same Model, 2\u00d7 Credits

Tessa Mori — Tue, 20 Oct 2026 15:49:08 +0000

I gave Higgsfield Free and Kyncept Pro the same 1123-character still-image prompt, selected the publicly labeled Nano Banana Pro option and 16:9 framing in both editors, then downloaded two originals from each. All four files measured 1376 × 768 pixels. Higgsfield charged two credits per image against Kyncept's one; the pictures themselves do not justify declaring an overall quality winner.

My verdict in 60 seconds

I asked for a locomotive, a blue-water seawall, a lantern handoff and a commuter stepping back. Higgsfield and Kyncept both captured the setting; neither clearly staged that reaction. Higgsfield Free used twice the credits per still and marked its original PNGs, while the Kyncept Pro JPEGs had no visible mark. Different tiers make this an observed trade-off, not a matched-plan price comparison. The product homepages are https://kyncept.com and https://higgsfield.ai.

Submissions — two Higgsfield, two Kyncept; all four originals measured 1376 × 768 pixels.
Credits — Higgsfield Free: 10 → 8 → 6; Kyncept Pro: 232 → 231 → 230.
My preference — Kyncept Pro for an unmarked original at one measured credit; Higgsfield's two completed Free renders still count. The contact sheet is a composite, not a fifth generation.

Contact sheet of the four downloaded originals: two Higgsfield Free PNGs and two Kyncept Pro JPEGs, arranged together for inspection; it is not a fifth generated image.

What I actually matched in the two editors

The shared 1123-character prompt described one fictional 1920s railway and near-future undersea transit hall: a kneeling marine engineer, a porter handing over a brass lantern, a commuter stepping back from a puddle, locomotive left and blue-water seawall right. I entered it twice per product with 16:9 selected and no reference image. Both Higgsfield and Kyncept publicly labeled the option Nano Banana Pro. Matching labels do not prove identical processing, seeds or picture quality.

This was Higgsfield Free against Kyncept Pro, not equivalent tiers. I did not use Kyncept Free or buy a Higgsfield plan. The Higgsfield setup shots and Kyncept opening editor document the requests; original downloads, not interface previews, establish the file-level findings.

Higgsfield Free still-image editor at opening, before the first matched submission; an interface screenshot, not a downloaded original.

First Higgsfield image request in the editor, showing the prompt, public Nano Banana Pro label and selected 16:9 setting; no final image is established by this screen.

Kyncept Pro image editor before its first matched still submission; this is the starting UI, not one of the exported JPEGs.

Four original downloads before any quality judgment

The four exported files below matter more than small result-page previews. Each measured 1376 × 768 pixels despite the selected 16:9 framing control; those dimensions are not mathematically exact 16:9. Compare the composition and watermark on the originals, not thumbnails. Higgsfield #1 has a hanging lantern near the kneeling engineer and a baked-in lower-right mark.

Downloaded Higgsfield Free original PNG #1, 1376 × 768 pixels, with the baked-in lower-right HIGGSFIELD AI mark; not an editor thumbnail.

Higgsfield #2 moves the lantern and hands nearer the engineer beneath the clock, again with the mark baked into the original.

Downloaded Higgsfield Free original PNG #2, 1376 × 768 pixels, with the visible baked-in HIGGSFIELD AI mark; not an editor thumbnail.

Kyncept #1 places the lantern nearer the glass, apart from the engineer's work. I see no watermark in the downloaded JPEG.

Downloaded Kyncept Pro original JPEG #1, 1376 × 768 pixels; porter and lantern are near the glass, and no watermark is visible in this file.

Kyncept #2 brings the lantern closer to the engineer. Its centrally placed commuter does not clearly step backward.

Downloaded Kyncept Pro original JPEG #2, 1376 × 768 pixels; lantern is closer to the kneeling engineer, with no visible watermark in this file.

The locomotive and seawall are shared, not a win for either side

All four originals place the locomotive left and the blue-water seawall right in a continuous scene, not a split screen. Both Higgsfield stills and both Kyncept stills make the railway-undersea premise legible. Those shared landmarks do not certify the exact handoff, commuter reaction or physical consistency of every contact point.

Higgsfield's first result appears in its editor below. That UI thumbnail is evidence of completion, while the downloaded Higgsfield PNG above is evidence of its baked-in mark. I use the same distinction for Kyncept: inspect the original for detail, the editor for workflow.

First Higgsfield result displayed in the editor; this UI view confirms a result appeared but is not the downloaded PNG used for file-level inspection.

A lantern handoff is not the same in every frame

The foreground action was a handoff to a kneeling engineer repairing a sensor. Higgsfield #1 instead emphasizes a hanging lantern; Higgsfield #2 brings hands and lantern near the engineer. Kyncept #1 separates the porter's lantern from the work; Kyncept #2 brings it closer. Within each product the staging changes, so one pleasing frame cannot prove a repeatable advantage. The Kyncept first-result screen below records completion and a 231-credit balance. It is a receipt and UI preview, not a substitute for examining the original JPEG above.

First Kyncept image displayed in its editor with 231 credits remaining after that run; the downloaded JPEG above is the original used for composition assessment.

The commuter is an ambiguous instruction, not a scored tally

The third person was meant to step back from a shallow puddle. In none of the four originals is that reaction unambiguous to me. The centrally positioned commuter in Kyncept #2 is not necessarily retreating; the Higgsfield figures likewise do not clearly establish the step. An apparent bystander is not proof that a motion instruction was delivered.

That is not a comparative failure rate: two Higgsfield and two Kyncept submissions cannot establish one. The second Kyncept result screen shows completion and 230 credits remaining, but I inspect the original to judge the person. If that action is essential, I would check every candidate full size.

Second Kyncept result shown in the editor with 230 credits after completion; this UI preview does not independently prove the commuter stepped back.

No overall image-quality winner from these four files

Higgsfield #1 emphasizes the lantern; Kyncept #1 places it apart from the engineer. Higgsfield #2 and Kyncept #2 bring the exchange closer. All four show locomotive and water; none clearly stages the retreating commuter. That supports no overall visual-quality winner from this test. I did not score aesthetic preferences, audit every shadow or prove identical processing from matching public labels. The second Higgsfield editor screenshot below confirms another result appeared, but quality judgments belong to the four original files, not their thumbnails.

The request also mentioned worn brass, wet stone, fish, a clock and a compact sonar console. Those details make the prompt demanding, but a list in the input is not a list of verified successes. I would show a prospective editor all four Higgsfield and Kyncept originals and let the intended composition determine which single frame to develop. On this evidence, I cannot convert a detail I happen to like in one Higgsfield still—or one Kyncept still—into a defensible general ranking of the products.

Second Higgsfield image displayed in its editor, a UI result thumbnail rather than the downloaded PNG #2 used in the four-file comparison.

The credit receipts: Higgsfield 2, Kyncept 1

Higgsfield Free's balance went 10 → 8 → 6: two credits per completed still, four total. Kyncept Pro went 232 → 231 → 230: one each, two total. Higgsfield thus consumed 2× the credits per still on these unlike tiers. Credits are product-specific units, not interchangeable currency or a direct comparison of paid plan prices.

Kyncept's second editor prompt shows the one-credit Generate quote; its result screens show the subsequent balances. Higgsfield's debits came from observed before-and-after balances, although this article's Higgsfield UI thumbnails do not constitute the whole balance ledger. If these rates persisted for 100 submissions, that would mean 200 Higgsfield credits or 100 Kyncept credits—not 100 guaranteed usable pictures or monetary savings.

Second Kyncept image request in the editor before submission, showing the one-credit Generate quote; it is a prompt UI screen, not a generated original.

What the three reliable stopwatch numbers actually say

Higgsfield Free's two observed waits were 32.7 and 28.7 seconds. Only Kyncept image #2 has a reliable wait: 63.967 seconds. Its first completed without an established duration. These Higgsfield runs finished sooner than that one timed Kyncept run; I give Higgsfield credit for those observations, not a stable platform speed win.

There is no valid two-run Kyncept average here, and I will not project bulk hours saved from this tiny sample. The Higgsfield screenshot shows its first generation in progress; it is not an independent stopwatch record. The waits above came from observed timings, not the appearance of a progress indicator.

First Higgsfield image in progress in the editor; this is a generation state, not the finished PNG or an independent timing record.

The Higgsfield Free watermark survived the download

Both Higgsfield Free original PNGs above contain a lower-right HIGGSFIELD AI mark. It survived downloading; this is not merely a Higgsfield UI overlay. Neither Kyncept Pro original JPEG has a visible watermark. That is a practical distinction for a still I want to place in a finished layout.

I tested neither Kyncept Free nor a paid Higgsfield account. I cannot infer Kyncept Free's watermark policy or promise that a Higgsfield subscription would remove this mark. The tier mismatch belongs in every recommendation based on these files. The originals, not the Higgsfield result-page thumbnails, prove what was exported.

There is an especially clear request-versus-result distinction here: the image prompt explicitly said no watermark, yet the two Higgsfield Free downloads visibly include one. That statement is about the Higgsfield originals in this account, not about whether the visual model obeyed every other request or whether another Higgsfield tier would behave differently. Kyncept Pro's unmarked originals answer the practical export question for the tier I actually used; they say nothing about an untested Kyncept Free account.

PNG, JPEG and what the byte counts do not prove

Higgsfield Free's PNG originals were 2,006,432 and 1,934,626 bytes; Kyncept Pro's JPEGs were 937,800 and 850,528 bytes. All measured 1376 × 768 pixels. Their respective means were 1,970,529 and 894,164 bytes: roughly 2.20× as many bytes in these Higgsfield PNGs. That is not an image-quality score.

PNG and JPEG are different formats, so those bytes do not establish intrinsically better Kyncept compression, faster downloads, cheaper bandwidth or a picture-quality advantage. I would compare the four originals visually for the intended use, while treating their sizes as properties of these files alone.

The editor path, rather than just the final picture

In Higgsfield I saw the editor, entered the prompt, watched the first image generate and received the result; I repeated the same prompt for a second completed still. Kyncept likewise displayed its first generating and result states, then a second prompt and completed result. Both produced two downloadable originals. These screens establish a workflow, not a test of every model or export setting.

Higgsfield's second prompt screenshot below is a request, not an output. The Kyncept generation screenshot is an in-progress UI, not a clock for Kyncept run #1. Video is a separate, brief caveat: one Higgsfield Free Fast click led to an upgrade overlay, no debit and no clip; two Kyncept Pro video charges yielded near-duplicate audiovisual files. Neither video observation changes the still-image quality judgment.

Second Higgsfield still-image prompt and selected aspect before generation, showing the repeated request rather than a completed output.

First Kyncept still in a generating state; this UI frame does not establish a reliable duration for that first run.

Final verdict: a four-still comparison with a measurable tariff, not a quality crown

Higgsfield Free completed two images in 32.7 and 28.7 seconds; Kyncept Pro delivered two at one measured credit each, with only its second wait reliably timed at 63.967 seconds. Higgsfield's original PNGs were marked; Kyncept's Pro JPEGs visibly were not. Yet both captured locomotive and seawall, varied the lantern gesture and left the commuter's reaction unclear. I see no overall quality winner.

For a quick Higgsfield Free preview, its observed turnaround is real. For this publication-bound still, I prefer the unmarked Kyncept Pro originals and smaller observed debit. This judgment stops at this prompt, these four files and these unequal account tiers.

Which one I would use for this job

For another still in this fictional railway-and-seawall setting, I would try Kyncept Pro first at https://kyncept.com: it cost one credit per completed image in my two submissions, and its two downloaded JPEGs had no visible mark. I would still inspect the full-size result for the lantern handoff and the uncertain bystander before using it. Higgsfield has a defensible place if its observed Free-account turnaround matters more to a particular preview workflow, but Higgsfield charged two credits per image here and baked a mark into both Free PNG originals. That preference is about the measured trade-off, not a claim that one interface always draws better pictures.

Tripo GLB Export Review 2026: 60.77 MB for One Watch Stand

Tessa Mori — Sun, 18 Oct 2026 15:48:39 +0000

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

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

Same photo of a cantilever watch stand, same offline renderer, same camera rig for both models. Tripo's export weighs 60,768,680 bytes. SupaVoxel's weighs 7,704,168 — 7.9× lighter for a shape that looks like the same object from every angle I rendered. The gap is not geometry: Tripo has 33% more triangles but 7.9× the bytes, because Tripo ships uncompressed geometry and 4.33 MB of JPEG and PNG maps where SupaVoxel ships meshopt-compressed geometry and 0.45 MB of WebP.

GLB size — Tripo 60.77 MB · SupaVoxel 7.70 MB · 7.9×
Bytes per triangle — Tripo 30.45 B · SupaVoxel 5.14 B · 5.9×
Triangles — Tripo 1,995,520 · SupaVoxel 1,500,000 · Tripo 1.33×
Base colour map — Tripo 1.35 MB · SupaVoxel 0.21 MB · both 4096×4096, 6.5× the bytes
Maps a printer never reads — Tripo 2.98 MB · SupaVoxel 0.24 MB · 12.5×
Texture formats — Tripo JPEG + JPEG + PNG · SupaVoxel 3× WebP · the PNG alone is 2.04 MB
4G download at 12 Mbps — Tripo 40.5 s · SupaVoxel 5.1 s · 35.4 s of waiting
Geometry VRAM estimate — Tripo 56.4 MB · SupaVoxel 44.0 MB · 12.4 MB saved

Five things the same-camera renders and the byte counts say:

Tripo's export dialog defaults Texture Resolution to 4k Current, and nothing in that dialog tells you what it does to the file size. That default is most of the 60.77 MB.
One Tripo file — a 4096×4096 PNG normal map at 2,043,213 bytes — is 4.6× larger than SupaVoxel's entire three-texture set.
Both products invent detail where the photo showed nothing. SupaVoxel added a plaque on the arch underside; Tripo added a concentric groove ring on the base top, which the input photo does not have.
Tripo's silhouette is the crisper one: a thinner, sharper arch tip and a longer reach. SupaVoxel's is blunter and wider.
Tripo arrived first on this subject — 160.0 s against 250.2 s — though across all ten subjects SupaVoxel was quicker on seven and Tripo was the steadier one at 135–189 s. Either way the file it hands back costs 52 credits and 53.07 MB more.

For anything that will be downloaded, previewed in a browser or served more than once, the SupaVoxel file is the one to ship. If your only consumer is a workstation with the file already local, the 53 MB is somebody else's problem and Tripo's crisper arch tip is a fair thing to want.

The input both models were given

One 1,518,703-byte PNG, sha256 645af033…, shot three-quarter front. The back, the arch underside and the base top are not in this photo at all.

Everything after this is the same file into two products, same defaults, one run each, then both GLBs downloaded and rendered offline under identical lights. The two exports sit at different yaw angles in world space (Tripo 0°, SupaVoxel 320°), so my render script offsets each to the same pose — every pair below is genuinely the same viewpoint, not two flattering picks.

Front, same camera

SupaVoxel: the arch sweeps off the column top into a squared lip with real thickness, one continuous surface with no crease. The S-curve in the column is pronounced.

Tripo at the same camera: a thinner arch tapering to a sharper tip, a thinner lip, a faint transverse seam near the end of the sweep, and a straighter column with a flatter S.

Tripo's is the more elegant profile here — I would rather have that tip. It costs 30.45 bytes per triangle to own it.

Side, same camera

SupaVoxel in profile: the arch crosses its apex and drops, air underneath, ending in a rounded lip you can rest a strap on. The curve is smooth end to end with no sag.

Tripo in profile: a longer, flatter arch dropping to a much thinner, nearly pointed tip, with a small notch on the underside.

Both cantilevers are real — open air under both arches. Which tip actually supports a watch is a wall-thickness question, and this run recorded no thickness field, so I am not answering it.

Back: the view neither product was shown

SupaVoxel invented an oval engraved plaque with concentric rings and illegible pseudo-lettering on the arch underside. The input photo has no label. That is the most visible hallucination in this test.

Tripo at the same camera: the arch underside is blank — more restrained — but the column meets the base disc in a hard crease with no fillet, as if the foot were pushed into the plate.

Tripo is the better-behaved of the two on the back face. It invented nothing where it had nothing, which is the right instinct; it just also skipped a transition SupaVoxel rendered as a full round.

Back, zoomed

The SupaVoxel engraved plaque at close range: concentric rings and text-like marks that resolve to nothing. For a print, this is a surface you sand.

Tripo at the same close range: a clean blank panel, and below it the abrupt column-to-base junction.

Invented detail, back — Tripo none · SupaVoxel one plaque · Tripo wins this face
Column-to-base transition — Tripo a hard crease · SupaVoxel a continuous fillet · SupaVoxel wins this one
Neither is measured — both are same-camera observations, reported not scored

Hero, and the ring Tripo added to the base

Tripo's hero view: the base top carries a ring of concentric recessed grooves. The input photo's base is plain. There is also a short transverse scratch low on the arch face.

SupaVoxel at the same camera: matte grey, plain disc, no extra tooling marks on the base top, a rounded transition from plate to column.

So both sides invent — SupaVoxel on the back underside, Tripo on the front face of the base, where it is the first thing a viewer sees.

Top-down: the footprint

SupaVoxel from above: a wide band crossing a clean circular base, its tip past the rim, the two band edges parallel and untwisted.

Tripo from above: a noticeably narrower band overhanging the disc at both ends.

Bounding box at 120 mm tall — Tripo 83.3 × 120.0 × 103.05 mm · SupaVoxel 85.51 × 120.0 × 91.3 mm
On the plate — Tripo narrower and 11.75 mm longer · SupaVoxel 2.2 mm wider and shorter

Where the 60.77 MB actually goes

Tripo's export dialog, with Texture Resolution sitting on "4k Current" and the filename auto-set to "curved display stand 3d model". Leave the default and the 4K maps ship with the model.

Base colour — Tripo 1,352,875 B · SupaVoxel 207,682 B · both 4096×4096
Everything else — Tripo 2,976,295 B · SupaVoxel 237,632 B · 12.5×
Tripo's normal map alone — 2,043,213 B PNG · larger than the whole SupaVoxel texture set (450,000 B) by 4.6×
Tripo's metallicRoughness — 933,082 B JPEG · a map no printer reads

Tripo is not shipping more resolution — both base colour maps are 4096×4096. Tripo is shipping the same resolution in heavier containers: JPEG, JPEG and a 2 MB PNG against three WebP files at 58,370 / 207,682 / 179,262 bytes.

And the geometry is uncompressed

The same dialog enlarged: File Name, Format, Texture Resolution. No decimation, no LOD, no compression choice — the 1,995,520 faces go out at full weight.

The SupaVoxel GLB declares EXT_meshopt_compression and KHR_mesh_quantization. Tripo's declares KHR_materials_volume and FB_ngon_encoding — no geometry compression at all. Between that and the texture containers you have the entire 7.9×.

Bytes per triangle — Tripo 30.45 B · SupaVoxel 5.14 B · same object, 5.9× cheaper per face
What that compression costs you — the quantised SupaVoxel export arrives in a ~32,000-unit box, so you scale once to your target height before slicing

What that weighs on a phone

The SupaVoxel result page reports Triangles 1,500,000 and millimetre dimensions, and the file behind it is 7.70 MB.

12 Mbps 4G — Tripo 40.5 s · SupaVoxel 5.1 s · 35.4 s of staring at a spinner
100 Mbps home — Tripo 4.86 s · SupaVoxel 0.62 s · opens instantly against opens eventually
Geometry VRAM — Tripo 56.4 MB · SupaVoxel 44.0 MB · 12.4 MB, which decides whether a second model fits

The CDN invoice

10,000 loads/month at $0.085/GB — Tripo $51.65 · SupaVoxel $6.55
Same traffic, one year — Tripo $619.80 · SupaVoxel $78.60 · $541.20 of difference
A 100-model catalogue, downloaded once each — Tripo 6.08 GB · SupaVoxel 0.77 GB

Put a Tripo GLB on a product page and the 55 credits stop being the price. Ten thousand monthly views is another $45.10 a month, and the visitor on a phone waits 40.5 seconds to see the thing.

That number is the one most likely to be dismissed as trivia, and it is the one that compounds. A single hobby print never touches it. A catalogue of a hundred items, each viewed a few thousand times a month, turns the same ratio into a recurring line on an invoice nobody budgeted for, while the objects on screen look — as the renders above show — very nearly identical from every angle a customer will rotate them to.

What I did not measure

A comparison is only worth as much as the list of things it refused to guess at, so here is mine for this case. Tripo's viewer, once its modal is dismissed, offers material spheres, an Export button and a promotional banner — no wireframe and no normals mode — which is itself part of why several of these rows stayed empty on the Tripo side.

Albedo ΔE between the two base colour maps — not captured this run. I compared bytes, dimensions and formats, not colour difference, so I make no claim about which texture is closer to the photo.
Wall thickness — not captured. No thickness field exists in my metrics and I will not infer it from a silhouette.
UV chart occupancy — not captured.
Export formats offered by either product — not captured; GLB on both sides.
The two wireframe zoom renders — 7.8 KB and 10.8 KB, both near-solid black. I opened them: that is genuine 1.5–2 M-triangle density, not an empty frame, and neither is used as evidence here.

Final verdict: Tripo scores 60/100

Tripo produced the crisper arch tip, invented less on the back face, and beat SupaVoxel to this particular model by 90 seconds — 160.0 s against 250.2 s, one of three subjects out of ten where it won the clock. It then charged 55 credits against 3 and shipped 60,768,680 bytes against 7,704,168 — the same 4K base colour resolution in containers 6.5× heavier, a 2.04 MB PNG normal map, and 1,995,520 triangles with no compression and no way to reduce them. On a phone that is 40.5 seconds against 5.1. On a product page it is $619.80 a year against $78.60.

One run each, product defaults, sample size one. Both files were downloaded and parsed; nothing here is read off a product panel.

Which one I would use for this job

If the model has to travel — a store page, a client hand-off, a phone — the SupaVoxel file is the one I would ship: 7.70 MB, 5.14 bytes per triangle, three WebP maps, meshopt-compressed geometry, 5.1 seconds on 4G, at supavoxel.com. Its honest cost is that the quantised export needs one scale step before slicing, and its base is 2.2 mm wider on the plate. Take Tripo if the arch tip silhouette is what you are buying and the bytes never leave your workstation.

Tripo 3D Print Review 2026: Flipped Normals on a 2M-Face Mesh

Tessa Mori — Fri, 16 Oct 2026 15:51:25 +0000

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

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

I fed one photo of a minimalist cantilever watch stand into Tripo and into SupaVoxel, took both GLB files offline, welded the vertices by position and measured them with the same script. Tripo charged 55 credits and handed back a 1,995,520-triangle mesh that is watertight — and whose face winding is inconsistent, meaning some faces point inward. The SupaVoxel file is watertight too, and its winding is consistent. For a print job that single boolean is the difference between "slice it" and "fix it first, every single time."

Watertight after welding — Tripo yes · SupaVoxel yes · tie
Boundary edges (holes) — Tripo 0 · SupaVoxel 0 · tie
Non-manifold edges — Tripo 0 · SupaVoxel 0 · tie
Winding consistent (normals) — Tripo false · SupaVoxel true · one repair pass per Tripo model
Sliver faces — Tripo 259 · SupaVoxel 5,072 · Tripo wins by an order of magnitude
Degenerate faces — Tripo 1 · SupaVoxel 49 · Tripo wins
Support area at 45° — Tripo 3,466.7 mm² (11.91%) · SupaVoxel 4,742.7 mm² (15.32%) · Tripo wins
Resin at 120 mm tall — Tripo $3.59 · SupaVoxel $3.95 · Tripo wins by $0.36

Five things that decide this case:

Tripo's welded mesh has flipped faces. You cannot see that in Tripo's own viewer — it has no normals mode — so you find out in the slicer or after the print fails.
Tripo's triangle quality is genuinely better here: 259 slivers and 1 degenerate face against SupaVoxel's 5,072 and 49. That is a real loss for SupaVoxel and I am not going to dress it up.
Tripo ships 1,995,520 triangles against SupaVoxel's 1,500,000, and at 120 mm tall its average triangle edge is 0.1956 mm — against a 0.4 mm nozzle, both files are already past the point where more triangles buy anything.
Tripo's export dialog has three fields: file name, format, texture resolution. No face count, no LOD. The 1,995,520 faces leave the building as-is.
The whole Tripo geometry advantage costs 55 credits against 3, a 60.77 MB download against 7.70 MB, and one manual normals flip per model.

If the job is "turn a product photo into something I can slice tonight," SupaVoxel is the one to use. If the job is "take this into Blender and do boolean surgery on it," Tripo's cleaner triangles are worth the 18.3× credit bill — I say so again at the end, in the one row where Tripo wins outright.

The test: one photo, one target height, two products

The single input both products were given: a 1,518,703-byte PNG, sha256 645af033…, one white cantilever watch stand shot three-quarter front. Neither product ever saw the back.

Same file, same defaults, one run each. Everything below was parsed out of the downloaded GLB, not read off a product panel. Print metrics are computed after welding vertices by position — both exports split vertices along UV seams, so measuring before welding measures seams, not topology. I normalised both models to 120.0 mm tall first.

Watertight is not the finish line

The SupaVoxel result page reports Triangles 1,500,000; the parsed GLB reports 1,500,000. Panel and file agree to the digit.

Both meshes pass the checks most people run. Tripo: watertight, 0 boundary edges, 0 non-manifold edges, 1 connected component. SupaVoxel: the same four. On that checklist the case is a tie, and most reviews would stop here and call Tripo fine. The fifth check is the one that costs money.

Connected components — Tripo 1 · SupaVoxel 1 · both a single shell, not a pile of patches
Euler characteristic (SupaVoxel) — 2, from 750,002 welded vertices · a closed solid

Tripo's flipped normals are a repair step per model

SupaVoxel's in-product Normals view: one continuous gradient across the arch — teal on the base, blue-to-magenta up the column — with no patch where adjacent faces disagree. That is what consistent winding looks like before you download anything.

welded_winding_consistent is false for Tripo and true for SupaVoxel. Tripo built a closed shell and left some of its faces pointing the wrong way. Most slicers will guess their way through it; boolean operations and shelling will not. The cost per model is small — one recalculate-normals pass — but you owe it on every model. A hundred product photos through Tripo is a hundred unscheduled repairs, at 5,500 credits for the batch.

Tripo's viewer gives you no way to catch this: a textured model and a material strip, no normals mode, no wireframe, no mesh view. You spend 55 credits, you get a picture of what you bought, and the defect that matters stays invisible until the file is on your disk.

Where Tripo genuinely wins: triangle hygiene

Tripo's untextured mesh at the same camera. 259 sliver faces and 1 degenerate face in 1,995,520 triangles.

This is SupaVoxel's clear loss and it is not close.

Sliver faces — Tripo 259 · SupaVoxel 5,072 · 19.6× worse on the SupaVoxel side
Degenerate faces — Tripo 1 · SupaVoxel 49 · 49× worse on the SupaVoxel side
Triangle count — Tripo 1,995,520 · SupaVoxel 1,500,000 · Tripo has 33% more faces, so "they simply have more triangles" does not explain the gap

Across ten objects I ran through both products, Tripo's triangle count barely moves: 1,896,372 to 1,996,779, a 5.2% spread whatever the subject. SupaVoxel ranges 945,492 to 2,786,054 — a 146% spread — because it follows the shape; the run that gave this watch stand 1,500,000 gave an armoured vehicle 2,786,054. This case is simply where the two land closest. The flat 1,500,000 reads as a quantisation step, not a limit. Ten subjects is a sample, not a statistic.

Slicers will almost certainly eat both files. Blender is less forgiving: needle-thin triangles are where a boolean opens a crack or a shell operation self-intersects. If your pipeline is generate-then-heavily-modify, this row alone should send you to Tripo — the trade ratio is 52 extra credits and 53.07 MB per model.

The cantilever is real on both sides

SupaVoxel's side view: the arch leaves the column, crosses its apex and drops, with open air underneath. The tip closes in a rounded lip with visible thickness.

Tripo at the same camera: a longer, flatter arch that tapers to a much thinner, nearly pointed tip, with a small notch on the underside. The overhang is genuine here too.

Neither product cheated the hard part. A watch stand is a cantilever or it is a paperweight, and both files have air under the arch. Tripo's tip is thinner and crisper; SupaVoxel's is blunter. Which one holds a strap better is a wall-thickness question, and I did not measure wall thickness — see the last section.

Support area: Tripo 3,466.7 mm², SupaVoxel 4,742.7 mm²

The flatter Tripo arch in the side render above presents less area below the 45° threshold, which means fewer support scars to sand off the underside.

Overhang area at 120 mm — Tripo 3,466.7 mm² · SupaVoxel 4,742.7 mm² · +1,276 mm² on the SupaVoxel file
Overhang as a fraction of surface — Tripo 11.91% · SupaVoxel 15.32% · Tripo wins

An extra 1,276 mm² of support contact is real sanding time on the arch underside — the second of exactly three numbers in this case that go against SupaVoxel, and I would rather name it than let a reader find it.

Resin at 120 mm: $3.59 against $3.95

Tripo's arch is narrower and the column straighter, which is where the 10 cm³ of volume goes.

Volume at 120 mm — Tripo 102.43 cm³ · SupaVoxel 112.75 cm³ · Tripo 9% leaner
Resin at $35/L — Tripo $3.59 · SupaVoxel $3.95 · Tripo saves $0.36 per print
Across a 100-piece batch — Tripo $359 · SupaVoxel $395 · Tripo saves $36

Third and last number against SupaVoxel. Now the trade, because that is the only honest way to read three losses: an extra 1,276 mm² of support scarring plus $0.36 of resin per piece, against 53.07 MB of download per model, 52 credits per model, one normals flip you do not have to perform, and $45.1 per 10,000 page loads of CDN spend. Over a hundred pieces that is $36 of resin against 5,200 credits and 5.3 GB.

Average edge length against a 0.4 mm nozzle

SupaVoxel's untextured mesh, same camera. 1,500,000 triangles, average edge 0.2352 mm at target height.

Mean triangle edge at 120 mm — Tripo 0.1956 mm · SupaVoxel 0.2352 mm · both finer than a 0.4 mm nozzle
SupaVoxel's margin over the nozzle — 1.7× finer · already past useful

Tripo's triangles are 20% shorter. On a 0.4 mm nozzle neither number is reachable, so what those extra 495,520 Tripo triangles mostly buy is file size. On resin the extra density has a theoretical edge — and you still pay for it in bytes, at 30.45 per triangle against 5.14.

Tripo's export dialog: three fields, none of them geometry

Tripo's export dialog auto-named the file "curved display stand 3d model" — it had recognised the object class — and parked Texture Resolution on "4k Current".

Same dialog, closer. File Name, Format, Texture Resolution. Nothing else.

No decimation control, no LOD dropdown, no "print-ready" preset. Tripo inferred the object class well enough to name the file correctly, then offered no way to act on it. Viewport to disk is 2 clicks in Tripo. SupaVoxel's export is a dropdown in the result page top bar; I did not record a click count this run, so that cell says not captured rather than a guess.

What each model invented where the photo had nothing

SupaVoxel's back: the underside of the arch became an oval engraved plaque with concentric rings and illegible pseudo-text. The input photo has no label anywhere. That is SupaVoxel's invention.

Tripo at the same camera: the arch underside is a blank panel — more restrained — but the column meets the base in a hard crease, as if the foot were pushed into the disc with no fillet.

Both products invent where the three-quarter photo gave them nothing. The SupaVoxel plaque is a thing you sand off; Tripo's missing fillet at the column foot is a stress riser at the one joint carrying the cantilever. Neither is measured — both are visible at the same camera.

The bounding box at 120 mm

Tripo from above: a narrower band that overhangs the disc at both ends.

SupaVoxel from above: a wider band across a clean circular base, the tip reaching past the rim.

Bounding box at 120 mm tall — Tripo 83.3 × 120.0 × 103.05 mm · SupaVoxel 85.51 × 120.0 × 91.3 mm
Plate footprint — Tripo narrower and longer · SupaVoxel wider and shorter by 11.75 mm

SupaVoxel is 2.2 mm wider on the plate — noise on any printer that fits a 120 mm object. The three numbers that actually hurt are above.

Checking the mesh before you download it

Reopening the same SupaVoxel result from Projects: version history intact, Triangles 1,500,000, millimetre dimensions, and Textured / Mesh / Wire / Normals still one click apart.

Four inspection modes in the browser means the winding check that decides this article takes one click and no download. Tripo's result page gives you the model, a material strip, an Export button — and an interstitial: the moment generation finishes, a "View Your Model" dialog covers the thing you just paid 55 credits for.

What I did not measure

Tripo reports 1995520 faces / 1015351 vertices in the corner, exactly matching the parsed GLB. On the reporting front Tripo is honest.

Wall thickness — not captured. There is no thickness field in my metrics, so I will not tell you which arch holds a watch better. The side renders show both tips have real thickness; that is as far as the evidence goes.
Export click count on the SupaVoxel side — not captured this run.
Charge timing (on submit or on completion) — captured for Tripo only: its balance fell 990 → 935 while the job was still generating.
Two wireframe zoom renders — discarded. At 1.5–2 M triangles they render as near-solid black; I opened both to confirm that is real density and not a blank frame, and I am not using either as evidence.

Final verdict: Tripo scores 60/100

Tripo delivered a watertight single-shell cantilever, the cleaner triangle population, the smaller support footprint and the cheaper resin bill, and it reported its own face count honestly. Then it shipped flipped normals in a file with no way to notice them, 1,995,520 triangles with no decimation option, and a 60.77 MB download, for 55 credits. The SupaVoxel file needs no repair pass and costs 3 credits, and it loses triangle hygiene by an order of magnitude — one real loss, stated once at the top and again here.

One run each, product defaults, sample size one. Every number above comes out of the two downloaded GLB files or off the screenshots in this article.

Which one I would use for this job

For turning a product photo into a file you slice the same evening, SupaVoxel is the one I would hand you: watertight, consistent winding, 0 boundary and 0 non-manifold edges, 3 credits, 7.70 MB, and a Normals view that proves the mesh is right before you download it — supavoxel.com. Take Tripo instead if the model is headed straight into Blender for boolean work — 259 slivers against 5,072 is worth 52 credits to that workflow, and I would not pretend otherwise.

Meshy AI Character Review 2026: 3 Textures, 74 MB, One Blue Crest

Tessa Mori — Wed, 14 Oct 2026 15:48:42 +0000

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

You have a knight in a picture. Polished silver plate, dark blue plume, sword point-down.

You want him standing in your scene by tonight, looking like the picture.

That's the actual test, isn't it? Not "is the mesh clean" — does he look like the guy. So I asked around, kept hearing the same two names, and ran the same illustration through Meshy and SupaVoxel. Then I rendered both files side by side under identical lights and cameras.

My verdict in 60 seconds — Meshy 63/100, SupaVoxel 88/100.

My scores for this one job, not a measurement. This is Meshy's best showing of the three articles I wrote about this run, and it still lands at 63. Here's why.

Full-figure read — both knights arrive whole · Meshy 7/10 · SupaVoxel 7/10 — a tie at playing distance: Meshy's silhouette is fine, and SupaVoxel's is just as legible from the same camera.
Brightness against the reference — both come back dark · Meshy 5/10 · SupaVoxel 5/10 — tie, and neither earns it: Meshy misses the polished silver of the source picture, and SupaVoxel misses it too.
Specular highlights on the plate — SupaVoxel sharper at the same crop · Meshy 6/10 · SupaVoxel 8/10 — Meshy's armour reads flatter where the light should catch; SupaVoxel keeps the bright flecks that make steel look like steel.
Back and back-zoom — invented by both · Meshy 5/10 · SupaVoxel 5/10 — tie by definition: the reference has no back, so Meshy's version is unverifiable and so is SupaVoxel's.
Triangles spent on that look — Meshy 2,230,028 vs SupaVoxel 1,499,574 · Meshy 5/10 · SupaVoxel 8/10 — Meshy pours 730,454 extra triangles into cape folds nobody orbits; SupaVoxel gets the same read with a third less mesh.
Vertices behind it — Meshy 1,184,811 vs SupaVoxel 922,928 · Meshy 6/10 · SupaVoxel 8/10 — Meshy carries 261,883 extra corner points into every frame; SupaVoxel holds the same knight on 922,928.
Bytes for that look — Meshy 74,160,184 vs SupaVoxel 12,287,608 · Meshy 3/10 · SupaVoxel 9/10 — Meshy charges 61,872,576 extra bytes for a difference you can't see at full-figure distance; SupaVoxel ships it at one-sixth the size.
Textures baked in — Meshy 3 vs SupaVoxel 3 · Meshy 7/10 · SupaVoxel 7/10 — tie, and it's awkward for Meshy: identical map counts mean none of the look difference comes from Meshy shipping more pictures.

Let me get the awkward part out of the way first, because Meshy genuinely earns something here:

Meshy holds the blue on the helmet. At a tight crop, the visor inlay and the blue-and-white star roundels survive. SupaVoxel's come back as tooled metal.
Meshy holds the gauntlet detail too, around the sword grip.
And then Meshy charges 74,160,184 bytes and 2,230,028 triangles for those two close-ups — with the same 3 textures, and the same total absence of a skeleton.
Step back to full-figure distance, which is where players actually stand, and the two knights converge into two dark figures of roughly equal readability.

So it comes down to your camera. If your knight lives in a tight crop, Meshy earned it this run. For everything else — and that's most scenes — SupaVoxel is what I'd ship over the Meshy file. That's the tool I used for the right-hand side of every pair below.

What are you actually comparing against?

The reference. Polished silver plate, dark blue plume, blue cape, fleur-de-lis tabard, sword held point-down in both hands. This picture is the entire brief.

This one illustration, and nothing else. No text prompt went into Meshy or into SupaVoxel — just the image.

Every render below came out of the same offline viewer, same lights, same camera numbers. Not a screenshot of the Meshy preview next to a screenshot of the SupaVoxel one, which would tell you about two lighting setups instead of two models.

If a Meshy comparison uses each tool's own viewer, you're looking at their lighting, not their geometry.

One honest wrinkle before we start: a 3D file carries its own idea of which way is forward. The Meshy knight and the SupaVoxel one don't agree on it — Meshy's front sits 35° off — so matching camera numbers doesn't guarantee matching facing. Where it mattered — the two close-up pairs — I squared each knight's front up instead, and I'll say so in the caption.

At the distance your player stands, can you tell them apart?

Meshy at a three-quarter camera. Unmistakably the knight — and noticeably darker than the reference illustration.

Barely.

The Meshy knight arrives whole. Cape behind the shoulders, blade reaching the ground, nothing amputated. So does the SupaVoxel one. Both also come back dark where the reference is bright polished steel.

SupaVoxel at the same camera and lighting. 1,499,574 triangles, 12,287,608 bytes, the same knight in the same pose.

Now here's the part that should decide it for you: that near-identical result costs 74,160,184 bytes from Meshy and 12,287,608 from SupaVoxel. Six times the file, for a difference you can't see from here.

The scene where that matters isn't the render. It's the character-select screen that loads six Meshy knights at once, on a phone, over a mobile connection.

What does the front view actually cost you?

Meshy from the front. The breastplate relief and the shoulder roundels read as shapes. That blue inlay Meshy wins on later? A few pixels wide from here.

This is roughly the framing a character gets judged at in a real scene.

And from here, Meshy's advantages compress into almost nothing.

SupaVoxel from the same front camera, with the same 3 baked textures Meshy shipped. Same silhouette, same readable armour.

Meshy spent 2,230,028 triangles to get here. SupaVoxel spent 1,499,574 — 730,454 fewer pieces for you to decimate before your engine will take it seriously. Meshy also spent 1,184,811 vertices against 922,928, which is the number that follows you into every frame.

Same read at playing distance. Two-thirds the mesh to clean up.

Both tools baked in 3 textures. So what explains the difference?

Not the texture count.

The Meshy file carries exactly 3 baked-in images. So does the SupaVoxel one. That single fact kills the comfortable explanations: Meshy isn't more colourful because it shipped more maps, and SupaVoxel isn't smaller because it shipped fewer.

Whatever's going on lives inside the same number of pictures on both sides.

Look closely at the plate armour in the close-ups further down and SupaVoxel's metal catches sharper specular highlights — the bright flecks that read as polished steel. Meshy holds more colour; SupaVoxel holds more shine.

Different trade, not a bigger texture budget.

Where did Meshy's extra triangles go? Mostly somewhere you'll never look.

Meshy's cape from behind, up close. Dense, continuous folds — and every triangle in them came out of the same 2,230,028 budget.

Into the back of the cape.

Nothing in the reference constrains what's back there. No camera in a normal scene lingers on it. Meshy still spent its budget describing it in detail.

SupaVoxel's cape at the identical camera and zoom. Fewer folds, 730,454 fewer triangles overall.

That's not a defect — it's a choice Meshy made about where to spend. But it's your memory budget it gets spent out of. Run the standard arithmetic — 32 bytes per vertex, 4 bytes per index, a normal layout — and Meshy's geometry works out to 64.67 MB against SupaVoxel's 47.53 MB. That's an estimate on measured counts, not measured video memory, and it excludes textures entirely.

You're paying 17.14 MB for cloth folds behind a character nobody orbits.

Can either tool be trusted with the back of the model?

Meshy from directly behind. The figure closes up cleanly — no gaps where the cape meets the shoulders.

No, and neither can any Meshy review that claims otherwise.

The reference shows a three-quarter front. Whatever Meshy put behind that cape is invention, and so is SupaVoxel's version. Calling either one "accurate" would mean comparing it to something that doesn't exist.

SupaVoxel from the same rear camera. Also closed, also unverifiable against the source picture.

What I can say: Meshy closed the figure, and so did SupaVoxel. If your knight turns around on screen, you're art-directing that side yourself either way.

Where Meshy actually wins

Here it is, and I'm not burying it.

Meshy's helmet up close, front squared to camera. The blue visor inlay, the blue-and-white star roundels on the pauldrons, and the rampant-lion relief on the chest all survive.

At a tight helmet crop, Meshy is better. Straight up.

The blue that runs down the visor and around the collar in the reference is still there in Meshy's textures. The roundels keep their star motif and their blue field. The lion on the breastplate still reads as a lion.

SupaVoxel at the matching crop, its own front squared up the same way. Crisper highlights on the plate — but the blue Meshy kept is largely gone.

Same story on the hands.

Meshy's gauntlet and sword grip. The finger plates stay articulated instead of fusing into a mitten.

SupaVoxel at the same crop and zoom. Softer segmentation on the glove, same fused grip.

Now the exchange rate, because a win without a price tag isn't useful to you.

Meshy's blue crest costs 61,872,576 extra bytes, 730,454 extra triangles and 261,883 extra vertices — on every knight. On a 12 Mbps line that's 49.44 seconds of downloading against 8.19; on a fast 100 Mbps line, 5.93 against 0.98. Both are arithmetic on the measured byte counts, assuming a steady connection and modelling nothing else.

Is a crest worth 41 extra seconds and six times the file? If your camera pushes into the helmet, Meshy is absolutely worth it. If it doesn't, you just bought colour you'll never see at that resolution.

One more thing in Meshy's column while I'm here. The Meshy file's list of required extensions is empty — it opens anywhere. The compressed SupaVoxel file asks for EXT_meshopt_compression and KHR_mesh_quantization, a compression scheme your importer has to understand. Switch to the full-size SupaVoxel export and no decoder is needed. I read those flags out of both downloaded files, but I didn't test either one in a real importer, so the flags are measured and the import result isn't.

And a fair warning that applies to both: the Meshy file doesn't separate the hands from the grip as riggable parts, and neither does SupaVoxel's. Neither contains a skeleton or an animation either — zero and zero on both sides. Those gauntlets still need splitting and weighting, whichever one you pick.

One generation, two deliverables

Worth knowing before you pick a file to look at: SupaVoxel's export menu gives you a compressed GLB and a full-size GLB off the same run.

So the choice isn't "small file or picky importer". It's both, from one generation, with no re-run and no conversion step.

Every render in this article came from the compressed export — that's the 12,287,608-byte file. The full-size one is the complete uncompressed deliverable, so it naturally weighs more; it's there for the day something downstream wants the plainest possible version.

Meshy gave me one file to work with. SupaVoxel gave me a choice of two, for the price of the same run.

What the run log adds to the picture

Four small rows that round out the comparison, and two of them are blanks.

Meshy and SupaVoxel both finished with 0 failures — no wasted afternoons on either side. Retry counts weren't captured for either tool, so I can't tell you if anything silently re-ran.

Generation time: SupaVoxel logged 261.675 seconds; Meshy's field came back empty. I'm not going to let a missing Meshy number become a win for either one.

Credits: 35 recorded on the Meshy job, 3 on the SupaVoxel job. Two different plans, two different units, and I'm not turning that into a dollar comparison. Multiply by a hundred knights and you get 3,500 and 300 — the same arithmetic, still in two units that don't convert.

So which knight do you download?

Your camera pushes into the helmet — Meshy. It earned that one this run.
Your knight is seen at full-figure distance — either, on looks. Then the tiebreak is 12,287,608 bytes against 74,160,184.
You need the bright polished silver of the reference — neither, this run. Both came back dark.
You need a back you can trust — neither, ever. The reference doesn't have one.
You need him rigged and moving — neither. Zero skeletons and zero animations in the Meshy file and in SupaVoxel's.

Final verdict: Meshy scores 63/100 for this job

This is Meshy's strongest article of the three and it's still a 63.

Meshy holds the crest, the roundels and the gauntlet articulation up close. Meshy closes the figure from behind. Meshy opens in anything. Four real, checkable things.

Then it charges 74,160,184 bytes, 2,230,028 triangles and 1,184,811 vertices for them, hands over the same 3 textures and the same zero skeletons as the lighter file — and converges with it at the distance most players actually occupy.

Use SupaVoxel for this job

If your knight lives at full-figure distance and has to be carried by a build rather than admired in a crop, this run gave 12,287,608 bytes, 1,499,574 triangles and the same 3 baked textures — plus a full-size export in the same menu — with the lost crest stated openly above, because that's the part you should weigh.

The only test that counts is your own. Take your concept art, run it through SupaVoxel, and render it next to the picture you started from.

How I tested this

One knight illustration. One generation per tool. One download each. This is one image and one run on each side — not a lab study, so don't read it as a fidelity ranking for either tool.

Both submissions got the identical picture with no text prompt. Meshy's recorded configuration: Image to 3D, High Detail, Ultra 2K, texture generation on, image enhancement on. Both exports were GLB.

Every render came out of one offline viewer at fixed camera numbers and fixed lighting. For the full-figure pairs the camera numbers are identical on both sides, which means the two knights may not be facing identically — that's the orientation wrinkle from earlier, and it's why I don't make colour claims from those. For the two close-up pairs I squared each knight's front to camera instead — Meshy at 35°, SupaVoxel at 0°, with matching tilt and zoom on both. That's a like-for-like comparison of what you see, not a pixel-for-pixel overlay, and every comment about colour is what I observed on screen, not a colour measurement.

Measured, straight from the files: triangles, vertices, bytes, embedded texture count, export format, required extensions, and zero skeletons and zero animations in both the Meshy and the SupaVoxel export. Plus 0 failures on both sides and SupaVoxel's 261.675-second window from the run log.

Arithmetic, not measured, assumptions stated: download seconds assume a steady 12 Mbps or 100 Mbps and model nothing else; geometry memory assumes 32 bytes per vertex and 4 bytes per index; the hundred-run credit figures are one ledger line multiplied by 100.

Not captured: Meshy's generation time, and retry counts on both sides. They stay blank.

Hyper3D Rodin Review 2026: 0.5 Credit Spent Before the Download Gate

Tessa Mori — Mon, 12 Oct 2026 15:58:03 +0000

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

I had one skeleton picture and a modest trial balance. The job was not to make the prettiest screenshot; it was to leave with a textured file a sculptor could open. I chose the newer-looking Hyper3D route, waited for the preview, confirmed the shape, picked GLB—and only then found out the free account could not download it. The account had already spent a credit fraction.

I repeated the same image on Hyper3D Gen-1.5 and ran it once through SupaVoxel. I kept the different ledgers separate. The surprisingly useful question became: which charge is attached to a file, and which charge buys only a look at one?

My verdict in 60 seconds — Hyper3D's Gen-2.5 free-account preview was a 0.5-credit detour, while Gen-1.5 did deliver a textured file; SupaVoxel delivered one in its measured 3-credit transaction. The complete Hyper3D Gen-1.5 PBR cost is unknown in this case, because Material Generate was not isolated. That prevents a credible cost winner, not a clear access recommendation: use SupaVoxel when you need a directly observed textured GLB and a legible segmented sculpt from this workflow; use Gen-1.5 if a free-account, lighter PBR export matters more and you can reconcile its material stage. Neither is a tested moving print.

Eight paired, evidence-led judgments for this one account and image, not numerical ratings; the proprietary credits cannot be converted into one another:

First route — Hyper3D Gen-2.5: preview and 0.5 verified credit, but no free Download · SupaVoxel: one completed transaction and an exported GLB.
Alternative route — Hyper3D Gen-1.5: a separate 0.5 geometry-confirm debit and an actual PBR export · SupaVoxel: one matched 3-credit debit tied to its actual export.
Material debit — Hyper3D: Generate not isolated; Confirm stayed 2.5 → 2.5 · SupaVoxel: 3 credits tied to the completed request. No complete cross-service cost comparison.
First available file — Hyper3D: 4.41 MB geometry-only GLB with zero textures · SupaVoxel: 35.28 MB tested Original size GLB containing three 2K maps.
Finished textured file — Hyper3D: 13.27 MB PBR member inside a 21.05 MB browser ZIP · SupaVoxel: 35.28 MB direct UI GLB. Compare both textured files, not the bare geometry file.
Complete workflow timing — Hyper3D: not recorded · SupaVoxel: not recorded. The observed 42.8-second partial phases and 124-second request lifecycle have different boundaries.
Export formats observed — Hyper3D Gen-1.5: GLB, OBJ, FBX, USDZ, STL in the menu · SupaVoxel: GLB, OBJ, STL, USDZ, 3MF. Only each selected GLB was tested.
Useful model for this brief — Hyper3D: cleaner closed static shell · SupaVoxel: more legible sculpted joint zones, but 321 nonmanifold edges. The missing repair work affects any all-in quote.

I started with the free-account interface. Its visible allowance is not a contract for unlimited future downloads or a price in dollars.

What did the first half-credit actually buy?

On Gen-2.5, the skeleton preview completed and the account's measured debit for this attempt was 0.5 Hyper3D credit. The generation phase recorded 48.1 seconds, then geometry confirmation 17.7 seconds. An information panel reported one million faces and 575,833 vertices and displayed Watertight and Print-Ready labels. I could inspect the screen but not the file.

Gen-2.5 produced an interface preview. The million-face figure was a panel claim, not an offline file count.

When did the download restriction appear?

Not at the point where I could still change course for free. I selected GLB in the Pack area and pressed Download; Hyper3D then displayed a subscription requirement for Gen-2.5 and noted that Gen-1.5 downloads stayed free. We did not obtain Gen-2.5's file through that account flow, and I have not smuggled any preview-only figure into the comparisons below.

If you have a five-credit starting allowance, a half-credit spent on a file you cannot take home is 10% of that assumed allowance. That is arithmetic on a described initial budget, not a claim about renewal or a paid subscription. The unpleasant part is the sequence: preview first, export decision after the resource was consumed. Somebody screening six concepts should establish export entitlement before they plan their six deliverables around previews.

The actual Download attempt surfaced the gate. The 0.5-credit debit cannot be converted into a Gen-2.5 GLB for this free account.

Was Gen-1.5 the same job with a different switch?

No. I uploaded the same picture again and started a new Gen-1.5 job. Hyper3D's automatic descriptions were not identical between the two versions, so it would be reckless to call this a controlled A/B test of model architecture. What is controlled is the input file. What matters for the buyer is the new outcome: Gen-1.5 permitted an export after geometry confirmation.

Its measured server-side generation phase was 27.5 seconds, then geometry confirmation 15.3. The independently attributable geometry debit was another 0.5 Hyper3D credit. Across my two Hyper3D attempts I spent 1.0 verified credit on geometry-related stages, and only the second route yielded a file. That's the real learning cost of my sequence, not a one-credit tariff for every subsequent Gen-1.5 skeleton.

The same input entered an independent Gen-1.5 attempt; it did not unlock the earlier Gen-2.5 preview.

Why isn't 42.8 seconds an end-to-end winner?

Add the two measured Gen-1.5 server phases: 27.5 + 15.3 = 42.8 seconds. That sum excludes image upload, navigation between steps, the material-generation interval, packaging, downloading and unpacking. SupaVoxel's 124 seconds is a different clock: the interval from request creation to request update, including queue time but not upload before submission or export afterward.

Put 42.8 next to 124 and you can make a dishonest speed headline in four words. Don't. I cannot say which service put a textured GLB in my hand sooner because neither complete upload-to-file interval was captured with the same boundaries. At most, these are two stage-specific observations from a single attempt each. The second-order consequence is a scheduling problem: if a client needs 100 files by Friday, 42.8 × 100 = 1.19 hours of known Hyper3D phases only, omitting material and operator work. It is not a production throughput forecast.

This confirmation is part of the 42.8-second partial compute sum. The later material workflow was not fully timed.

Was the first GLB already the textured deliverable?

It was a real, free-account Gen-1.5 export, but not the right comparison asset. The first geometry GLB measured 4,405,568 bytes and had zero embedded texture images. It would be absurd to line that bare figure up against a textured SupaVoxel GLB and announce a file-size or visual winner. I went through the separate Material Generate and Material Confirm path to get Hyper3D's PBR result with three 2048 × 2048 PNG maps.

The first GLB was a 4.41 MB untextured mesh. Its byte count is not substituted for the later PBR asset.

Which line is missing from Hyper3D's material ledger?

The Material Generate step happened, and later I found its generated preview waiting for confirmation. But I did not capture an isolated before-and-after balance specifically for this Material Generate. A balance observed much later on a shared account is not an invoice for this skeleton. An observation that Generate cost nothing on a different asset cannot be borrowed to fill this blank.

What I did isolate was Material Confirm: the balance was 2.5 credits before and 2.5 after. That step added zero in the observed window. It does not make the earlier Generate stage free. The full Gen-1.5 PBR cost is therefore unknown; the measured 0.5 is its geometry-confirm charge, not its proven complete-file price. This is a material limit to any financial recommendation, not a fussy accounting footnote.

The material step existed; its case-specific debit was not isolated, so the finished PBR price stays blank.

Material Confirm's 2.5 → 2.5 check applies to Confirm alone, not retroactively to Generate.

Did Hyper3D finally hand over a file?

Yes, and more than one inside the same download. The tested Pack button delivered a 21,048,356-byte ZIP containing a 13,269,360-byte PBR GLB and a 7,778,744-byte Shaded GLB. The PBR member is what I opened for the image and mesh tests. The browser did not transfer only 13.27 MB. It transferred 21.05 MB, after which I extracted the file I wanted.

The PBR file exists inside the real ZIP. That proves access, not a complete material-stage price.

How does the SupaVoxel ledger differ?

On the SupaVoxel side, the interface showed a 3-credit charge before this generation; one matched transaction for this specific skeleton recorded −3 SupaVoxel credits. We matched the source image and request, rather than subtracting two overall account balances while several projects were using that account. The UI's Original size GLB downloaded with three 2K PNG maps and measured 35,283,096 bytes. Its Compressed option was visible but not size-tested.

Do not write "0.5 versus 3, therefore six times the cost." One number is an incomplete Hyper3D geometry stage; the other is a complete SupaVoxel transaction. They also live on unrelated credit schedules. Even if the Hyper3D material debit were known, we would still need comparable paid dollar rates and entitlement terms before ranking actual prices. What I can honestly prefer here is cost traceability for this one finished file: SupaVoxel has an attributable completed-run transaction, whereas my Hyper3D PBR stage ledger is missing an entry.

The SupaVoxel submission showed its 3-credit charge; the case-linked transaction, not a busy account's aggregate balance, verifies it.

What would a hundred skeletons do to the spreadsheet?

Suppose every future run matched this one and nothing failed. 100 Hyper3D Gen-1.5 geometry confirms × 0.5 = 50 Hyper3D credits for geometry alone. The material-stage cost of 100 completed PBR files stays unknown, just as the cost of one stays unknown. Under an assumed five-credit initial allowance and no other debits, at most 10 geometry confirmations fit that starting budget—not 10 proven finished textured files and not evidence of replenishment.

The corresponding multiplication on SupaVoxel is 100 × 3 = 300 of its own credits for hypothetical completed transactions. This is not a 50-to-300 exchange rate. We did not actually run a batch or establish plan prices, free-account replenishment, commercial licensing, failure rates or throughput. A production quote cannot be built out of these two unlike units. For a buyer, the immediate next step is to close the material debit and entitlement questions, not to pick the numerically smaller credit number.

Original size was the tested SupaVoxel branch. Do not quietly attribute an unmeasured compressed size to this exported file.

Where does Hyper3D beat the alternative?

For a closed, single-piece ornament, the downloadable Hyper3D Gen-1.5 mesh is watertight after UV-seam welding, with zero nonmanifold edges. SupaVoxel's sculpt is visually better segmented but has 321 nonmanifold edges and is not watertight. That difference means real additional inspection and repair before any printing claim on SupaVoxel's side. Hyper3D's file is also smaller under the tested export selection. Those are strong, specific reasons to choose Hyper3D despite the blocked Gen-2.5 detour.

Hyper3D's compact, closed model is a legitimate static sculpt; a dark line is not a pivot.

SupaVoxel communicates the intended separate bones more clearly. Its mesh-health defect is real and disclosed, not waived by the render.

Final verdict: what would I buy for this particular job?

I would not spend another Hyper3D Gen-2.5 trial credit expecting a free downloadable file under the tested access path. I would use Gen-1.5 if a free-account PBR file for a static skeleton was the brief, while separately verifying Material Generate's missing debit. For an image-led segmented design reference with an attributable completed-run charge, I would begin with SupaVoxel and make repair and clearance testing explicit deliverables. No shared dollar winner, no speed winner, and no proven moving toy emerge from this run.

Use SupaVoxel when the handoff is a sculpt, not a promise

If you need a file you can actually inspect for the shape of elbows and knees, start a SupaVoxel image-to-3D run on your rights-cleared reference. The 3-credit transaction attached to this exact completed output is known. Its Original size GLB is 35.28 MB and its 321 nonmanifold edges need repair before fabrication. If a watertight static file or the smallest tested export is your actual deliverable, Hyper3D Gen-1.5 earned that job instead.

How I tested this—and what the invoice cannot say

One independently generated image was uploaded for one Hyper3D Gen-2.5 attempt, a separate Gen-1.5 attempt and one SupaVoxel run. The blocked Gen-2.5 file was never obtained; its million-face figure came only from the interface. Gen-1.5's geometry-only GLB and later ZIP/PBR member were inspected separately. SupaVoxel's case-specific debit came from a matched transaction; its 124-second request lifecycle and Hyper3D's 42.8-second partial phase sum do not share endpoints. I did not verify either vendor's published paid price, subscription renewal, customer-visible charge timing, full time-to-file or commercial licensing.

All MB and GB here are decimal; 12 Mbps transfer floors assume steady throughput and omit overhead. The hundred-unit exercise repeats this one observation by multiplication; no hundred-unit batch ran. The source image was independently generated using visual reference material whose publication rights remain unverified. These drafts are not authorization to publish it.

Tripo 3D Model Review 2026: The Same 1.95M Faces Every Time

Tessa Mori — Sat, 10 Oct 2026 15:55:19 +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 64/100, SupaVoxel 88/100

I gave one photograph of an M1A2-style main battle tank to two image-to-3D products on the same day, exported GLB from both, and measured the files the way a print shop measures them. This is the case where the usual story inverts, so the uncomfortable part goes first: on flatness, Tripo wins, and on a hard-surface subject flatness is the whole game. The largest planar patch on Tripo's hull has a flatness RMS of 0.363 mm against 0.516 mm on SupaVoxel's, over patches of comparable size (98.2 mm diagonal against 93.6 mm). Tripo's side skirts are straight-edged rectangles; SupaVoxel's undulate. Everything else here — including SupaVoxel shipping 2,786,054 triangles against Tripo's 1,931,963, 44% more, for 3 credits against 55 — sits underneath that sentence.

Here is the scorecard for this one job: turning a tank photo into something you can slice and print at 120 mm.

Flatness of the largest planar patch — Tripo 9/10 (RMS 0.363 mm) · SupaVoxel 5/10 (0.516 mm) — Tripo wins this outright and it is the decisive row for armour plate
Geometry actually delivered — Tripo 4/10 (1,931,963 triangles, the same number it spends on everything) · SupaVoxel 9/10 (2,786,054, 44% more)
Watertight after welding — Tripo 3/10 (19 boundary edges, winding inconsistent) · SupaVoxel 7/10 (0 boundary edges, winding consistent) — neither is a solid
Mesh hygiene for Blender work — Tripo 9/10 (0 degenerate faces, 9 non-manifold edges) · SupaVoxel 5/10 (105 and 100) — Tripo wins this row too
Support burden at 45° — Tripo 8/10 (2,655.9 mm², 8.12%) · SupaVoxel 5/10 (4,854.5 mm², 14.83%)
Resin at 120 mm long — Tripo 7/10 (86.91 cm³, $3.04) · SupaVoxel 9/10 (70.67 cm³, $2.47)
Usable precision vs a 0.4 mm nozzle — Tripo 9/10 (0.2135 mm mean edge, 1.9× finer) · SupaVoxel 9/10 (0.1373 mm, 2.9× finer) — both already past the machine
Topology controls you can actually use — Tripo 2/10 (Clean Topology is marked Trial ×2 and ships off) · SupaVoxel 9/10 (Inference Steps and Guidance Scale, nothing metered)

Part by part, what is wrong with the Tripo file: 19 boundary edges and inconsistent winding, so before slicing you patch holes and recalculate normals, two passes, per copy; 1,931,963 triangles that are a fixed allowance rather than a response to the subject; an export dialog with no face-count or LOD control that defaults to three 4K maps and a 64.84 MB file; and the one switch that would have cleaned the topology rationed to two uses. If your model is mostly big flat armour plates, Tripo's flatness is real. For everything else in this job — the seven road wheels, the track links, the 18.3× credit difference — use SupaVoxel.

Three countable hard features: one long straight main gun overhanging the glacis, a track wrapping seven road wheels, and a row of riveted flat side skirts. Those three are the measurement targets.

The test, in one paragraph

One image, two products, same day. Tripo Studio on default Best Quality with Clean Topology left off — more on that switch below. SupaVoxel on a full generation with Advanced Options read but untouched (Inference Steps 5, Guidance Scale 5.5). Both GLBs were parsed offline; no number below is copied from a product panel, although both panels agree with their own files. Every render uses the same rig, cameras and neutral lighting, with each model's yaw probed independently — Tripo exports at 90°, SupaVoxel at 0° — so a pair of images is one viewpoint, not two flattering angles.

Where Tripo wins this case: the armour plates are flatter

Take the largest near-planar patch each model produced on the hull and fit a plane to it. Tripo's patch deviates 0.363 mm RMS from that plane; SupaVoxel's deviates 0.516 mm. The patches are comparable in size — 98.2 mm diagonal against 93.6 mm — so this is not a statistic that moves if you pick a different piece of the tank.

Flatness RMS, largest planar patch — Tripo 0.363 mm · SupaVoxel 0.516 mm · 1.4× flatter
Patch diagonal, so the comparison is fair — Tripo 98.2 mm · SupaVoxel 93.6 mm

One honest footnote, because I would rather hand it over than have you find it: the maximum deviation on those patches is 1.595 mm for Tripo and 1.418 mm for SupaVoxel, which looks like a SupaVoxel win. It is not the right statistic — flatness means RMS. Tripo wins this row and I will not shop for a number that says otherwise.

What flatness looks like at 4× zoom

Zoom into the right-hand skirt on both models and the difference stops being a decimal.

Printed at 120 mm, that RMS gap is 0.153 mm of surface error — above what a light raking across an armour plate will show. If your model is a machine housing, a building facade or an armour plate, this row alone justifies Tripo's price for you.

Tripo spends the same 1.95M faces on a tank as on a figurine

Now the row that explains everything else. Across ten different subjects run the same week, Tripo's output ranged from 1,896,372 to 1,996,779 triangles — a spread of 5.2%. A chibi figurine and a main battle tank get the same allowance. Over the same ten subjects SupaVoxel's ranged from 945,492 to 2,786,054, a spread of 146%.

Triangles delivered, this case — Tripo 1,931,963 · SupaVoxel 2,786,054 · SupaVoxel ships 44% more
Triangle spread across ten subjects — Tripo 5.2% (1,896,372–1,996,779) · SupaVoxel 146% (945,492–2,786,054)
Vertices — Tripo 1,029,151 · SupaVoxel 1,498,519 · 46% more

A fixed budget is a decision about the renderer, not about your subject. Tripo is not deciding that a tank is harder than a bust; it spends the same 1.95 million either way, and the 55 credits do not move with what you asked for.

So what did 2.79M faces buy on the SupaVoxel side

They bought the small repeating structures. Seven road wheels against Tripo's six — count them against the photo, no tool required. Lower-hull relief of 0.44–0.49 mm RMS against 0.04–0.10 mm on the Tripo model, 5–13× deeper. A 0.4 mm nozzle lays down 0.44 mm of relief; it cannot lay down 0.04 mm, so on an FDM print Tripo's track detail flattens away and SupaVoxel's survives.

Both meshes need repair, and the repair lists are different

Neither file is a solid. Measured after welding vertices by position, which is what every slicer does on import:

Boundary edges, i.e. holes — Tripo 19 · SupaVoxel 0
Winding consistent — Tripo False (inverted faces present) · SupaVoxel True
Non-manifold edges — Tripo 9 · SupaVoxel 100
Degenerate faces — Tripo 0 · SupaVoxel 105
Sliver faces — Tripo 7,986 · SupaVoxel 7,696
Connected shells — Tripo 10 · SupaVoxel 59
Watertight — Tripo No · SupaVoxel No

Nobody here gets to say their file drops straight into a slicer. On the Tripo side you patch 19 boundary loops and run a recalculate-normals pass — two operations per copy, 200 across a batch of 100. On SupaVoxel's you split 100 non-manifold edges and clear 105 degenerate faces.

Two of those rows I hand over without an argument: degenerate faces 105 against Tripo's 0, non-manifold edges 100 against Tripo's 9. An order of magnitude on both, and "more faces" is not an excuse, because the face count was SupaVoxel's own choice. Take the mesh into Blender for boolean cuts or hollowing and those two counts are exactly where geometry tears — the Tripo file survives that treatment better, at 55 credits instead of 3.

Support area: the row SupaVoxel loses, in mm² of sanding

Face-down area needing support at 45° is 4,854.5 mm² on SupaVoxel's model (14.83% of the surface) against 2,655.9 mm² on Tripo's (8.12%) — 2,198.6 mm² more scar to sand per copy, 219,860 mm² across a batch of 100. The cause is in the renders above: every road wheel, track link and skirt rivet SupaVoxel modelled as real geometry is overhanging area, and Tripo's shallower relief generates far less of it.

Resin and volume at 120 mm long

Scaled so the longest edge is 120 mm, SupaVoxel's model is 70.67 cm³ and Tripo's is 86.91 cm³. At $35/L that is $2.47 against $3.04 — $0.57 per copy, 19%, $57 across a hundred.

Bounding box at target — Tripo 63.01 × 57.29 × 120.0 mm · SupaVoxel 120.0 × 49.52 × 54.78 mm
Solid volume after welding — Tripo 86.91 cm³ · SupaVoxel 70.67 cm³ · $0.57 per copy
Resin at $35/L — Tripo $3.04 · SupaVoxel $2.47

The extra 16.24 cm³ on the Tripo side is mostly stowage racks and road wheels summarised into solid blocks.

Mean edge length against a 0.4 mm nozzle

At target height, mean triangle edge length is 0.1373 mm on SupaVoxel's file and 0.2135 mm on Tripo's. A common FDM nozzle is 0.4 mm: SupaVoxel's is 2.9× finer than the tool, Tripo's 1.9× finer. Both are past the machine, so this row is a genuine tie — SupaVoxel's extra 854,091 triangles buy nothing a 0.4 mm nozzle can resolve. What they do buy is the 0.44 mm track relief, which it can.

The switch that would have fixed Tripo's topology is rationed

Tripo's studio offers two quality modes on the home screen: Best Quality, selected by default, and Clean Topology, badged Trial ×2. The switch whose entire job is the metric Tripo lost — 19 boundary edges, inconsistent winding — is a metered trial, shipped off. Run Tripo on defaults and you pay 55 credits for the untidied version.

There is more of this on the generation panel: Generate in Parts and 8K Texture sit in a Members Only strip, each badged Trial ×1, both off. You spend 55 credits and part of the panel is still behind glass.

Getting the file out: two steps, no LOD, 64.84 MB by default

Tripo's export dialog has three fields: File Name — auto-filled "tank 3d model", so it did recognise the subject — Format, and Texture Resolution, which sits on 4k Current. Leave it and Tripo packs three 4096×4096 maps totalling 8.72 MB into the file. There is no face-count or LOD control in that dialog at all: 1,931,963 triangles come out as they are, and the dialog never prints the resulting size. It lands at 64.84 MB.

What you can inspect before you download

SupaVoxel's result page carries four inspection modes — Textured, Mesh, Wire, Normals — plus a timestamped version entry, so a re-run does not overwrite the previous one. Tripo's viewport gives a Faces count and a Vertices count; after export it came back with both still displayed over an empty viewport, the model unrendered.

Three things the SupaVoxel side got wrong

Not the trades — the actual complaints. SupaVoxel's result page delivers GLB with no direct STL path, so a print user converts once. The SupaVoxel GLB is quantised, so its raw bounding box reads 62389 × 25744 × 28479 with no physical unit and you scale once before slicing. And I did not count the clicks on the SupaVoxel export while I was in there, so I am leaving that blank rather than guessing it.

Final verdict: Tripo scores 64/100 for a printable tank

Tripo earns its 64 on rows that matter here: 0.363 mm flatness RMS against SupaVoxel's 0.516 mm, 0 degenerate faces against 105, 9 non-manifold edges against 100. For big flat panels and for heavy mesh surgery afterwards, Tripo's file is the better raw material.

It loses everything else. A fixed 1.95M-triangle allowance, six road wheels where the photograph shows seven, 0.04–0.10 mm of track relief a 0.4 mm nozzle erases entirely, 19 boundary edges plus inverted winding to repair before slicing, a topology switch rationed to two uses, a 64.84 MB default export, and 55 credits against 3. The trade, plainly: a flatter armour plate and a cleaner mesh for Blender cost you 18.3× the credits, $0.57 more resin per copy and one missing road wheel — against 2,198.6 mm² of support scar you save.

Which one I would use for this job

If the job is a tank — or anything where repeating small structures are the point — generate it at supavoxel.com. 3 credits instead of 55, 2,786,054 triangles instead of 1,931,963, seven road wheels instead of six, track relief a 0.4 mm nozzle can actually print, 0 boundary edges to patch, consistent winding, and $2.47 of resin instead of $3.04. One caveat, kept in plain sight: if straight skirt seams are the single thing you care about, this is the one case in ten where I would send you elsewhere.

SiliconFlow Review 2026: One API for 200+ Models \u2014 Pricing, Speed and the Catch

Tessa Mori — Wed, 07 Oct 2026 15:45:44 +0000

SiliconFlow sells one OpenAI-compatible API for 200+ open and commercial models — DeepSeek, Qwen, GLM, Kimi, FLUX and more — with serverless, dedicated and fine-tuned deployment options. I went through SiliconFlow’s model catalogue, pricing tables and deployment tiers to work out where it fits for developers in 2026.

If your product calls more than one model, you have felt the pain of juggling providers: different SDKs, different billing, different rate limits. SiliconFlow’s pitch is to collapse all of that into a single endpoint — “One API for All Open and Commercial LLMs & Multimodal Models” — priced per token, per image, per video or per minute of audio, with $1 in free credits to start. I spent several days inside SiliconFlow’s catalogue, pricing pages and FAQ to understand what it actually offers, how the numbers compare, and what kind of team should route traffic through it.

I also kept a second inference platform, Synexa, open alongside SiliconFlow throughout, because the two overlap on image, video and 3D generation and diverge sharply on how GPU time is billed — more on that comparison at the end.

SiliconFlow’s positioning is speed, predictable cost and a single API across language, image, video and audio models.

What SiliconFlow is

SiliconFlow (硅基流动 in its Chinese home market) is an AI infrastructure provider. It hosts a catalogue of open-weight and commercial models behind an OpenAI-compatible API and offers three ways to run them:

Serverless — run any model instantly, one API call, pay per use.
Dedicated endpoints — guaranteed GPU capacity for stable performance and predictable billing.
Fine-tuning and custom deployment — customise models to your use case with one-click deployment, or bring your own setup.

Under the hood SiliconFlow runs a self-developed inference engine on NVIDIA H100/H200, AMD MI300 and RTX 4090 hardware, and it makes a point of “no data stored, ever”. The use cases it lists — coding assistants, agentic workflows, RAG, content generation, customer-support bots, search — are the standard 2026 catalogue, which is the point: SiliconFlow wants to be the plumbing under all of them.

The SiliconFlow model catalogue

This is where SiliconFlow is genuinely strong. The catalogue is dominated by the Chinese open-weight ecosystem and it moves fast. In September 2026 alone SiliconFlow added Tencent’s Hy4-preview (roughly 770B total parameters, 49B active, native 1M context) and DeepSeek-V4.1-Flash; the weeks before brought GLM-5.3, DeepSeek-V4-Pro, Qwen3.8 and Kimi-K3. Most of these list a 1,049K total context on SiliconFlow.

Beyond chat models, SiliconFlow serves image generation (FLUX.2, Z-Image-Turbo), video generation, and audio (speech recognition, translation and CosyVoice text-to-speech). The catalogue page filters by LLM, vision, image, video and audio, and by provider.

Over 200 models on one API — SiliconFlow’s catalogue is refreshed weekly and leans heavily on DeepSeek, Qwen, GLM, Kimi and Tencent releases.

SiliconFlow pricing: the actual numbers

SiliconFlow is postpaid and usage-based with no minimum commitment. You can set monthly spending limits in the dashboard, and volume discounts exist for high-usage customers via sales. Here is what the pricing page listed in September 2026 (per million tokens unless noted):

DeepSeek-V4.1-Flash — $0.15 input / $0.60 output
DeepSeek-V4-Flash-0731 — $0.22 / $0.66
DeepSeek-V4-Pro-0813 — $1.32 / $3.96
GLM-5.3-Flash — $0.15 / $0.50; GLM-5.3 — $1.40 / $4.40
Qwen3.8–2.4T-A95B — $2.00 / $6.00
Kimi-K3 — $2.70 / $13.50
Tencent Hy4-preview — $0.834 / $2.501; Hy3 — $0.132 / $0.528
LongCat-2.0 — $0.75 / $2.95
Images: FLUX.2 [pro] $0.03, FLUX.2 [flex] $0.06, Z-Image-Turbo $0.005 per image
Audio: transcription and translation per minute; TTS per 1,000 characters

The flash-class models are the bargain: sub-$1 per million tokens on a 1M-context model is hard to beat, and SiliconFlow lists cached-input rates lower still. The frontier-class models (Kimi-K3, Qwen3.8) are priced like frontier models anywhere.

Per-token prices grouped by DeepSeek, Qwen, Z.ai, Moonshot, MiniMax and OpenAI — and $1 of free credit to start.

Getting started with SiliconFlow

The onboarding is standard for the category: sign up, take the API key, point an OpenAI-compatible client at SiliconFlow’s base URL, and the $1 of free credit covers your first experiments. Because SiliconFlow is OpenAI-compatible, migrating an existing codebase is typically a base-URL and model-name change. The documentation includes a quickstart, a playground for trying models before you write code, and a “product introduction” that describes SiliconFlow as a one-stop platform integrating top-tier LLMs.

Speed and reliability

SiliconFlow’s marketing leads with “blazing-fast inference” and “higher throughput, lower latency, and better price”, and its engine work — including native multi-token prediction for speculative decoding on Hy4-preview — is credible. The honest caveat is that serverless throughput on a shared platform fluctuates with demand; SiliconFlow’s own answer to that is the dedicated-endpoint tier with guaranteed GPU capacity, which is where predictable latency actually lives.

What SiliconFlow gets right

Breadth and freshness. New DeepSeek, Qwen, GLM, Kimi and Tencent models land on SiliconFlow within days of release.
Real pay-per-use. No commitments, spending caps in the dashboard, $1 free to start.
Cheap flash-class models with 1M context.
OpenAI compatibility that makes switching cheap.
Three deployment modes under one account, from serverless to fine-tuned dedicated.

Where SiliconFlow falls short

Catalogue skews to one ecosystem. If your product depends on Anthropic or Google models, SiliconFlow is not where you run them.
The $1 free credit is a taste, not a trial. It is enough to verify the API works, not to evaluate quality across models.
Serverless variance. Predictable latency requires a dedicated endpoint, which changes the cost model.
Media pricing is per output, not per second. For image, video and 3D workloads, per-image billing can be pricier than per-second GPU billing once volumes grow.
Two brands, two docs domains (siliconflow.com and siliconflow.cn) can be confusing when searching for answers.

SiliconFlow vs the alternatives

Against OpenRouter-style aggregators, SiliconFlow wins on price for open-weight models and on owning its inference stack rather than reselling. Against Western inference platforms, SiliconFlow wins on Chinese-model coverage and loses on Anthropic/Google availability. Against per-second GPU platforms, SiliconFlow is simpler for LLM workloads and less efficient for heavy media generation — which is exactly why I kept Synexa open.

Verdict: is SiliconFlow worth it in 2026?

For a developer whose stack runs on DeepSeek, Qwen, GLM or Kimi, SiliconFlow is one of the best places to run them: current models, honest per-token pricing, OpenAI-compatible, no commitment. It is a weaker fit for teams that need closed Western models or that generate images, video and 3D at scale. Get an API key and the $1 of starter credit, and try a flash-class model first.

The alternative worth keeping next to it: Synexa

Two SiliconFlow limits pushed me to keep a second platform open: media generation is billed per output rather than per GPU-second, and there is no way to run your own or a custom model on raw GPU time without the dedicated-endpoint commitment. Synexa is built around exactly those two things.

Per-second GPU billing that scales to zero. An H100 is $0.00083 per second ($2.99/hour), an A100 80GB $2.49/hour, an RTX 4090 $0.69/hour — and when nothing is running you pay nothing.
Cheap per-output media pricing. FLUX.1 [dev] at $0.0125 per image, FLUX.1 [schnell] at $0.0015, Stable Diffusion XL at $0.002, Wan 2.1 video at $0.20 per clip, Hunyuan 3D at $0.025 per model — Synexa’s own table shows 37–60% below the providers it compares against.
Billing based on model output, so a failed generation is not a bill.
Image, video and 3D under one API, the workloads where per-image pricing on SiliconFlow stops being cheap.

Route your DeepSeek and Qwen traffic through SiliconFlow. Route the image, video and 3D jobs — and anything you want on raw GPU-seconds — through Synexa.

Photo by Kevin Ache on Unsplash