DEV Community: Tariq Hassan

Higgsfield AI Video Review 2026: The 5-Second LUMA Unboxing

Tariq Hassan — Mon, 19 Oct 2026 15:44:13 +0000

This is an independent, documented hands-on comparison of two third-party tools; both were run on my own accounts — a free tier and a paid plan — with no vendor-provided access. The downloaded clips, visible settings, wallet changes and limitations matter more than any claim to neutrality.

The headline is not a failure story. Higgsfield delivered a playable LUMA phone-unboxing video from a text prompt. Its tested Wan 2.5 Fast setting was five seconds, however, while the request said eight. Kyncept delivered two visually distinct eight-second clips. Those are observations about these jobs, not success rates for either service.

My verdict in 60 seconds

For a brief reveal, the Higgsfield result is usable: box, opening, film and raised handset appear. For an eight-second deliverable, this tested selection is 2.958 seconds short. Both Kyncept runs supplied 8.000-second originals. None of the audio tracks proves the requested sounds synchronize with those actions.

Delivered clips: one tested Wan result and two Kyncept results; no zero-output narrative.
Runtime: 5.042 seconds versus 8.000 seconds on each Kyncept file, under different selected settings.
Turnaround known: Kyncept's UI stopwatch read 91.4 seconds, then 282.1 seconds. A comparable Higgsfield video completion time was not captured.
Sound: the downloaded files have non-silent AAC tracks; synchronization has not been checked by listening.

That is a narrower verdict than “which video generator wins?” It answers whether the actual files fit this particular edit.

The Kyncept video setup shows optional start and last frames, a text prompt and a 16:9 selection. No reference frame was provided for this test.

One prompt, two different duration settings

The test asked for an eight-second, 16:9 tabletop unboxing of a matte-black smartphone in a charcoal-and-teal LUMA box on a white table. A pair of hands should tear a pull tab, lift the hinged lid, peel transparent film and lift the handset to show its dark screen. It also asked for separately synchronized paper tear, hinge creak, film crinkle and tray click, with no voice or music. This was text-to-video, without an uploaded reference image or start/end frames. Both interfaces had 16:9 selected.

The prompt was adapted from a social-video inspiration, not copied verbatim; its popularity was not independently verified. The sequence of actions makes this a practical prompt to assess against sampled frames.

The Higgsfield video setup recorded the LUMA text prompt. The selected Wan job, rather than the eight-second wording inside that prompt, determined the shorter output setting.

Why “eight seconds” in the prompt did not deliver eight seconds

For the tested Higgsfield run, the interface selected Wan 2.5 Fast, 5 seconds, 720p and 16:9. The downloaded file was 5.042 seconds. Writing “8-second” inside the prompt did not turn the five-second setting into an eight-second setting. This is not evidence that every Higgsfield model is capped at five seconds; only this Wan selection was run in the phone case. It is also not an equal-settings race against Kyncept's eight-second output.

For one uninterrupted eight-second original: 8.000 − 5.042 = 2.958 seconds short. A loop or ending card could fill the timeline, but would not add generated footage. A five-second social cut could instead use the file at its measured length.

The playable Higgsfield result card identifies Wan 2.5 Fast and displays 5.0s and 16:9; the separately downloaded original measured 5.042s.

Higgsfield did produce the phone reveal

The single tested Higgsfield video is not a placeholder or a failed card. The result appeared playable in the interface, its individual job ID matched the downloaded MP4 URL, and the original file decoded. A four-frame contact sheet samples the video at 0.5, 1.8, 3.0 and 4.5 seconds. The first frame shows hands at a dark LUMA box; the second shows its opened packaging and handset; the third shows a sheet of film over the phone; the last shows the phone held up. That is a recognizable visual progression through the requested unboxing.

This is not proof of exact compliance. Four sampled frames show the broad sequence, not the hinge mechanics or frame-by-frame consistency of the package and handset. The main visual beats are represented; every spatial instruction has not been verified.

At 0.5/1.8/3.0/4.5s, the tested Wan clip moves from LUMA package to open box, film and raised handset. These are sampled stills, not a frame-by-frame fidelity audit.

The first Kyncept file uses the full eight seconds

Kyncept's first run completed in 91.4 seconds on the UI stopwatch and downloaded as an 8.000-second, 1280×720, 24 fps H.264 MP4 with stereo AAC, weighing 2,148,345 bytes. The account moved from 289 to 279 Kyncept credits, a ten-unit change for that job. This is a product-specific credit receipt, not a dollar cost or a currency comparable with Higgsfield's.

At 1, 3, 5 and 7 seconds, sampled frames show a LUMA-marked closed box, an opened tray, a peel of clear film and hands lifting the dark phone above the tray. These visual checkpoints fit inside the eight-second original. They do not verify its sound effects.

The first Kyncept job was observed generating before its finished video appeared; the measured 91.4s comes from the UI run, not this still alone.

The 1/3/5/7s samples show a LUMA lid, open tray, film peel and phone being lifted. The original runs 8.000s.

A second render is a second variant, not a duplicate

One successful clip tells you what one draw looked like. To check whether a second draw merely repeated it, Kyncept was run again with the same video text. The second original was another 8.000 seconds at 1280×720 and 24 fps, weighing 1,951,133 bytes. The wallet moved from 279 to 269, again a ten-Kyncept-credit change. It was not visually identical to the first: the four paired sampled frames gave grayscale SSIM readings of 0.5697, 0.5914, 0.4078 and 0.3310, with a mean of 0.4750. Here SSIM serves only as a difference check. It is not a quality score or a claim that the second video is better.

The second opening shows a more prominent pull tab; later samples show a dark handset, film peel and the phone held upright. A creator gains a choice of composition, not a measured service-wide diversity rate. Two runs versus one are not comparable success rates.

The project view displays two Kyncept LUMA video cards after the second job finished; the downloaded originals, not thumbnail count alone, establish the distinct variants.

At 1/3/5/7s the second Kyncept result shows a different pull-tab composition, opened box, peeling film and upright phone.

The slow second run changes the production plan

The second Kyncept job's UI stopwatch read 282.1 seconds against 91.4 seconds for the first: 190.7 seconds longer, roughly 3.09× as long. A creator should not promise a deadline based on the first run alone. Two jobs cannot establish typical completion time or a queue policy.

There is no symmetrical Higgsfield number to place beside those stopwatch readings. Its submission click was recorded, but the after-click script crashed before printing the timestamp needed to calculate precise UI completion. The raw response log also cut off its JSON at 1,500 bytes, so a full terminal status response was not independently parsed. The playable completed card, matched individual ID and decoded download establish delivery; they do not reconstruct the missing completion clock. “Higgsfield took X seconds” would be invented here.

The second Kyncept generation remained in progress before its later completion; its measured UI elapsed time was 282.1s.

The Higgsfield UI showed a generating state, but this screenshot cannot recover the missing after-click completion timestamp.

Soundtrack presence is not Foley accuracy

All three downloaded originals contain non-silent stereo AAC. Higgsfield's measured peak was approximately 0.0 dBFS; the Kyncept tracks peaked at −5.0 and −10.4 dBFS. Peaks establish signal level, not whether a paper tear, hinge creak, film crinkle or tray click coincides with the matching movement. The Higgsfield peak reaches the measured maximum; this alone cannot diagnose audible distortion.

No listening or speech-recognition check was performed. The prompt's “no voice or music” instruction is therefore unverified too. Before release, listen to the complete file against each action and replace mistimed audio if necessary. This is a recommendation, not an observed audio failure.

The finished video card confirms visual delivery; it does not show which sounds are present in the AAC track.

File specifications, without a false quality ranking

The Higgsfield original measured 1904×1104, 24 fps, 5.042 seconds, H.264/AAC stereo and 7,937,554 bytes. Kyncept's two originals were 1280×720, 24 fps, 8.000 seconds, H.264/AAC stereo, with byte sizes of 2,148,345 and 1,951,133. Higgsfield thus supplied more pixels per frame in this observed file, despite the selected UI label reading 720p. That is a useful file fact, but it does not isolate which service creates sharper images: the model, selected duration and generated compositions were not matched.

The byte counts are similarly operational rather than aesthetic. At an idealized 12 Mbps, the first Kyncept original's bytes alone would take about 1.432 seconds to transfer, versus 5.292 seconds for the Higgsfield original. Those are bytes × 8 ÷ 12,000,000, before network handshake, storage, transcoding or congestion. A shorter clip being the larger file is noteworthy for a transfer budget, but not proof of inferior compression or better-looking video under unequal outputs.

The Higgsfield video wallet receipt ends at one credit after starting at ten; the nine-unit change belongs only to Higgsfield's credit system.

A phone-launch edit: which original fits the timeline?

For an eight-second shot ending on a lifted handset, the tested Wan original leaves 2.958 seconds for an edit or additional footage. Its late sample already shows the lifted phone, so a compact reveal may use the file as delivered. This is a timeline fit, not a universal product ceiling.

Both Kyncept originals run 8.000 seconds and show a late phone reveal. The second composition cost another ten Kyncept credits and took 282.1 seconds on the UI clock. A five-second edit might instead value Higgsfield's 1904×1104 source raster. Duration, pixels and variant choice are measurable here; Foley timing is not.

The second Kyncept setup precedes a separately billed second generation, not an automatic extension of the first clip.

Where Higgsfield genuinely has an observed advantage

The Higgsfield job produced a playable, recognizable unboxing with a 1904×1104 file, compared with the 1280×720 Kyncept originals. More pixels can give an editor a larger source raster to crop or downscale; this test cannot guarantee extra visible detail in every frame. The shorter duration may be a feature for a short reveal when the brief permits it, rather than a defect. It becomes a shortfall only against this prompt's explicit eight-second delivery requirement.

A limited side observation from the same phone-package case: when both interfaces selected the publicly shown Nano Banana Pro image option, the two Higgsfield image completion cards were observed no later than 41.01 and 37.63 seconds; the paired Kyncept UI stopwatch readings were 55.7 and 54.0 seconds. That is an advantage in these two observed image jobs, not evidence about video generation time. Both sides also made recognizable LUMA cardboard imagery. Image rendering deserves its own comparison rather than being smuggled into a video-speed verdict.

This is an image result, not a second video test. Its first observed completion card was no later than 41.01s in the separate image run.

Final verdict: delivery is real, but the settings decide suitability

The tested Higgsfield Wan job succeeded: a playable, downloaded 5.042-second LUMA unboxing represented the major visual stages. It should not be described as zero clips, nor should its missing stopwatch value be guessed. Kyncept supplied two distinct 8.000-second variants, but their measured UI times spread from 91.4 to 282.1 seconds. One run on one side and two on the other cannot establish a failure rate or overall winner.

Which one I would use for this job

For this requested eight-second shot, I would begin with the tested Kyncept workflow at https://kyncept.com because its delivered originals fit the specified timeline; I would still audit the full soundtrack before release. For a compact five-second reveal where the larger observed source raster matters, the Higgsfield file is a usable option. This recommendation is conditioned on the delivered files, not a prediction that either product will repeat the outcome on the next prompt.

Tripo AI Review 2026: 5,500 Credits to Print 100 Robotic Arms

Tariq Hassan — Sat, 17 Oct 2026 15:46:49 +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 58/100, SupaVoxel 90/100

One photograph of a desktop robotic arm, run once through Tripo and once through SupaVoxel at stock defaults, with the credit balance on screen before and after each step. I bought the credits on both sides myself. Both products passed every part of the geometry test on this subject — real through-holes, a surviving cable, flat parallel plates. That is the unusual part, and it is what makes the money question the whole question: Tripo charged 55 credits and SupaVoxel charged 3 for an outcome that ties. 18.3×.

Credits for one arm — Tripo 55 · SupaVoxel 3 · 18.33×
When you are charged — Tripo on submit, balance 755 → 700 while the card still said Generating · SupaVoxel on submit, 337 → 334 · both charge up front, so abandoning mid-run refunds nothing on either side
When the price is shown — Tripo after upload, the button reads only "Generate" before that · SupaVoxel before upload, the button reads "Generate (3 credits)" on an empty workbench
Credits for a batch of 100 — Tripo 5,500 · SupaVoxel 300 · 5,200 credits apart
Wall clock, this arm — Tripo 175.0 s · SupaVoxel 139.6 s · SupaVoxel 35 s quicker on this one run
Wall clock across the ten subjects I ran — SupaVoxel is usually faster (quicker on 7 of 10, median 133.6 s against 163.5 s) and Tripo is far more predictable (135–189 s, a 54 s spread, against 100.2–867.4 s and 767 s). Two different things, and you need both to choose.
Resin for 100 arms at 120 mm — Tripo $877.00 · SupaVoxel $815.00 · only $62 apart
Trial-limited switches on Tripo's screens — Clean Topology ×2, Generate in Parts ×1, 8K Texture ×1
Download for a batch of 100 — Tripo 6.29 GB · SupaVoxel 0.56 GB

Three things before the detail. Tripo's 55 credits did not turn into material: $8.77 against $8.15, a gap of $0.62. Tripo does not tell you the price until the image is already uploaded. And on timing the two split the difference: SupaVoxel was quicker on 7 of my 10 subjects, while Tripo was the one that never had a slow run — both figures are below, because either alone is misleading.

For a workshop making this arm, once or a hundred times, I would use SupaVoxel — same three passes, 1/18.3 of the credits, and a batch that downloads in half a gigabyte instead of six.

The single input, 1,403,490 bytes. Flat link plates with cut-out windows and a three-strand servo loom — a hard-surface subject with nothing hidden. Both products received this file byte for byte and both were left on product defaults.

The price is on SupaVoxel's button before you upload; on Tripo's only after

On an empty SupaVoxel workbench the primary button already reads "Generate (3 credits)" and the balance sits in the top bar at 337. You know the cost before you decide to spend it.

Tripo's home screen shows a balance of 755 and a button that reads "Generate". No number. Upload the reference image and the same button becomes "Generate 55" — so the only way to discover what a Tripo run costs is to hand over the file first. Second-order number: the information you are missing at that moment is worth 52 credits.

SupaVoxel, empty studio. The price is written into the button — Generate (3 credits) — and the balance reads 337. The reference slots take Main plus four extra angles; this case used one. Also visible: SupaVoxel's own two-step onboarding bubble sitting in the middle of the viewport. It is not a zero-popup product, only a two-step one.

Tripo, home. Balance 755, button reads "Generate" with no price. The quality selector offers Best Quality and Clean Topology, and Clean Topology is labelled Trial ×2 on the control itself. A personal-brand promo bubble floats top right, notification badge at 99+.

Tripo after upload: the button now reads Generate 55. This is the first and only place the price appears before you commit.

SupaVoxel after upload: the button text has not changed one character. Still Generate (3 credits). The price does not float with the input.

Clean topology is a trial on Tripo, and that matters here

Tripo's quality selector marks Clean Topology as Trial ×2 on the control. I left the run on Best Quality, the default, because the point is to measure what a normal user gets.

That matters downstream. The Tripo mesh I received has inconsistent winding — the normals have to be flipped before it slices — and the route to avoiding that is the trial-limited switch. The repair step is not a bad roll; it is the standard behaviour of the default tier, and the fix has a counter on it.

Two more switches sit in Tripo's Members Only column and only become visible on the generation screen: Generate in Parts (Trial ×1) and 8K Texture (Trial ×1), both off. So three of the switches that could change the result are metered, and you learn what you did not buy after the 55 credits are gone. Separately, the completion screen advertises Free Retry (×3) — a retry allowance, not a quality switch, and I am not counting it among the three.

Tripo, verification frame — near pixel-identical to the previous shot, thumbnail present, button still Generate 55. I took it because Tripo's upload has a history of failing silently and the only tell is that number on the button.

Tripo charges on submit: 755 → 700 while the card says Generating

The generation screen settles the billing question. Tripo's balance has already dropped from 755 to 700 — the full 55 — while the result card still reads "Generating... 107s". Abandon there and you have paid.

SupaVoxel does the same thing: its balance goes 337 → 334 at submit, exactly 3. The difference is not the policy, it is the size of the bet. Second-order number: three abandoned Tripo runs cost 165 credits, which is 55 SupaVoxel generations.

Tripo mid-run. Balance already 700. Three things are competing with the model for the viewport: a Humanoid Rigging & Text2Motion promo bar across the top, a View Your Model tutorial panel covering the right half, and the Members Only column with two trial switches that were never offered before payment.

SupaVoxel mid-run. One progress bar at 3% and the line "Estimated 5-10 minutes". No promo bar, no tutorial panel over the model.

Wall clock: SupaVoxel is usually quicker, Tripo is never slow

On this arm Tripo took 175.0 s and SupaVoxel 139.6 s. Tripo shows no completion timestamp, so I bracketed its run with a check on the result card every 30 seconds; SupaVoxel's own timer gave me the 139.6 s directly.

The ten-subject picture needs two sentences, and quoting either one alone would mislead you. SupaVoxel was the quicker of the two on 7 of the 10 subjects, with a median of 133.6 s against Tripo's 163.5 s — roughly 30 s a run. And Tripo was far more predictable: every Tripo run landed between 135 s and 189 s, a 54 s spread, against SupaVoxel's 100.2–867.4 s, a spread of 767 s.

The tail is where that matters. SupaVoxel's slowest three were the tank at 867 s, the reindeer at 258 s and the watch stand at 250 s; Tripo has nothing in that territory because Tripo has no territory — it spends the same time on everything, the same way it spends the same triangle budget on everything. So: if you are generating one model and watching the tab, SupaVoxel usually hands it back sooner. If you are queueing a batch against a deadline, Tripo's 54 s window is the thing you can plan around and SupaVoxel's is not.

Ten subjects with one run each per tool is a sample, not a statistic. I have no visibility into either company's overall numbers and I am not going to pretend my twenty runs are a distribution. Take the ranges as what one person saw in one week.

What that predictability costs: 52 extra credits per model, 18.33×, and the model that arrives still needs its winding flipped.

SupaVoxel's Advanced Options at product defaults: Inference Steps 5, Guidance Scale 5.5, Remove Background on. I opened the panel, changed nothing, and ran it as shipped — every parameter I quote is the default reading off this screen.

Both panels told the truth about what they made

Tripo's completion screen reports Triangle 1954511 / Vertices 1020577, and my offline parse of the downloaded GLB gives exactly that. Tripo did not inflate its own numbers, and that deserves saying. SupaVoxel's panel reports Triangles 997,355 against a parsed 997,355 and Size 0.61 / 1 / 0.76 against a raw bounding box of 0.6088 / 1.0 / 0.7610. Both panels are honest; only one of them costs 55 credits.

Tripo, finished. The readout matches my parse exactly. The View Your Model panel has not moved, so the arm is half covered, and the bottom bar advertises Free Retry (×3) — even the retries are metered.

What the 52 extra credits did not buy

Tripo's premium did not buy bulk, did not buy less support, and bought a triangle edge 1.43× finer that a 0.4 mm nozzle cannot lay down (Tripo 0.58× of the nozzle, SupaVoxel 0.83×). That fineness is real on SLA and worth nothing on FDM.

Volume at 120 mm — Tripo 250.53 cm³ · SupaVoxel 232.74 cm³
Resin at $35/L — Tripo $8.77 · SupaVoxel $8.15 · $0.62 apart
Support area — Tripo 6,761.4 mm² · SupaVoxel 4,858.5 mm² · Tripo +39.2%
Mean edge — Tripo 0.2326 mm · SupaVoxel 0.3335 mm · Tripo 1.43× finer, unusable at 0.4 mm

Tripo spends the same triangle budget whatever you show it

Across ten subjects generated on the same day with the same settings, Tripo's triangle count ran from 1,896,372 to 1,996,779 — a spread of 5.2%. A candle holder, a watch stand, a tank, this arm: the same number every time. Over the same ten subjects, same day, same settings, SupaVoxel ran from 945,492 to 2,786,054, a spread of 146%; this arm came out at 997,355, and on the tank SupaVoxel shipped 44% more triangles than Tripo in a file 4.1× smaller.

So the accurate claim is not that SupaVoxel is leaner. It is that Tripo's spend does not respond to the subject — a fixed house budget — while SupaVoxel's tracks what you asked for. Ten subjects, same day, same settings is a small sample, and I will say so every time I use it.

The SupaVoxel project list. Every card carries "3 credits · 9/26/2026" — ten test subjects, ten cards, cost auditable one row at a time.

A batch of 100: 5,500 credits against 300

Small workshops do not make one arm. Here is the same job at 100 units, with every assumption stated.

Credits — Tripo 5,500 · SupaVoxel 300 · 5,200 apart
Download volume — Tripo 6.29 GB · SupaVoxel 0.56 GB · 5.73 GB saved
Resin at $35/L — Tripo $877.00 · SupaVoxel $815.00 · $62 saved
Support area to cut — Tripo 676,140 mm² · SupaVoxel 485,850 mm² · 190,290 mm² less
Serial wall clock, from my own ranges — Tripo 3.8–5.2 h · SupaVoxel 2.8–24.1 h · the ranges overlap, so nobody gets to claim this row at 100 units
Post-processing — Tripo: flip winding on 100 files · SupaVoxel: merge shells on 100 files · neither side gets to skip it

Read that wall-clock line carefully, because it is the one place my sample genuinely cannot decide the question. Tripo's best case is slower than SupaVoxel's best case and its worst case is far better — 5.2 hours against a possible 24. If you need a hundred models by a deadline and the credits are somebody else's problem, Tripo's predictability is worth buying. If the credits are your problem, 5,200 of them buy a great deal of patience.

Where the credits actually go: bytes you cannot print

Tripo ships three 4096² textures totalling 6,773,618 bytes, of which 4,154,207 — 61.3% — are metallicRoughness and normal maps a slicer never reads. The normal map alone is 2,676,872 bytes, 4.56× the entire SupaVoxel three-texture set at 586,638 bytes. Nothing in Tripo's export dialog says so: Texture Resolution sits pre-set to 4k (Current), the two dropdowns hold nothing else, and 62.89 MB lands on your disk.

Texture bytes total — Tripo 6,773,618 B (3 × 4096² JPEG/PNG) · SupaVoxel 586,638 B (3 × 2048² WebP) · 11.55×
baseColor, the one a slicer might use — Tripo 2,619,411 B · SupaVoxel 345,278 B · 7.59×
Maps a printer never reads — Tripo 4,154,207 B · SupaVoxel 241,360 B · 17.21×
GLB on disk — Tripo 62,888,224 B · SupaVoxel 5,627,132 B · 11.18×

The one place SupaVoxel's 3 credits underdeliver

Fair is fair. SupaVoxel's Wire inspection mode is useless at this face count: 997,355 triangles of wireframe render as a near-solid white mass with no readable topology. It should down-sample or warn above a threshold and does neither. It costs nothing here because X-Ray answered the only question that mattered — whether the windows were real openings — in one click. But it is a mode the product ships that does not do its job at the density the product ships.

SupaVoxel's Wire mode on a 997,355-triangle model: a white blob. Recorded as found. The useful inspection modes on this subject were X-Ray and Mesh.

Final verdict: Tripo scores 58/100 on cost

Tripo passed every geometry test on this subject, and Tripo held the tighter timing window — though not the faster one, which was SupaVoxel's on 7 of my 10 subjects. Tripo also asked 55 credits against 3 for a result that ties, withheld the price until after upload, charged the full amount at submit, metered the topology cleanup that would have removed the repair step, and delivered 4,154,207 bytes of texture that never reach a print.

SupaVoxel scores 90/100 on this axis: 3 credits, price visible before upload, five export formats, a batch of 100 for 300 credits and 0.56 GB, and the quicker run on 7 of 10 subjects — against a timing spread of 767 s that you cannot plan a batch around, and an inspection mode that does not scale.

On a clean hard-surface subject like this one, the two products converge on quality. Which is exactly why the price is the decision.

Which one I would use for this job

Same photograph, 3 credits instead of 55, price on the button before you upload, 5.63 MB out the door, a hundred of them for 300 credits — supavoxel.com. Run your own reference through it and check the balance before and after; that is the only measurement in this article you need to reproduce.

Tripo 3D Mesh Review 2026: Watertight, and Every Normal Faces Inward

Tariq Hassan — Thu, 15 Oct 2026 15:43:51 +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 62/100, SupaVoxel 88/100

I ran one photograph of a ball-jointed toy skeleton through Tripo and through SupaVoxel, both on stock product defaults, and then tore both GLBs apart offline at a 120 mm target height. This is not a sweep. Tripo wins the topology row outright and Tripo wins the invented back. It loses everything that touches the invoice, and it hands you a mesh whose faces all point the wrong way.

Watertight after welding — Tripo yes · SupaVoxel no · Tripo's row, no argument
Boundary edges (holes) — Tripo 0 · SupaVoxel 0 · tie, neither file has a hole to patch
Non-manifold edges — Tripo 0 · SupaVoxel 375 · Tripo wins, and 375 is the worst number SupaVoxel posted in this case
Face winding consistent — Tripo no · SupaVoxel yes · SupaVoxel wins, a slicer reads Tripo's file as a non-solid
Connected shells — Tripo 2 · SupaVoxel 251 · Tripo wins, Euler characteristic −12 against SupaVoxel's 222
Sliver faces — Tripo 16 · SupaVoxel 26 · Tripo wins by 10 triangles a slicer will fight
Support area at 45° — Tripo 3,573 mm² (13.52%) · SupaVoxel 3,940 mm² (14.88%) · Tripo wins by 366.7 mm²
Resin at 120 mm — Tripo 121.89 cm³ / $4.27 · SupaVoxel 121.28 cm³ / $4.24 · three cents apart

Four things a print shop should know before it pays Tripo 55 credits for this file:

Tripo's mesh is closed and manifold, and it is still not slice-ready — the winding is inconsistent, so the slicer calls it a non-solid and you flip every normal by hand before anything else happens.
Tripo shipped this file with Clean Topology switched off, because that is the default and because it is rationed at Trial ×2. The winding defect sits exactly where that switch would have been.
Tripo's 1,961,102 triangles average 0.1922 mm per edge, already 2.1× finer than a 0.4 mm FDM nozzle. SupaVoxel's 978,322 triangles average 0.2772 mm and are still 1.4× finer than the nozzle. Neither file can be printed at the density it was generated at.
On the back of the skull and pelvis — the part the input photo never showed — Tripo invented something more bone-like than SupaVoxel did. That is a real loss for SupaVoxel on this case's own stress axis, and I am not going to bury it.

For a printable 120 mm articulated skeleton, I would take the SupaVoxel file: both meshes enter a repair tool exactly once, both print to the same 121 cm³ of resin, and one of them costs 3 credits instead of 55.

The input: one photo, no back, 120 mm target

The single file both tools received: 1,373,847 B, sha256 197445ba…, grey studio backdrop, front view only. The spine, scapulae and rear pelvis are not in this photo at all.

Same file, same product defaults, same offline render rig, same camera positions. Tripo exports at yaw 0 and SupaVoxel at yaw 90, so every paired render below applies that offset — neither tool got to pick a flattering angle.

Both meshes kept the ball joints separate

SupaVoxel at 978,322 triangles: elbows, wrists, knees and ankles are discrete bulges, the rib arches are individually separated, the pelvic aperture is open.

The headline risk for an articulated toy is fusion — limbs welded into one column. Neither Tripo nor SupaVoxel fused anything. Tripo passed this at 1,961,102 triangles; SupaVoxel passed it at exactly half that, 978,322. The joint test costs 55 credits on one side and 3 on the other.

Tripo's extra triangles land on the face and the hands

Tripo, same camera: individually countable teeth, a hard cheekbone transition, a defined sternal ridge, three distinguishable finger segments.

This is what Tripo's 982,780 extra triangles bought, and it is worth naming precisely: facial and hand micro-features. Not joints, not proportion, not structure. At the 120 mm target those features sit at 0.1922 mm — below what a 0.4 mm nozzle resolves. Tripo charges 18.3× the credits for detail the printer erases.

Tripo's mesh is genuinely closed

Tripo's untextured geometry. After welding by position: watertight = yes, boundary edges = 0, non-manifold edges = 0, connected components = 2.

Credit where it is due. Tripo hands over a two-shell, hole-free, manifold body. If your downstream is an automated slicer or a CAD boolean that refuses hand-repaired meshes, Tripo wins this row and nothing else in this article changes that.

And then every face points the wrong way

Tripo's studio row before submit: Best Quality selected, Clean Topology carrying a Trial ×2 badge and switched off. This is the state 55 credits bought.

Tripo's welded winding is inconsistent — some faces are inside-out. A slicer reads that as a non-solid and stops. So the closed manifold shell you just paid for still goes into a repair tool for a global normal flip. Tripo's topological perfection is worth exactly zero steps saved.

SupaVoxel's mesh: winding consistent, 375 non-manifold edges

SupaVoxel untextured: consistent winding, 0 boundary edges, 0 degenerate faces — and 375 non-manifold edges across 251 connected shells.

The SupaVoxel file is not watertight and Tripo's is. 375 non-manifold edges is the ugliest number I recorded in this case, and it means a mesh-repair pass before slicing. The Tripo file needs a normal flip; the SupaVoxel file needs a manifold repair. One tool visit each. The step count is 1:1. The 52-credit difference does not buy you "no repair" — it buys you "a different repair".

Euler characteristic 222 against −12

SupaVoxel's in-product inspection panel reads Triangles 978,322 — identical to what I parsed out of the GLB offline. Five view modes: Textured / Mesh / Wire / Normals / X-Ray.

251 shells against Tripo's 2, Euler 222 against Tripo's −12. Those 251 components are mostly small and most repair tools sweep them, but Tripo's 2-shell result is the cleaner starting point and I will not pretend otherwise. What it costs to get there: 55 credits versus 3, an 18.3× multiple, for a file you then re-orient anyway.

Sliver faces: Tripo 16, SupaVoxel 26

Tripo from the side: distinct temporal hollow, humerus / elbow ball / forearm reading as three separate contours.

Degenerate faces: zero on both sides. Sliver faces: Tripo 16, SupaVoxel 26. Slivers produce jagged boundaries and stray thin walls, so 26 is 10 more places a slicer can misbehave. Tripo's triangle hygiene is better here. The trade: those 10 triangles cost 52 extra credits and 56.5 MB of extra download.

Supports: SupaVoxel needs 366.7 mm² more

SupaVoxel from the side: softer jaw-to-ribcage transition, forearm contour merging into the torso near the chest, clean toe segments.

At a 45° threshold Tripo needs 3,573.2 mm² of support (13.52% of area) and SupaVoxel needs 3,939.9 mm² (14.88%). That is 366.7 mm² more, +10.3%. In resin at $35/L it is under five cents; in labour it is a slightly longer support-removal session. Tripo takes this row.

Mean edge length versus a 0.4 mm nozzle

Tripo's wireframe at 1000×750. 1,961,102 triangles render as a solid black field — the mesh density is not humanly resolvable at this zoom.

Tripo averages 0.1922 mm per triangle edge, SupaVoxel averages 0.2772 mm, and an FDM nozzle is 0.4 mm. Tripo is 2.1× finer than the nozzle, SupaVoxel 1.4× finer. Both are past the machine's limit, which makes Tripo's triangle advantage unprintable by definition. The second-order number: 982,780 triangles priced at 52 extra credits, worth 0.000 mm of printed difference.

Volume and resin: three cents apart

SupaVoxel from above. The transverse ripples on the cranium are the FDM layer lines from the input photograph, faithfully rebuilt as geometry by both tools.

Scaled to 120 mm, Tripo's solid measures 121.89 cm³ and SupaVoxel's 121.28 cm³. At $35/L that is $4.27 against $4.24. Tripo's 2.00× triangle count buys three cents of resin. Bounding boxes: Tripo 61.84 × 120.0 × 58.31 mm, SupaVoxel 59.13 × 120.0 × 62.19 mm — same object, same shelf.

The back neither tool could see — and Tripo did it better

Tripo's invented back, zoomed: a soft butterfly contour reading as scapulae, a graded central groove, a short vertical column above the pelvis reading as lumbar vertebrae.

There is no spine in either model. Both tools invented this surface, because the input photo has no back. But Tripo's invention is anatomically more convincing than SupaVoxel's, and on a skeleton — where bone structure is the subject — that matters more than it would on a vase. On this case's own stress axis, Tripo wins. There is no trade ratio that makes that go away; the honest framing is that it costs 52 extra credits and a normal flip to buy a better guess at a surface that was never photographed.

SupaVoxel's back is a hard-edged plate with a rectangular window

SupaVoxel's invented back: two hard-edged, filleted industrial plates, an H-shaped seam, and a rectangular recess on the pelvis with no anatomical counterpart at all.

That rectangular window is pure geometry, not biology. The limb joints survive the zoom intact — elbow ball and forearm stay separate — but the back panel is the weakest surface SupaVoxel produced in this case.

Getting the file out: Tripo's six formats, 2 steps

Tripo's export panel: File Name, a Format dropdown offering USD / FBX / OBJ / STL / GLB / 3MF, Texture Resolution 4k Current.

Six formats against the single GLB I took out of SupaVoxel, and Tripo reaches a file on disk in two clicks from the result view. That is a real Tripo advantage and it is on the board. I never expanded SupaVoxel's export dropdown in this run, so its format list and click count read "not captured" rather than a guessed number. One Tripo footnote: the download runs through a client-side blob URL that is revoked on click, so a second copy means walking the export panel again.

Final verdict: Tripo scores 62/100, SupaVoxel 88/100

Tripo earns its 62 on real ground: a closed manifold shell with 0 boundary edges and 0 non-manifold edges, 16 slivers against SupaVoxel's 26, 366.7 mm² less support area, and a back-surface invention that reads more like bone. Anyone who downloads both GLBs can confirm all five.

Tripo loses 38 points on the things that decide whether the file is usable: inconsistent winding that a slicer reads as a non-solid, Clean Topology defaulted off and rationed at Trial ×2, 0.1922 mm triangles a 0.4 mm nozzle cannot print, and 55 credits against 3 for a part that comes out of the printer at 121.89 cm³ instead of 121.28 cm³. Both files need one trip through a repair tool. Only one of them costs 18.3× to obtain.

Caveat, stated plainly: one generation per tool, product defaults, sample size 1. Every number here parses out of the two downloadable GLBs.

Which one I would use for this job

For a 120 mm articulated skeleton headed to a printer, the 3-credit path is the one I would repeat: consistent winding, 0 boundary edges, 0 degenerate faces, 5.54 MB, an in-product panel whose triangle count matches the GLB exactly, and the same 121 cm³ of resin at the end. Budget one mesh-repair pass for those 375 non-manifold edges — the other path budgets one normal flip, and charges 52 more credits for the privilege. Start at supavoxel.com.

Meshy AI 3D Review 2026: The Chair Seat Splits Into Triangles

Tariq Hassan — Tue, 13 Oct 2026 15:44:42 +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.

The whole point of a director's chair is the canvas.

Take away the red seat and the red back and you've got two sticks in an X. The fabric is what makes it read as a film-set prop instead of a folding stool.

So when I needed one in 3D — one illustration, no time to model it by hand — the canvas was the thing I was going to judge it on.

I asked around for an image-to-3D tool and got the same two answers over and over: Meshy and SupaVoxel. Nobody would choose for me, so I ran the same picture through Meshy and through SupaVoxel, then zoomed in on the seat.

My verdict in 60 seconds — Meshy 60/100, SupaVoxel 90/100. My subjective scores for this one job. The numbers under them are not subjective.

The seat fabric at 2× — Meshy's pleats break into visible triangles vs SupaVoxel's continuous run with fine speckling · Meshy 5/10 · SupaVoxel 9/10 — Meshy turns canvas into origami the moment you get close; SupaVoxel keeps the fold reading as cloth, specks and all.
The crossbar and pivot at 2× — Meshy coarse vs SupaVoxel finer · Meshy 6/10 · SupaVoxel 8/10 — Meshy softens the joint that sells the folding mechanism; SupaVoxel holds enough of it that the prop still reads as a folding chair.
Triangles to hold a crease — Meshy 254,336 vs SupaVoxel 1,500,000 · Meshy 6/10 · SupaVoxel 9/10 — triangles are the flat plates a shape is built from, and Meshy hasn't got enough for a curve; SupaVoxel has the plates the fabric needs.
Corners to pin detail to — Meshy 146,472 vs SupaVoxel 854,468 · Meshy 6/10 · SupaVoxel 9/10 — Meshy runs out of corners right where the seat creases; SupaVoxel still has pins to land a fold on.
File you download for that look — Meshy 15.26 MB vs SupaVoxel 10.25 MB · Meshy 6/10 · SupaVoxel 9/10 — Meshy charges more download for the worse-looking fabric; SupaVoxel's better surface arrived in the smaller file.
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 hands you one file and that's your lot; SupaVoxel gives you a light build for the page and a plain build for a fussy importer off the same generation.
Textures baked in — Meshy 3 vs SupaVoxel 3 · Meshy 7/10 · SupaVoxel 7/10 — a straight tie: identical count out of both files, which is exactly why Meshy's faceting can't be blamed on the paint.
The back of the chair — Meshy invented it vs SupaVoxel invented it · Meshy 6/10 · SupaVoxel 6/10 — tie by necessity: the source picture never showed the back, so there's no right answer to score either side against.

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

The illustration Meshy and the other tool both received. Generated for this project with GPT Image 2. No text prompt went into either 3D tool.

The smaller file is the one that got the fabric right

I'll give away the ending.

The 10.25 MB file has better canvas than Meshy's 15.26 MB file. Not marginally — visibly, at the first zoom I tried.

That's backwards from how this usually goes, and the reason is sitting in the triangle counts. Meshy had 254,336 triangles and 146,472 corners to spread across an entire chair. The other file had 1,500,000 and 854,468.

Straight sticks are cheap to describe. Sagging fabric is expensive. A curve needs edges to sit on. Run out and the curve becomes a set of flat plates — which is exactly what Meshy is about to show you.

Meshy's chair, head-on. Red seat, red back, both connector boards, X-frame. At this distance it's fine. Honestly, it's fine.

The SupaVoxel chair from exactly the same camera as the Meshy shot above. Also fine. If you stopped here you'd call it a draw — and most comparisons do stop here. That's the tool I kept, by the way: supavoxel.com.

Zoom in 2× and Meshy's canvas turns into origami

Same front render on both sides. Same crop box, same magnification. Nothing cherry-picked — I pulled the identical rectangle out of Meshy's render and the other one.

The box covers the seat panel where it creases and the bracket at each end.

Meshy's seat at 2×. Look at the pleats. They're not curving — they're breaking into triangles, and the fabric starts reading as a hard folded surface instead of cloth.

The SupaVoxel crop from the same box and magnification as Meshy's. The fabric run is continuous. It does carry fine specks, and I'm not going to pretend it doesn't.

Here's what that costs you in practice.

If the chair is set dressing thirty feet behind your actor, nothing. Nobody sees it. But the second the camera pushes in — or someone rotates it on a product page, or it lands in a hero shot — Meshy's faceted canvas is the kind of wrong that people notice without being able to say why. It reads as cheap.

And this applies to these two crops only. Nothing here says either chair would actually fold.

The crossbar is the bit that says "this thing folds"

Second crop, same discipline. Same front render, same box on both sides, 2× on both sides. This time it's the X-frame crossing and the pivot in the middle.

Meshy's crossbar and centre pivot. Only the visible structure is in play here — the faces the source picture never showed have no right answer on either side.

The SupaVoxel crossbar from the same crop as Meshy's. Finer — at a cost I get to further down.

Why does this matter more than it looks like it should? Because the pivot is the visual promise that the prop is a folding chair. Soften it and you've got a chair-shaped object. Detail at the joints is what sells the mechanism, even in a still.

Three textures each, so you can stop blaming the paint

The kindest reading of Meshy's faceted seat would be that Meshy spent its budget on texture instead of shape.

Meshy's file doesn't support that reading. Both have exactly 3 textures baked in. Same count, both sides.

So Meshy's 15,262,068 bytes aren't heavier because of extra image files. They're just heavier, and the surface underneath still ran short of edges.

Texture is makeup. Geometry is bone structure. You can't paint your way out of a flat curve.

The Meshy chair at three-quarters. Both files show the whole subject from this camera.

The SupaVoxel chair from the same angle as Meshy's. One thing to keep in mind on every pair in this article: each file has its own idea of which way is forward, so matching camera numbers doesn't guarantee a matching view. Don't read these as overlays.

What about the back nobody has a picture of?

The source illustration shows the chair from the front. That's it.

So whatever is on the back of Meshy's chair or the other one, both tools made it up.

Meshy's chair from behind. This surface was never in the input.

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

I'm not scoring this pair and neither should you. There's no right answer to compare against.

I'm still publishing it, though. A comparison that only shows the angles where Meshy struggles isn't evidence — it's editing. Both back views came off the same camera numbers as everything else here.

Meshy's back, close up. This is the camera that would expose patched holes or odd hardware if either tool generated any.

The SupaVoxel back close-up from the same camera and zoom as Meshy's.

What the better-looking file costs you to move around

Fidelity is worthless if nobody waits for it, so I weighed Meshy's file and the other one and did the division.

Meshy's chair is 15,262,068 bytes. The other one is 10,245,480. Both came out as GLB — the single-file 3D format that packs geometry and textures into one blob, which most web viewers and engines read with no conversion. Same format out of Meshy and out of the other tool, so this is like for like.

On a clean, steady 12 Mbps phone connection, Meshy's file is about 10.2 seconds of pure transfer against 6.8. On a 100 Mbps desktop line, Meshy is about 1.22 seconds against 0.82. Those are division, not stopwatch readings — the same assumption applied to Meshy and to the other file, with no handshake, decode or cache.

Here's the version that matters. Someone lands on your prop page on a train. Ten seconds of blank viewer is where people swipe away, and with Meshy you'd be spending those seconds on the file with the faceted seat. That's the worst trade in this whole test: paying more wait for less fabric.

Scale it to a project. A hundred props at Meshy's size is about 1.53 GB on your drive against 1.02 GB — half a gigabyte of set dressing you get back for free. On the credit side, a hundred runs works out to 3,500 Meshy credits against 300 SupaVoxel credits. Meshy credits and SupaVoxel credits are two different plans in two different units, so that is not a price ratio and I'm not turning it into one. All of those are straight multiplication of this one Meshy run and the one beside it, assuming nothing fails.

What happens when the pretty file won't open

One scenario beats every render on this page, so it gets its own section.

Every GLB declares the extensions it requires — features a reader must support or it refuses the file. Meshy's list is empty. The compressed SupaVoxel file requires EXT_meshopt_compression and KHR_mesh_quantization. Meshopt compresses the geometry; quantization stores coordinates in smaller number formats. Both need a decoder at the other end.

So if your importer is old, or locked down, or belongs to a client: Meshy's single file at least tries.

And that is exactly why SupaVoxel ships two exports. The same menu also gives you an original-size GLB — no meshopt, no decoder, nothing to install. The compressed build goes on the page where every megabyte counts; the original-size build goes to the importer that won't budge. One generation, two deliverables, no converter to hunt down. A continuous seat fabric is worth nothing in a viewer that can't load it, which is the whole argument for having both files in hand.

Meshy's flags and the SupaVoxel file's are measured; the import outcome is inference — I loaded neither into a real importer and didn't measure what converting would cost.

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

Failure counts: not captured. Retry counts: not captured. For Meshy and for the other side alike. I didn't record them this run, so I don't have them.

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

That matters more than it sounds. If Meshy's faceted seat was a bad roll and a retry would have fixed it, one run would never tell me — and the same is true in reverse for the fine specks on the other side. Generated output is random. One image proves one image.

So which one do you pick for a prop like this?

It has to survive a close shot on fabric — the SupaVoxel file, on these crops. 1,500,000 triangles and 854,468 corners against Meshy's 254,336 and 146,472.
It's background dressing and memory is tight — Meshy. About 7.7 MB of estimated geometry memory against 45.3, by arithmetic on an illustrative layout.
Your importer can't decode meshopt — Meshy's single file, or SupaVoxel's original-size export. Both decoder-free; only one also leaves you a light copy for the page.
Which one is cheaper — undecidable here. 35 credits on Meshy's plan, 3 on the other, two different units, not a price.
Whether the chair would actually fold or the arms detach — not answered by Meshy or by the other tool. A 2× crop is not a manufacturing test.

Where Meshy actually wins

I'd be selling you something if I stopped here. Meshy takes real points in this test, and if you're in any of these situations, Meshy is the better answer.

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 get there 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 the faceted fabric and 5 MB more download. If you'd rather never think about which export to grab, that's a fair price. I didn't test either file in a real importer, so treat that as what the files declare.

Meshy's model is far lighter once loaded. Estimated from the vertex and triangle counts, Meshy's geometry needs around 7.7 MB of memory against around 45.3 MB.

The exchange rate: roughly six times less memory pressure, paid for with canvas that runs out of edges. For a chair in the deep background, Meshy's is the smarter file and I'd use it. For anything the camera gets near, no.

And Meshy was faster — 245.8 seconds against 274.9, about 29 seconds sooner. One run each, each tool timing its own clock.

What I won't claim from these pictures

Not that Meshy is worse in general. One image, one run, one prop.
Not that Meshy's chair or the other one would fold. Nothing here was tested for mechanism, thickness or assembly.
Not that either file is production-ready. Rigging, target engine and physical validation were all outside this test.
Not anything about cost. One job ticket said 35 credits, the other said 3 — two different plans, two different units, not a price comparison. No multiple, no dollar figure, no "cheaper" in either direction.

Final verdict: Meshy scores 60/100 for this job

At full frame, Meshy's director's chair holds up. The red panels read, the frame reads, the connectors read. If your prop lives at a distance, this is a perfectly good Meshy file and it opens anywhere.

Zoom 2× into the seat through the same crop box and Meshy's canvas breaks into triangular pleats — 254,336 triangles and 146,472 corners spread across the whole prop, in a 15,262,068-byte download that's bigger than the alternative.

60/100 is my call on this one chair from this one run. Generated output is random enough that a second run could land differently for either tool.

Go zoom into your own render before you decide

If your prop has to survive a close shot on fabric, supavoxel.com is where I'd start for a job like this.

But do the thing I did, whichever tool you use. Render your model from the front, crop the same rectangle out of it at 2×, and look at the surface that's supposed to be soft. Full-frame previews are designed to make everything look fine. Thirty seconds of zooming tells you more than any spec sheet.

How I tested this

One illustration of a director's chair, generated for this project with GPT Image 2, given 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.

Every render came out of the same offline viewer at the same resolution with the same fixed lighting, using identical camera numbers on both sides — front at yaw 0, three-quarters at yaw 35, side at 90, back at 180, plus a back close-up and a top view. Each file carries its own built-in orientation, so identical numbers don't guarantee an identical semantic angle, and none of these pairs is a pixel overlay.

Both detail crops were cut from the front render using the same normalised box on each side and resampled 2×. The seat crop covers the fabric crease and the brackets; the crossbar crop covers the X-frame crossing and the pivot.

Triangle counts, vertex counts, texture counts, file sizes and required extensions were read out of Meshy's downloaded GLB and the other one, after their hashes checked out. The geometry memory figures are arithmetic, not measurement: they assume 32 bytes per vertex and 4 bytes per index, exclude textures and mipmaps, and are not real VRAM.

Failure counts and retry counts were not captured in this test, and neither were any published claims from either tool. Those numbers aren't in this article because I don't have them.

Hyper3D 3D Print Review 2026: 1,293 mm\u00b2 of Potential Overhang

Tariq Hassan — Sun, 11 Oct 2026 15:46:59 +0000

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

I wanted a leaf-shaped cable clip that could sit on a wall, not merely a leaf that looked good in a thumbnail. The reference showed an open C-shaped holder and a screw hole. I sent that exact picture to Hyper3D and SupaVoxel, took home the files the tested accounts could actually download, and checked the geometry offline. Then I looked at the back—the part no photograph had supplied.

My verdict in 60 seconds — I would prototype the SupaVoxel leaf first, then inspect and repair its mesh before slicing. It offers a quieter-looking wall side, 27.79 cm³ less calculated solid volume and 421.1 mm² less potentially downward-facing area at a matched 120 mm longest outer dimension. Hyper3D Gen-1.5 is the cleaner original mesh: one welded shell, no degenerate faces and fewer slender triangles. Neither clip has touched a cable, fastener, wall or printer. If first-pass topology outranks wall-facing shape in your shop, choose Hyper3D instead; my choice is a starting file, not a validated fixture. See SupaVoxel for the candidate I would fit-test.

Eight side-by-side checks, Hyper3D then SupaVoxel:

Visible channel — both keep the C open; minimum opening and actual cable fit are unknown.
Visible mounting hole — both show a through-hole; no screw gauge or head clearance was measured.
Closed surface after UV welding — both are watertight with zero boundary and non-manifold edges; that does not certify strength.
Face-edge-connected shells — Hyper3D one versus SupaVoxel two; inspect the second shell before slicing.
Triangle hygiene — Hyper3D 0 degenerate / 1,368 slender faces versus SupaVoxel 157 / 8,887; Hyper3D wins this repair-risk row.
Wall-facing rear — Hyper3D invents strong veins; SupaVoxel is visually plainer, not proven flush.
Potential downward-facing area — Hyper3D 1,293.4 versus SupaVoxel 872.3 mm² at matched scale and Y-up; neither measures supports.
Calculated solid material — Hyper3D 85.33 versus SupaVoxel 57.54 cm³ under closed-solid, no-hollowing assumptions; smaller is preferable for my prototype.

Those last two rows make SupaVoxel my choice for this proposed wall fixture. They do not erase its worse face quality. One image, one downloadable textured file from each side, and no physical print: that is the size of the evidence.

What was the actual test image asking for?

The identical 1,811,538-byte input PNG: the leaf edge, clip mouth and mounting hole are already visible. The hidden rear and any dimensions are not.

I initially thought this would test whether image-to-3D could give a flat leaf some thickness. Look closely: the picture already gives that away. The harder test is whether the two files preserve an open route into the clip and make a plausible guess at the wall-facing side. Both services received identical PNG bytes, verified by the input hash. That does not establish identical preprocessing inside either service. I used Hyper3D's downloaded Gen-1.5 PBR file, not its prettier Gen-2.5 screen preview: Free-tier Download refused the latter. SupaVoxel's comparison is its actual Original size UI export. This distinction matters whenever a screenshot promises more detail than the file you can put into a slicer.

Can a cable even enter the C-shaped opening?

Hyper3D's exported mesh, seen from above: the clip mouth remains open, with a rough-looking interior patch whose geometry-versus-material cause was not isolated.

Matching overhead camera on SupaVoxel: another open passage, not a measured cable gauge.

A bridge across the mouth would have ended the trial immediately. Neither generator did that. But I cannot put a 4 mm, 6 mm or any other cable through a render. I did not section the inner channel, measure spring-arm thickness, or repeatedly flex a physical print. A dark gap is visual evidence of an opening, not proof of useful clearance or elastic recovery. For an organizer sold by cable diameter, that missing millimeter measurement is not a footnote; it is the next experiment. I would print one low-stakes sample, measure its mouth, and repeat the clip motion before ordering hardware or promising fit.

What happens to the screw hole and plate in profile?

Hyper3D side view: visible plate thickness and a protruding holder rather than a flat image plane.

Same side camera, SupaVoxel: the profile is visibly shallower, although this image cannot isolate the clip's interior dimensions.

After scaling each model until its longest bounding-box edge is 120 mm, Hyper3D occupies 120 × 104.94 × 30.61 mm and SupaVoxel 120 × 103.33 × 21.37 mm. The difference in whole-model depth is 9.24 mm. It might involve the leaf, the back or the holder. It is not a measured 9.24 mm difference in cable clearance. Likewise a through-hole visible in both front and side views is not a drill callout: neither hole diameter nor screw-head recess was extracted here. A shop would section the mounting plane and make a fit coupon. The file gives a starting form, not a standard fastener size.

Does “watertight” survive a real mesh audit?

The untextured Hyper3D mesh keeps major veins, the opening and the hole. It does not show whether every finer painted line is cut into the mesh.

A GLB can duplicate its vertices where UV islands meet. If I count those split positions as holes, I falsely fail both models. After welding coincident UV/normal seam vertices, both files are watertight, winding-consistent and show zero boundary edges and zero non-manifold edges. This is the strongest positive print-preparation result both earned. But Hyper3D has one face-edge-connected shell, and SupaVoxel has two. I do not know whether that second piece is an intentional detail or loose geometry. A slicer operator should identify and inspect both shells rather than infer their intent from the word “watertight.” Neither mesh was actually sliced or printed in this test.

Which file will fight me during a boolean edit?

Hyper3D wireframe: fewer faces and a legible local structure. The hygiene numbers below come from file analysis, not from counting dark lines in a picture.

Hyper3D's 120,000 triangles include zero degenerate faces and 1,368 slender ones by the report's fixed thresholds. SupaVoxel's 1,500,000 triangles include 157 degenerate and 8,887 slender faces: 7,519 more long-thin faces. This is an honest Hyper3D win. If I need to cut a screw recess or thicken an arm, dirty triangles may make that edit more fiddly. I cannot claim a failed boolean or print, because I ran neither. Nor should I call every one of SupaVoxel's extra faces valuable: triangle count is only inventory. The shape of the clip and its minimum material thickness are the relevant mechanical questions, still unanswered.

Does finer average sampling solve the fit problem?

SupaVoxel in clay: major leaf grooves and the through-hole remain without green texture. The second shell and slender-face tally require numerical inspection.

At that same 120 mm maximum outer dimension, Hyper3D's mean triangle edge is 0.8203 mm and SupaVoxel's 0.2358 mm. A nominal 0.4 mm FDM nozzle is a useful yardstick: the latter average is below it; the former is above it. This is not an accuracy certificate. A global mean does not tell me whether a given 2 mm screw lip exists, whether the spring arm is uniformly thick, or whether finer faces have encoded the right dimensions. SupaVoxel's denser mesh gives me more local shape to examine, but it also gives me many more suspect slender faces to clean. I would measure a cross-section at the clip before celebrating either number.

Which orientation seems to need more support?

The SupaVoxel oblique view keeps the cable opening. No supports are shown or measured in this rendered view.

I counted faces with normals pointing within 45° of straight down in world Y-up, then scaled both meshes by their longest bounding-box edge to 120 mm. Hyper3D's potentially downward-facing area is 1,293.4 mm² (4.31%); SupaVoxel's is 872.3 mm² (3.28%), a 421.1 mm² arithmetic difference. It is tempting to call that 421 mm² fewer supports. Don't. An underside face resting on the build plate can enter the count; changing orientation changes the answer; real supports are generated by a slicer. The lower potential area favors SupaVoxel under this one analytic orientation, but I need a matched slicer test before claiming any resin or sanding saving.

Did Hyper3D decorate the side the wall needs?

Hyper3D close-up of an invented back: conspicuous branching and diagonal grooves near a surface meant to face a wall.

SupaVoxel at the corresponding rear camera: comparatively plain. The photo supplied no rear truth, and neither model was checked against a flat wall.

This changed my pick. Hyper3D extended vein relief around the unseen reverse; SupaVoxel made a quieter guess. I prefer the latter as a wall-facing prototype not because I proved it flat or Hyper3D obstructive, but because it has less conspicuous invented relief to inspect. Both are guesses: no source photo shows the rear or screw-head clearance.

What might one solid-fill prototype consume?

Both welded outputs meet the closed-solid prerequisites used for volume arithmetic. At a 120 mm longest side, Hyper3D's mesh volume is 85.33 cm³ and SupaVoxel's 57.54 cm³. Suppose solid resin, $35 per liter, no cavity, supports, losses or hardware. Then the resin alone would be $2.99 versus $2.01, or about $0.98 less per SupaVoxel piece. A hundred exact copies would amplify the arithmetic gap to about $98, but no hundred-piece batch was run. This does not attribute the entire difference to rear veins; the bodies have different proportions and depths. Hollowing, orientation, failed prints and actual spring suitability can reverse the real shop bill. I would use this as a reason to test both shapes in the slicer, not as a customer-facing material quote.

Is the file I can actually take home the one I saw?

On the Hyper3D Free account, Download after Gen-2.5 confirmation produced a subscription gate. Its million-face screen is not the measured Gen-1.5 GLB.

The impressive Hyper3D Gen-2.5 preview reported 1,000,000 faces and Print-Ready in its UI. I couldn't download it as a free user, and did not test the label. To get a file I generated the same image again with Gen-1.5, confirmed geometry, generated and confirmed material, and exported. That file has 120,000 faces. SupaVoxel gave me the pictured full textured output via Export → GLB → Original size. Its export menu also offered STL, 3MF and Fix Mesh, but none was exercised. Hyper3D offers FBX where the pictured SupaVoxel menu does not; that matters if your downstream pipeline insists on FBX. File availability is part of print readiness—an unexportable preview cannot be sliced by this tester.

Final verdict: which leaf would I prototype?

My first-prototype choice reflects a specific preference: less invented wall-side relief, less calculated solid volume and lower potential downward-facing area in the tested outputs. Hyper3D's one shell, zero degenerate faces and 7,519 fewer slender faces are substantial wins, not trivia. SupaVoxel's two shells and 157 degenerate faces mean I would inspect and clean it before slicing. Neither visible C nor closed mesh proves fit, grip, fatigue life or installation safety. If your shop values cleaner first-pass topology above my wall-facing priorities, the Hyper3D Gen-1.5 file is the defensible pick.

Use SupaVoxel for the first fit prototype, not a promise

For this leaf design I would start in SupaVoxel, isolate its second shell, clean its suspect faces, section the clip, and then make a physical sample with the intended cable, fastener, printer and material. That is a recommendation for a starting file, not a declaration that the file can safely hold a cable. I would keep Hyper3D's cleaner Gen-1.5 mesh as the alternate if cleanup time dominates. No paid Hyper3D tier or physical trial was tested here.

How I checked—and what I did not

The same SHA-checked, AI-generated PNG was uploaded on both sides; it was made with a third-party product cover used as a visual reference, and this comparison does not establish publication rights to that original reference. Hyper3D Gen-1.5 and SupaVoxel exported distinct textured GLBs; the blocked Gen-2.5 preview contributes no file measurements. All render pairs used the same offline viewer and camera settings, with front orientation checked on these models. After UV seam welding, file analysis supplied triangles, connected shells, edge checks and solid volumes. 120 mm means the longest bounding-box edge, never a guaranteed leaf height, clip width or cavity dimension. Normal-based downward area, resin dollars and hypothetical hundred-piece totals are arithmetic under stated assumptions, not slicer/printing outcomes. I did not measure channel minimums, wall contact, spring fatigue, screw fit, print success or repair hours.

Hyper3D Rodin Planter Review 2026: A Base Matters More Than a Mesh

Tariq Hassan — Fri, 09 Oct 2026 15:44:04 +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.

The test brief was a blue crumpled-foil planter, not a symmetrical vase or merely a good front-facing render. I gave the same single image to Hyper3D and SupaVoxel, opened their actual textured downloads and looked inside from above before imagining soil or a printer. The most important finding is a hole you can see, even though a standard mesh check says both exports are topologically watertight.

My verdict in 60 seconds — for an as-delivered planter candidate, I would start with Hyper3D Gen-1.5’s visible inner floor, not SupaVoxel’s visibly through-open cavity. This is a shape decision, not a certification that either file contains water or soil. Hyper3D Gen-1.5 shows a blue inner floor. The actual SupaVoxel Original size GLB shows white scene background through the lower opening. SupaVoxel unquestionably produces more convincing irregular foil on the outside; for a visual study or prop that will be intentionally remodeled, I would start there. But topologically watertight does not mean “can hold soil,” and I would not send its as-delivered shape to a planter print queue. Neither model was sliced, printed, filled or leak-tested.

Here is my eight-line decision card for the as-delivered container starting point. Each measured or visible difference names the work it leaves to do; the floor is a gate, not a weighted point:

Visible inner floor — Hyper3D yes, SupaVoxel shows background through cavity — the decisive functional-shape difference.
Outer foil irregularity — Hyper3D broad near-mirrored folds, SupaVoxel varied crossings — SupaVoxel clearly wins the art brief.
Welded watertight topology — both yes — a real tie that cannot resolve the floor question.
Welded nonmanifold / boundary edges — 0 / 0 for both — clean edge counts do not create a base.
Degenerate faces — 0 vs 12 — Hyper3D has the tidier triangles here.
Sliver faces — 610 vs 8,408 — extra sampling does not guarantee cleaner topology.
Mean edge at 120 mm longest side — 1.1448 vs 0.3841 mm — SupaVoxel carries finer fold detail.
Physical leak, wall and slice test — neither performed — no one has earned “ready to plant.”

A vessel and a convincing foil surface are different commissions. A useful decision must name which of those jobs is being evaluated.

What did the single source actually show?

Both products received this identical 1,647,256-byte independently generated blue-container PNG; its dark cavity does not prove that the pictured object has a floor.

There is no plant, no second view and no unambiguous reference for the bottom. The single photograph asks for irregular crisscrossing crumples on an open-rimmed blue cylinder. It does not tell either generator how to build a watertight container in use. Both uploads matched the same input bytes, but the tools’ own descriptions and settings differed. I am comparing the delivered results, not claiming an isolated test of a hidden algorithm. My first check is what a gardener would do before reading a triangle count: look into the opening.

What happened when I looked down into SupaVoxel’s model?

The SupaVoxel Original size GLB has a ring wall; the white background is visible through its lower central passage.

The model pictured is the actual 58,065,236-byte browser Original size GLB, not a smaller CDN copy. White viewer background is visible through its central passage. That is not an open-mesh-boundary claim: a closed-surface tube can be topologically watertight while soil falls through its middle. A usable pot needs an added, joined inner base, a floor-thickness check, slicing and a physical test. None happened here; the repair labor and revised material quantity are unmeasured.

Did Hyper3D put a floor in the same place?

The Hyper3D Gen-1.5 PBR member shows a blue interior floor instead of white background at the matched overhead angle.

Yes. That apparent bottom makes Hyper3D a better container candidate despite less chaotic exterior folds. A blue floor in a render is not proof of thickness, strength, drainage or leak resistance; neither file was printed or filled. At a common 120 mm longest bounding-box side, their boxes are 92.61 × 120 × 92.8 mm and 91.3 × 120 × 92.26 mm. Those figures do not establish usable interior capacity. But Hyper3D passes the first visible floor check.

Why did the watertight check say “yes” to both?

Hyper3D’s lower-density wireframe belongs to the actual 120,000-triangle Gen-1.5 PBR export, not a blocked million-face preview.

SupaVoxel’s dense wire cannot reveal whether the model’s central passage is a useful container cavity.

UV seams duplicate vertices: raw boundaries read 61,004 vs 104,794. Weld those seam duplicates and both files become one face-connected, consistently wound, watertight shell with zero boundary/nonmanifold edges. Yet a doughnut is a closed surface too. A manifold tube’s central passage is not a bowl bottom. The paired top images show Hyper3D’s visible floor and SupaVoxel’s through-opening. “Watertight mesh” cannot be stretched into “holds water.”

Does SupaVoxel at least make the folds in the brief?

Without blue PBR paint, SupaVoxel still has crossing ridges and recesses of varied size; its crumpling is geometric.

Absolutely. Without materials, SupaVoxel’s differently sized diagonal facets still cross; Hyper3D’s gather around a mask-like center spine. That is what the images show, not a claim that extra faces cause accuracy. The files have 1,500,000 vs 120,000 triangles. At the 120 mm longest-side scale, average edge lengths are 0.3841 vs 1.1448 mm — about 2.98× finer sampling. A 0.4 mm FDM nozzle is context, not proof those folds survive printing.

What did Hyper3D do to the silhouette?

Hyper3D’s textured front shows its central near-mirrored ridge even before the clay check.

SupaVoxel’s textured front retains less predictable crossed ridges; both image pairs use the tested exported files.

The Hyper3D clay shape has a rim and real facets, but its central ridge and paired hollows feel closer to a mask than accidental foil.

Hyper3D is not a blank cylinder: it has angular ridges. But front and rear organize them around a near-bilateral axis rather than the reference’s unruly crossings. A digital prop artist gets better foil from SupaVoxel. A maker needing a container instead gets a floor-design and joining task with SupaVoxel, of unmeasured duration. Hyper3D may need aesthetic sculpting; it already shows the inner bottom.

Which mesh has more actual cleanup noise?

At the same seam-welded analysis settings, Hyper3D has 0 degenerate faces and 610 sliver faces. SupaVoxel has 12 degenerate and 8,408 sliver faces. Both have zero welded nonmanifold edges. This is a real rival win in triangle hygiene, not a hidden footnote. SupaVoxel’s sliver count is about 13.8 times Hyper3D’s, even though its overall triangle count is 12.5 times higher. A sliver count by itself does not tell me whether a slicer rejects the object or whether cleaning every sliver is required; no such test was run. It does tell me not to sell “1.5 million faces” as unqualified print quality. For a digital close-up I can trade some cleanup headroom for folds I want. For an automated manufacturing pipeline, I would inspect the 8,408 first and keep the need for a new interior floor on the job ticket.

Can potential overhang area decide the print bill?

Hyper3D’s lower exterior folds make a different side profile; the support calculation is an orientation screen, not a slicer output.

SupaVoxel retains angular exterior relief from the side, but no printer-generated support structure was measured.

I normalized each file so its longest bbox side is 120 mm, assumed world Y is up and counted faces whose normals point within 45° of downward −Y. That flags 5,524.6 mm², or 8.9602%, on Hyper3D and 1,703.2 mm², or 2.4824%, on SupaVoxel. The difference is 3,821.4 mm² of potentially downward-facing surface under that orientation, not “3,821.4 mm² fewer required supports.” A face resting on the bed may be counted, and rotating the print or adding SupaVoxel’s missing visible floor changes the result. Without a slicer, resin supports, machine, build orientation and a completed usable geometry, I cannot convert this screen into printing minutes or support dollars. It points to what I would inspect next, not which model I would quote to a client.

What does the solid-fill resin estimate actually price?

For the current topologically closed shapes at the same longest-side 120 mm scale, mathematical enclosed volumes are 487.23 cm³ Hyper3D and 193.89 cm³ SupaVoxel. A completely solid pour at the illustrative $35 per liter gives $17.05 vs $6.79. That $10.26 gap is not a saving on two equal, usable planters. SupaVoxel’s modeled passage lacks the observed floor and would need new geometry; Hyper3D’s apparent bottom still requires thickness and physical validation. Hollowing, drainage, supports, waste and shrinkage are excluded. A structurally valid signed volume answers how much these exported closed surfaces enclose, not how much resin a sensible planter will consume after redesign. The exchange rate for SupaVoxel’s excellent crumples includes an unknown base-design and verification cost; I will not erase that with a neat but inapplicable $6.79 number.

Is the attractive million-face Hyper3D preview part of this comparison?

Hyper3D Gen-2.5’s separate million-face preview cost an isolated 0.5 credit, then explicitly required a subscription for GLB download on the tested Free account.

No. Hyper3D’s accessible analyzed mesh is Gen-1.5, 120,000 triangles, extracted as a PBR GLB from its successful ZIP. A separate Gen-2.5 preview claimed one million faces and “Print-Ready” inside the interface but supplied no downloadable file to this Free account after the 0.5-credit debit. I will not transfer that preview’s claimed quality or badge onto the Gen-1.5 model. Hyper3D’s second, Gen-1.5 run incurred another isolated 0.5 credit at geometry Confirm; independently checked Material Generate and Confirm cost zero more in this case. Those credits are not comparable to SupaVoxel’s independently matched three-credit transaction: different ledgers, no dollar exchange rate. For a shop, the only candidate I can inspect is the file actually delivered.

How much file did each export really transfer?

SupaVoxel’s actual browser Export → GLB → Original size produced the 58,065,236-byte file analyzed here, not the separate 8,499,144-byte CDN resource.

Hyper3D’s webpage transferred a 21,471,080-byte ZIP containing a 14,038,528-byte PBR GLB and a Shaded variant. SupaVoxel’s tested UI selection transferred 58,065,236 bytes as one Original size GLB. The SupaVoxel same-task compressed CDN file is 8,499,144 bytes but was not a measured click on its Compressed menu; a separate 44,556,092-byte local analysis derivative was not a browser export either. At hypothetical ideal 12 Mbps, the actual UI payloads need 14.31 vs 38.71 seconds of pure transfer. A smaller Hyper3D file is a genuine win. For a digital foil close-up I may accept the larger SupaVoxel file for better exterior creases; for a planter the more pressing cost is designing the missing visible floor. File size and function must not be smuggled into the same metric.

Final verdict: which starting shape fits each brief?

For an apparently bottomed planter candidate, Hyper3D Gen-1.5. It shows the blue inner floor and has a clean welded shell in this particular pair. I would still test wall and floor thickness, slice, print and check whether a real object handles soil or water; none of that has happened. For an irregular foil art object destined for digital display or deliberate redesign, SupaVoxel: its asymmetrical crossings make the exterior more compelling even without texture. Its welded watertight flag is not permission to claim container usability. That is the genuine rival-win and exchange rate, not a “both have pros and cons” dodge.

Use SupaVoxel when the foil surface is the product

If your commission prizes jagged, unpredictable creases and you can budget a floor-design stage before any physical use, start with SupaVoxel. Rotate the result and inspect it from overhead before ordering prints. This case delivers a stronger irregular surface, not a soil-holding or water-holding vessel. If your brief requires a usable bottom from the first downloadable model, this paired run gives Hyper3D Gen-1.5 the more relevant initial shape.

How I tested it. The identical source PNG went into both products. I used Hyper3D’s legally downloaded Gen-1.5 PBR member and SupaVoxel’s genuine browser Original size GLB, rendered from repeatable front, rear, side and top viewpoints. File counts and seam-welded topology are measured; fold and floor observations are from matched rendered images, not a measured watertightness-of-vessel test. The 120 mm normalization scales the longest side, and resin, transfer and batch figures require their stated hypothetical assumptions. Neither print, slicer, minimum wall, water/soil retention, completed base repair nor reference-image publication rights were verified.

Also in this series
Hyper3D Rodin Cost Review 2026: 0.5 Credit, Then a Download Wall
Hyper3D Rodin 3D Review 2026: The Foil Folds Turn Into a Mask

Can Claude Generate Images? What Actually Works in 2026

Tariq Hassan — Wed, 07 Oct 2026 03:10:28 +0000

I get asked "can Claude generate images?" about once a week, usually by someone who just watched Claude produce a perfect landing page and assumed a hero image would be the easy part. The short answer is no: Claude does not output pixels. The longer answer is more useful, because there are three or four reliable ways to get images out of a Claude workflow, and picking the right one saves a lot of wasted prompts.

This post is the version of that answer I wish I had a year ago: what the model does and doesn't do, what it can produce instead, and a working setup for getting real raster images from inside Claude Code. For photographic stuff like product shots, I don't route through Claude at all; I use Supavisual for that, and I'll explain where the line sits.

Can Claude generate images? The official answer

Anthropic is unusually direct about this. The vision docs have an FAQ entry that reads:

No, Claude is an image understanding model only. It can interpret and analyze images, but it cannot generate, produce, edit, manipulate, or create images.

So images go in, text comes out. Claude accepts JPEG, PNG, GIF and WebP as input (for animated GIFs only the first frame is used), and it is very good at reading them: screenshots, charts, UI mockups, whiteboard photos. But every token it returns is text.

That's the part people skip over: text covers a lot of formats. SVG is text. HTML with a <canvas> is text. A Python script that draws a PNG is text. A tool call that asks an image model for a picture is also text. Once you stop expecting Claude to be an image model and treat it as the thing that writes the instructions for one, most of the "Claude can't do images" frustration goes away.

What Claude can actually produce

Here's how I think about the options, roughly ordered from "works in any chat" to "needs setup":

Route	What you get	Good for	Weak at
Inline SVG	Vector markup	Icons, logos, diagrams, simple illustrations	Anything photographic, gradients get muddy fast
HTML / CSS / canvas	A page that renders a visual	Mockups, animated demos, generative patterns	Exporting a clean file without a browser step
Plotting / imaging code (matplotlib, Pillow)	A script that writes a PNG	Charts, OG cards, templated graphics, batch jobs	Organic, painterly or photo content
Mermaid / Graphviz	Diagram source	Flowcharts, architecture, sequence diagrams	Visual polish
Tool call to an image model (CLI, MCP, API)	A real raster image	Hero images, illustrations, textures	Costs money, needs a key, less deterministic

The first four are deterministic: the same code gives the same picture, which you can diff, review and commit. The last one is where you get photorealism, but you're now depending on a separate model and paying per image.

Route 1: SVG and HTML, straight from the chat

If you ask Claude for "a logo for a CLI tool called pgsnap, flat, two colors, as SVG", you get valid SVG markup back. In the claude.ai app that usually renders in an artifact, so you see the result immediately. In Claude Code it just writes the .svg file into your repo.

A few things that make this work better:

Ask for a viewBox and no fixed width/height. It scales cleanly in CSS that way.
Constrain the palette. "Use only #0f172a and #f97316" gives far more usable output than "make it modern".
Iterate on the code, not the vibe. "Move the circle 10 units left and thicken the stroke to 3" works. "Make it pop more" doesn't.
Paste a screenshot back in. Since Claude can read images, you can render the SVG, screenshot it, and ask what's off. This loop is where the vision side actually helps the generation side.

Where SVG falls apart is anything with texture, lighting or faces. Claude will gamely try to draw a person in SVG, and the result looks like it was drawn by someone describing a person over the phone.

Route 2: let Claude write the code that draws the image

This is my most-used route, especially for repetitive assets. Open Graph cards are the classic example: every blog post needs a 1200x630 image with the title on it, and you do not want a diffusion model for that. You want a script.

Here's one I had Claude Code write and then trimmed down. It runs on Pillow 10.1 or newer (that's when load_default(size=...) gained the size argument), with no font files to ship:

# og_card.py - render a 1200x630 Open Graph card from a title string
import sys
import textwrap
from PIL import Image, ImageDraw, ImageFont

W, H = 1200, 630
BG, FG, ACCENT = "#0f172a", "#f8fafc", "#f97316"

def render(title: str, out: str = "og.png") -> None:
    img = Image.new("RGB", (W, H), BG)
    d = ImageDraw.Draw(img)
    d.rectangle([0, 0, 24, H], fill=ACCENT)           # left accent bar
    font = ImageFont.load_default(size=64)             # Pillow >= 10.1
    lines = textwrap.wrap(title, width=28)[:4]
    y = (H - len(lines) * 80) // 2
    for line in lines:
        d.text((90, y), line, font=font, fill=FG)
        y += 80
    img.save(out, optimize=True)
    print(f"wrote {out} ({W}x{H})")

if __name__ == "__main__":
    render(" ".join(sys.argv[1:]) or "Untitled post")

pip install "pillow>=10.1"
python og_card.py Can Claude generate images? Here is what actually works
# wrote og.png (1200x630)

I ran exactly this to make the card for this post: dark background, orange bar on the left, title in white, wrapped onto two lines.

Once the script exists, Claude Code can loop over your posts/ directory and regenerate every card whenever you change the design. Boring and repeatable is what you want for build assets. The same pattern works with matplotlib for charts in docs: describe the chart, let Claude write the plotting code, commit the code next to the PNG so the next person can regenerate it.

Route 3: Claude Code calling a real image model

When you actually need a raster image from a model, the trick is to give Claude Code a tool it can call. You have two main options.

A CLI plus a skill. Vercel's ai-cli (repo: vercel-labs/ai-cli) wraps their AI Gateway and has an image command. Its README lists Node.js 22+ as a requirement, plus either an AI Gateway key or a provider key like OPENAI_API_KEY:

npm install -g ai-cli
export AI_GATEWAY_API_KEY=your_key_here

ai models --type image                       # what's available, with rates
ai image "flat illustration of a server rack, navy and orange" -o public/hero.png
ai image -m flux-2-pro "a sunset" -o renders/    # short ids resolve to creator/model

The repo also ships a skills/ai-cli folder, so Claude Code can learn to reach for the CLI on its own when you ask for "a hero image for the pricing page" in plain English. Even without the skill, Claude Code can run the command through its Bash tool if you tell it the CLI exists.

One pricing detail the earlier write-ups gloss over: Vercel's AI Gateway pricing page says the free tier includes $5/month of credit, but only for a subset of "Free Tier eligible" models, and free requests are rate limited per model (you'll see 429s if you push it). Buying any credits moves you to the paid tier, and the monthly free credit stops applying. Fine for a handful of hero images; plan for it if you're batch-generating.

An MCP server. If an image provider ships an MCP server, Claude Code can register it and call it like any other tool. The command shape for a local stdio server, from Claude Code's MCP docs, is:

claude mcp add --env API_KEY=your-key --transport stdio my-image-server -- npx -y <the-server-package>

Remote servers use --transport http <name> <url> instead. I'm deliberately not naming a specific image MCP package here, because the ecosystem churns fast; check the provider's own docs for the exact package and env var names.

Either way, the mental model is the same: Claude writes the prompt, picks the parameters, calls the tool and saves the file. The pixels come from a different model.

Which route for which job

After a lot of trial and error, this is roughly my decision tree:

Icon, logo draft, diagram: SVG or Mermaid straight from Claude. Free, instant, editable.
Chart or templated graphic (OG cards, social banners with text): have Claude write Pillow/matplotlib code and commit it.
One-off illustration or hero image in a repo: Claude Code plus an image CLI or MCP server.
Product photos, lifestyle shots, background removal, upscaling at volume: a dedicated image tool. This is where an LLM-in-the-middle adds friction rather than removing it.

FAQ

Can Claude generate images in the free plan?
No plan changes this. Claude on any tier returns text only. You can still get SVG, HTML and code that renders images on the free plan, since those are text outputs.

Can Claude edit an image I upload?
No. It can analyze it (describe it, read text in it, spot UI bugs), but Anthropic's docs say it cannot edit or manipulate images. To edit, have Claude write Pillow code for simple operations, or use an image tool for anything generative.

Can Claude Code generate images?
Not by itself, but it can run tools that do. Install an image CLI or add an image-generation MCP server, and Claude Code will call it and save the output into your project.

Is Claude's SVG output good enough for production?
For icons and diagrams, often yes after a couple of rounds of feedback. For illustrations with depth, lighting or people, no; use an image model.

Wrapping up

So: can Claude generate images? Not natively, and the docs are clear about that. But "Claude can't make images" is the wrong takeaway. It writes SVG, it writes the code that draws your charts and cards, and in Claude Code it can drive a real image model for you. For the photographic side, especially e-commerce product shots, background swaps and batch edits across a whole catalog, I use Supavisual, which has templates for studio, apparel and jewelry shots plus remove-background, upscale and batch editing built in.

Use Claude for the parts that are really code, and a proper image tool for the parts that are really photos. That split has saved me more time than any single prompt trick.