DEV Community: Selin Orlov

Higgsfield Pricing Review 2026: Nine Credits Are Not Nine Dollars

Selin Orlov — Mon, 19 Oct 2026 15:52:26 +0000

A nine-credit Generate button shows a debit, not a dollar price. It does not reveal the plan that supplied those credits, their renewal terms, or their value relative to another site's ten-credit button. I tested the distinction with a LUMA phone-package image and tabletop unboxing video.

This is an independent 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. Higgsfield successfully delivered a playable video and two stills in this test. The balances below are observed transactions, not an invented price list.

My verdict in 60 seconds

Higgsfield's tested Wan 2.5 Fast video took 9 Higgsfield credits, from 10 → 1. Two Kyncept Plus videos took 10 Kyncept credits each, from 289 → 279 → 269. Higgsfield's separate image account spent 2 Higgsfield credits per Nano Banana Pro still, from 6 → 4 → 2. Kyncept spent 1 Kyncept credit per Nano Banana Pro still, continuing from 269 → 268 → 267. The units are platform-specific; neither figure is a dollar comparison.

Video deliverable: Higgsfield selected 5 seconds and delivered 5.042 seconds; Kyncept delivered two 8.000-second files. The prompt requested eight seconds, but the settings were not matched.
Image observation: the two Higgsfield completion cards appeared earlier than their paired Kyncept UI results. Two runs cannot establish a general speed lead.
Unpriced: current matching subscription costs, credit inclusions, top-ups, rights, and failed-job treatment were not established.

For a single-file, eight-second first draft, I would try Kyncept here. For a five-second teaser, Higgsfield demonstrably produced one. Neither recommendation rests on an unverified dollar-per-credit conversion.

The comparison the prompt allows—and the one it does not

Both products received text-only LUMA prompts, without reference images or video start/end frames. The still called for a matte-black phone inside a charcoal-and-teal cardboard box with a window and pull tab; the video called for hands to open it, peel film, and lift the phone. Both UIs selected 16:9. But Higgsfield's Wan 2.5 Fast UI selected 5s/720p, although the video prompt said eight seconds. Kyncept's Kyncept Plus results are eight seconds. These are not matched-duration or matched-model video purchases.

For images, both UIs displayed Nano Banana Pro and selected 16:9; all four originals measure 1376 × 768. The common image model makes the debit observation easier to interpret, but it does not turn two proprietary credit units into common currency.

Higgsfield's Wan 2.5 video panel shows Generate marked 9; the completed card below documents the selected 5s setting.

Kyncept Plus shows 16:9 and Generate marked 10; the eight-second runtime was measured from the downloaded files.

Higgsfield's video: a successful nine-unit transaction

The video account showed 10 Higgsfield credits immediately before submission and 1 after delivery: 10 − 1 = 9. The completed History card shows the playable LUMA result labeled Wan 2.5 Fast, 5.0s, 720p, 16:9. The downloaded original measures 5.042 seconds, 1904 × 1104, and 7,937,554 bytes. The 720p UI selection and measured file dimensions are different observations, not interchangeable specifications.

Before this Higgsfield video job: 10 credits left.

The playable result card lists Wan 2.5 Fast and the UI's 5.0s/720p/16:9 labels.

After delivery: 1 credit left in the video account, a nine-credit debit.

This is a successful generation, not a failed attempt. The exact Higgsfield UI completion time is unknown: after-click timestamp logging crashed, and the captured raw response was truncated before its full terminal-status JSON could be parsed. Delivery is established by the playable UI result, matching individual job ID, and downloaded file. The incomplete timing record must not become a made-up speed claim.

Kyncept's videos: two debits in one wallet

The first Kyncept job moved the wallet 289 → 279, the second 279 → 269. Each cost 10 Kyncept credits and produced a distinct 8.000-second, 1280 × 720, 24fps H.264 file with an AAC stereo track. The first original is 2,148,345 bytes, the second 1,951,133 bytes. Different frames show two actual takes, not an expected number of acceptable takes in future batches.

The first Kyncept submission shows 289 in the wallet and 10 on Generate.

After the first result, the wallet reads 279: ten Kyncept credits spent.

After the second job, two result cards are visible and the wallet reads 269: another ten-unit debit.

The measured Kyncept UI completion times were 91.4 and 282.1 seconds, a 190.7-second spread within two attempts. The test does not establish a typical wait, and the missing Higgsfield video UI timestamp prevents a video-speed ranking.

Why nine versus ten does not settle a video budget

Higgsfield's delivered file is 8.000 − 5.042 = 2.958 seconds short of the prompt's requested runtime under the tested Wan setting. A five-second teaser may be fine; an eight-second storyboard may not be. Kyncept's two observed files meet eight seconds, but a credit count from one platform still cannot be divided by credits from the other. Even a per-second credit figure would have different denominators: different outputs and different proprietary wallets.

An eight-second-capable Higgsfield option might change the decision; its price and output were not tested. Neither other free video models nor a paid Veo generation were tested in this phone case. I will not price an unperformed extension or assert that five seconds is a universal Higgsfield ceiling.

The image buttons are not dollar labels

Both image panels offered Nano Banana Pro with a single 16:9 output selected. Higgsfield's Generate button read 2; Kyncept's read 1. That is a quoted debit in each product's own unit. Even with the same public model name and 1376 × 768 originals, it is wrong to call Higgsfield “twice the cash price.” Subscription allocations, top-up pricing, expiration, and the cost of other plan features remain unverified.

Higgsfield image settings show Nano Banana Pro, 16:9, one output, and Generate marked 2.

Kyncept image settings show Nano Banana Pro, 16:9, and Generate marked 1.

Higgsfield's separate image account: six to two

The Higgsfield images were made on a different account from the Higgsfield video. This image wallet went 6 → 4 → 2 across two completed stills: two 2-Higgsfield-credit debits, or 4 units in that image wallet. Do not add that account's wallet balances to the video's 10-to-1 sequence or present their combined changes as one account's bill.

The separate Higgsfield image account begins with 6 credits left.

After the first image, that same wallet reads 4: two units spent.

After the second image, that image wallet reads 2: another two units spent.

The first image's completed UI card was observed no later than 41.01 seconds after submission and the second no later than 37.63 seconds. These are completion-card observation bounds, not exact server times. In both paired attempts, the Higgsfield cards appeared before Kyncept's UI results; that favorable observation is limited to this small sample.

Kyncept's continuing image wallet: 269 to 267

Kyncept used one continuous wallet for its two videos and two images. After the videos left 269, the image balances went 269 → 268 → 267: 1 Kyncept credit per still. The UI completion times were 55.7 and 54.0 seconds. They are measured UI times, whereas Higgsfield's figures mark first observed completion cards, so a precise percentage speed advantage would overstate the timing evidence.

Before Kyncept image one: 269 credits in the wallet and 1 on Generate.

The first completed image appears with 268 credits remaining.

The second completed image appears with 267 credits remaining.

Across the four jobs, 289 − 267 = 22 Kyncept credits: 10 + 10 for video and 1 + 1 for images. That is a legitimate within-wallet total, not a cross-platform cash rate. Both services also produced an unrequested Apple mark in a second image. The detailed image-quality and watermark inspection belongs in the image-focused companion article, not this billing review.

Use case: twenty product stills

For 20 one-image jobs at the observed Nano Banana Pro settings, assuming unchanged debit rates, the planning ledger is 20 × 1 = 20 Kyncept credits or 20 × 2 = 40 Higgsfield credits. The units remain different. Forty is not twice the cash price of twenty. The test accounts' displayed balances do not themselves fund that hypothetical batch, and no matched plan prices were collected.

The earlier-observed Higgsfield cards matter if turnaround is your constraint. A buyer should test that behavior under their own workload, then obtain each plan's included units and renewal terms before turning either projected debit into money. A 20-image spreadsheet is useful as an internal wallet forecast; it is not an invoice.

Use case: two eight-second unboxing takes

The observed Kyncept pair gives a narrow arithmetic result: 2 delivered eight-second takes × 10 = 20 Kyncept credits, with UI waits of 91.4 and 282.1 seconds. The Higgsfield record gives 1 delivered 5.042-second Wan take for 9 Higgsfield credits. Two jobs at that same displayed setting would hypothetically debit 2 × 9 = 18 Higgsfield credits if unchanged; no second job was tested, and that still would not establish two eight-second files. Presenting 18 versus 20 as equivalent output would be wrong even before the currency problem.

Both downloaded videos contain AAC stereo tracks. I did not listen for the requested paper tear, hinge creak, film crinkle, and tray click, nor verify that voice or music is absent. Sound-track presence cannot be priced as verified Foley or used to invent a revision rate.

The checkout worksheet this review cannot complete

There was no freshly verified, matched pair of cash-priced plans in this evidence set. Before converting these receipts into dollars, record these items for both products on the same date:

Plan terms: actual checkout price, billing period, renewal price, and applicable taxes.
Credit supply: included units, rollover, expiration, and differences between trial, promotional, and paid credits.
Comparable job: exact model, duration, resolution, aspect ratio, output count, and pre-submit debit; quote an eight-second-capable Higgsfield option separately if needed.
Extra usage: top-up price and quantity, plus what happens when included credits run out.
Usable-output criterion: acceptable duration, sound check, revisions, and a measured keep rate from more than two attempts.
Terms to verify: current commercial-use permission, failed-job credit treatment, cancellation, and refund rules.

Then calculate cash per usable, specification-matched asset, distinguishing included credits from marginal top-ups. A plan's nominal dollars-per-credit can be misleading when unused credits expire or the subscription includes unrelated features. Nothing in the balance screenshots settles those assumptions.

What the receipts cannot establish

This one successful Wan job does not price all Higgsfield video models or define a free-tier quota. The two image jobs belong to a separate Higgsfield account; the four Kyncept jobs share one wallet but do not establish every customer's allocation. There was no failed-job observation, commercial-license audit, matched checkout, or production month. Therefore there is no evidentiary basis here for refunds, commercial rights, a monthly dollar ROI, or a cross-platform dollar winner.

Nor should file bytes quietly become a price proxy. Higgsfield's tested clip is 7,937,554 bytes versus 2,148,345 bytes for Kyncept's first, but duration and dimensions differ. The stills were Higgsfield PNG and Kyncept JPEG, with different compression. Neither byte ratio ranks sharpness, cash value, or credit purchasing power.

Final verdict: a debit is not an exchange rate

The repeatable findings are 9 Higgsfield credits for a delivered 5.042-second Wan clip, 10 Kyncept credits each for two 8.000-second Kyncept Plus clips, 2 Higgsfield credits each for two Nano Banana Pro stills, and 1 Kyncept credit each for two same-named-model stills. Higgsfield's two image completion cards appeared earlier. These are strong transaction observations and weak dollar-price evidence.

For a five-second teaser, the Higgsfield result deserves consideration. For an eight-second single-file brief, the observed Kyncept result meets the duration while the tested Wan setting does not. Verify a matching Higgsfield alternative and both live plans before buying. Nine credits are not nine dollars, and they are not inherently cheaper than ten credits on another platform.

Which one I would use for this job

For two alternative eight-second LUMA takes, I would start with Kyncept because this run delivered both files and recorded a continuous 20-Kyncept-credit video debit. I would still trial Higgsfield for time-sensitive stills, because its cards appeared earlier in both paired image attempts. That is my disclosed workflow preference, not a claim of a lower cash bill. Check the live settings at https://kyncept.com before spending on either service.

Tripo AI Image to 3D Review 2026: 18.3x the Credits for 101 Seconds

Selin Orlov — Sat, 17 Oct 2026 15:50:43 +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 91/100

Same photograph, same day, two image-to-3D products: a seated chibi reindeer in a corduroy scarf. Tripo charged 55 credits. SupaVoxel charged 3. On this subject Tripo was faster on raw wall clock — 157.0 seconds against 258.3 — and I am going to give Tripo that row properly rather than explain it away. Two things stop it being a general speed win: across the ten subjects I ran, SupaVoxel was the faster tool on seven of them, and here the 101 seconds cost 52 extra credits, a mesh that arrives non-watertight with inconsistent winding, and 6.45× the bytes to download.

Here is the scorecard for this one job: what it costs to turn a photo into a printable figurine.

Credits per generation — Tripo 2/10 (55) · SupaVoxel 10/10 (3) — 18.3×, same photo, same defaults
Price visible before upload — Tripo 3/10 (hidden) · SupaVoxel 10/10 (on the button) — Tripo's button says Generate until you upload, then Generate 55
When the charge lands — Tripo 4/10 (on submit, 870 → 815) · SupaVoxel 8/10 (nothing charged while running) — Tripo takes it before you see a result
Rate limits — Tripo 10/10 (0) · SupaVoxel 10/10 (0) — genuine tie, neither caps you
Rationed switches — Tripo 3/10 (3 trial-limited) · SupaVoxel 10/10 (0) — Clean Topology Trial ×2, Generate in Parts ×1, 8K Texture ×1
Wall clock, this subject — Tripo 9/10 (157.0 s) · SupaVoxel 6/10 (258.3 s) — Tripo wins this subject; SupaVoxel won 7 of the 10 I ran
Wall clock, predictability — Tripo 10/10 (135–189 s across ten) · SupaVoxel 4/10 (100.2–867.4 s) — Tripo's spread is 54 s against 767 s
Batch of 100 — Tripo 2/10 (5,500 credits, 6.46 GB) · SupaVoxel 10/10 (300 credits, 1.00 GB)
Reference images per run — Tripo not measured · SupaVoxel 9/10 (5 slots) — 1 Main plus 4 supplementary angles

Part by part, what the money actually buys:

Tripo won the clock on this subject and that is real: 157.0 seconds against 258.3, a 101-second margin. Across ten subjects, though, SupaVoxel was faster on seven and about 30 s quicker on median — Tripo's advantage is consistency, not speed.
Tripo takes the 55 credits at submit, not at completion — the balance went 870 → 815 while the viewport still read Generating.
Tripo's price is not on the button until you have uploaded an image; SupaVoxel's reads Generate (3 credits) before you upload anything.
The Tripo mesh that arrives after those 157 seconds is not watertight, has inconsistent winding and comes in two pieces — so the wall-clock win is measured to the wrong finish line.

For this job — one photo, one printable figurine, done more than once — use SupaVoxel.

The only input: one 1,517,781 B PNG, sha256 8ba545f2…, handed to both products unmodified on default settings. One photo, two invoices: 55 credits and 3.

The test, in one paragraph

One photo, two products, one day, both left on shipped defaults. Tripo Studio: Best Quality on, Clean Topology off. SupaVoxel: full model, Inference Steps 5, Guidance Scale 5.5, Octree Resolution 256. Both GLBs parsed offline. Credit figures come from the on-screen balances before and after each run, not from a pricing page.

55 credits against 3, for the same photograph

This is the headline number and it does not need interpretation. Tripo deducted 55 credits. SupaVoxel deducted 3. That is 18.3× for the same input, the same day, the same default settings, producing a figurine of the same object at the same target height.

Credits, one generation — Tripo 55 · SupaVoxel 3 · 18.3×
Credits, 100 generations — Tripo 5,500 · SupaVoxel 300 · 5,200 difference
Rate limits or daily caps observed — Tripo 0 · SupaVoxel 0

That last row is a genuine tie worth saying out loud: neither product throttled the run or imposed a visible daily cap. The difference is entirely price per unit.

The SupaVoxel studio before anything is uploaded. The button already reads Generate (3 credits), and the Input Images panel offers five slots — one Main plus four supplementary angles. The price does not move after upload.

Tripo Studio at the same moment. The button reads Generate with an arrow and no number. Beside the quality selector, Clean Topology carries a Trial ×2 badge and is not selected by default. A promotional bubble covers part of the top bar and a third-party ad strip sits along the bottom.

The price does not appear until you have uploaded

This is the part that irritated me most. On Tripo the generate button carries no number at all until an image is in the frame. Upload the reindeer and the button becomes Generate 55. The 18.3× gap only reveals itself at the step where you have already committed the photo.

The SupaVoxel button reads Generate (3 credits) on an empty studio. You know the price before you know whether you want the thing.

Price shown before upload — Tripo no · SupaVoxel yes (3 credits)
Price shown after upload — Tripo 55 · SupaVoxel 3
Change in displayed price after upload — Tripo 0 → 55 · SupaVoxel 3 → 3

Tripo with the photo uploaded. Only now does the button read Generate 55, with the balance at 870 in the top bar. The quality selector is still on Best Quality and Clean Topology Trial ×2 is still unselected — this run used Tripo's default throughout.

SupaVoxel with the same photo in the Main slot. The button still reads Generate (3 credits) — not one character changed on upload — with the balance of 352 visible for reconciliation.

The 55 credits are taken on submit, not on delivery

I watched the balance across two screenshots. Before generation, Tripo's top bar read 870. During generation, with the viewport still showing Generating and no model in existence, it read 815. The 55 credits were gone before there was anything to charge for.

Tripo makes no product statement about when the charge lands that I could capture, so I am reporting the observation and not a policy: not measured on the policy, observed on the balance.

On the SupaVoxel side the project grid shows the cost per card — finished cards read 3 credits, cards still running read 0 credits. Nothing is deducted while a job is in flight, and you can see that in the list rather than in a billing statement.

Balance before / during generation — Tripo 870 → 815 · SupaVoxel no deduction observed mid-run
Cost visible per job afterwards — Tripo not surfaced per job · SupaVoxel 3 credits on the card
Stated charging policy — Tripo not measured · SupaVoxel not measured

Tripo mid-generation. The balance has already dropped to 815. A Humanoid Rigging & Text2Motion promotional banner runs across the top of the viewport and a View Your Model tutorial popup sits in the middle of it, requiring a click to dismiss. The card reads 96s — that is a countdown of remaining time, not elapsed time.

The SupaVoxel project grid. Each card carries what that job cost — 3 credits · 9/26/2026 — and jobs still running read 0 credits. One SupaVoxel flaw is visible here too: under concurrent use this grid is not reliably newest-first, and I had to open the project by id rather than by card position.

Three of Tripo's switches are rationed by trial count

Tripo's paid run is not the full product. Three switches I wanted are metered separately: Clean Topology carries Trial ×2, and in the Members Only panel, Generate in Parts and 8K Texture each carry Trial ×1. All three are off by default.

That matters for this case specifically, because Clean Topology is the switch that would have addressed the topology problems in the delivered mesh — the 2 non-manifold edges, the 2 boundary edges, the 2 connected components. Tripo's default output has those, and the fix is rationed to two uses.

SupaVoxel's Advanced Options are numeric sliders with their values on screen: Inference Steps 5, Guidance Scale 5.5. No trial counter, no members-only gate.

Trial-rationed switches — Tripo 3 (Clean Topology ×2, Generate in Parts ×1, 8K Texture ×1) · SupaVoxel 0
Parameters exposed as numeric values — Tripo quality presets · SupaVoxel Inference Steps 5, Guidance Scale 5.5
Reference images per run — Tripo not measured · SupaVoxel 5 slots (1 Main + 4 angles)

SupaVoxel Advanced Options expanded: Inference Steps and Guidance Scale as sliders with the numbers visible and editable. This run used these factory defaults, identical across all ten cases I ran — "both on defaults" is documented, not assumed.

The clock: Tripo won this subject, and SupaVoxel is usually faster

This is the row where a single case will mislead you, so here are both halves of it.

On this subject Tripo won, clearly. Tripo 157.0 seconds against SupaVoxel's 258.347 — 101 seconds, one run each on the same photograph. I am not going to soften that; it is the one row Tripo takes outright in this article.

Now the part a one-case review cannot see. I ran ten subjects through both tools, one run per tool per subject, and across those ten SupaVoxel was faster on seven of them. SupaVoxel's median was 133.6 seconds against Tripo's 163.5 — about 30 seconds the other way. This reindeer is one of only three subjects where Tripo came out ahead. If I had tested only this one, I would have told you Tripo is the faster tool, and I would have been wrong.

And the reason those two facts coexist is the interesting finding: Tripo is far more predictable. Tripo's ten runs spanned 135 to 189 seconds — a 54-second spread, tight enough to plan around. SupaVoxel's spanned 100.2 to 867.4 seconds, a 767-second spread. SupaVoxel is usually quicker and occasionally enormously slower; a scale-model tank took it 867 seconds and a watch stand 250. This reindeer, at 258, is one of those slow draws.

So: if you want the lower average wait, that is SupaVoxel. If you need to promise someone a delivery time, that is Tripo. Ten subjects, one run each, is a sample and not a statistic — but the pattern is consistent enough in both directions that I will state both.

This subject — Tripo 157.0 s · SupaVoxel 258.347 s · 101 s to Tripo
Faster on how many of ten subjects — Tripo 3 · SupaVoxel 7
Median across ten subjects — Tripo 163.5 s · SupaVoxel 133.6 s
Range across ten subjects — Tripo 135–189 s (54 s spread) · SupaVoxel 100.2–867.4 s (767 s spread)
Basis — my own stopwatch and the on-screen states; Tripo exposes no completion timestamp and its counter counts down rather than up

What those 101 seconds cost

Now price it, on this subject, where Tripo actually won them. For 101 seconds of wall clock you pay Tripo 52 extra credits, and you receive a file that is 64.63 MB against 10.02 MB — 6.45× — which on a 12 Mbps mobile connection takes 43.1 seconds to pull down against 6.7.

Subtract the download and the 101-second lead is already down to about 65 seconds before anyone has opened a slicer. Then add the repair: Tripo's welded mesh is not watertight, its winding is inconsistent, it has 2 boundary edges, 2 non-manifold edges and 2 connected components. Patching, unifying and merging that is not free, and at that point the remaining lead is gone.

Credits for the 101 seconds — 52 extra (55 vs 3)
Download time for the file — Tripo 43.1 s · SupaVoxel 6.7 s at 12 Mbps
Lead after download — about 65 s
Repair operations required — Tripo 3 · SupaVoxel 0

Tripo's result screen, reporting 1,996,779 triangles and 1,028,963 vertices — figures that matched the downloaded GLB exactly, so Tripo's panel does not inflate. The View Your Model tutorial popup is still parked over the model you just paid 55 credits for.

The SupaVoxel result page: an Export dropdown in the top bar, four inspection modes at top left, and 1,499,386 triangles at top right — which also matched the downloaded GLB exactly. Neither panel lies; that row is a tie.

A batch of 100: 5,500 credits against 300

One figurine is a curiosity. A hundred is a business, so here is the same run multiplied out.

Tripo: 5,500 credits, 6.46 GB of downloads, $443 of resin. SupaVoxel: 300 credits, 1.00 GB, $488 of resin.

Generation time is the row I cannot call, and I want to be exact about why. A hundred copies of this reindeer, run serially, is 4.4 hours on Tripo against 7.2 on SupaVoxel. But a hundred assorted objects lands anywhere in 3.8–5.2 hours on Tripo and 2.8–24.1 hours on SupaVoxel, going by the ten subjects I timed. Those ranges overlap, so "Tripo finishes your batch sooner" is a claim I would have to pick a subject to support.

On the median subject SupaVoxel gets the hundred done in about 3.7 hours against Tripo's 4.5 — and that median is exactly what you should not plan on, because it hides the tail that makes the whole row unanswerable. Fill the hundred with tank-shaped objects and SupaVoxel needs about 24 hours where Tripo's worst case is around 5. What survives is the predictability point: Tripo's batch time barely moves, SupaVoxel's can be eight times its own best.

Tripo is $45 cheaper in resin across the hundred. It is also 5,200 credits more expensive and 5.46 GB heavier, and every one of those 100 files arrives needing the same three repairs. At an estimated three minutes each — an estimate, not a measurement, and I am labelling it as one — that is five hours of work — more than the head start Tripo earned on this subject, and there is no head start at all on the seven subjects where SupaVoxel finished first.

Credits for 100 — Tripo 5,500 · SupaVoxel 300 · 5,200 difference
Download volume for 100 — Tripo 6.46 GB · SupaVoxel 1.00 GB
Serial time, 100 of this subject — Tripo 4.4 h · SupaVoxel 7.2 h
Serial time, 100 assorted objects — Tripo 3.8–5.2 h · SupaVoxel 2.8–24.1 h · overlapping, no winner
Serial time on the median subject — Tripo 4.5 h · SupaVoxel 3.7 h · a median that hides the tail
Resin for 100 — Tripo $443.00 · SupaVoxel $488.00
Repair passes needed — Tripo 100 · SupaVoxel 0

What else you pay for in attention

Not every cost is on the invoice. Between submitting and exporting, Tripo showed two modal tutorials that must be dismissed — View Your Model during generation, then Guide with a five-video list on the viewer — plus a promotional banner across the top of the viewport that changed content between screens, plus a third-party ad strip on the landing screen.

The worst instance: clicking Export opens Tripo's export dialog with the Guide popup on top of it, covering File Name and Format. You close a tutorial to fill in the export form for the model you already paid for.

Across the same run the SupaVoxel viewport showed zero popups and zero promotional strips.

Modal tutorials between submit and export — Tripo 2 · SupaVoxel 0
Promotional banners in the viewport — Tripo present in generation and result · SupaVoxel 0
Export dialog obstructed on open — Tripo yes · SupaVoxel not applicable

Dismiss Tripo's first popup and the second arrives: Guide, a list of five tutorial videos, again across the model. The Export, Share and Free Retry (×3) controls only become visible underneath it.

Tripo's export dialog with the Guide popup sitting on top of it. Two of the three fields are covered. This is the last screen between you and the 64.63 MB file.

SupaVoxel generating. One numeric progress bar counting up, an estimate of 5–10 minutes, and an otherwise empty viewport. Note the direction: SupaVoxel counts up from 2%, Tripo counts down from 96s. They are not the same kind of number and should not be compared as one.

Final verdict: Tripo scores 58, SupaVoxel scores 91

Tripo won this subject on the clock — 157.0 seconds against 258.3, by 101 — and Tripo is the more predictable tool by a wide margin: 135–189 seconds across ten subjects against SupaVoxel's 100.2–867.4. Both of those are real and both are Tripo's. What is not Tripo's is a general speed claim: across those same ten subjects SupaVoxel finished first on seven and was about 30 seconds quicker on median. This reindeer is one of three where Tripo led. If your workflow is "get a first pass in front of a client, then rebuild the topology in Blender anyway," Tripo's consistency is worth money and the mesh problems are not your acceptance criteria.

For everyone else, the price of those 101 seconds is 52 extra credits per object, 54.6 MB of extra download, and a repair pass on every file. At 100 units that is 5,200 credits, 5.46 GB and 100 repairs — against a head start that only exists on some subjects and, on this one, is smaller than the repair time it creates. Tripo also hides the price until you upload, takes the credits at submit rather than at delivery, and rations the one switch that would have fixed the topology to two uses.

Tripo: 58/100. SupaVoxel: 91/100.

Which one I would use for this job

If you are generating more than one of these, use SupaVoxel. 3 credits instead of 55, the price on the button before you upload, per-job cost printed on the project card, nothing deducted while a job is running, no trial-metered switches, five reference slots instead of one visible one, and a file that arrives watertight and ready to slice.

Three things to hold against SupaVoxel honestly: it lost the clock on this subject by 101 seconds, and its run times are far less predictable than Tripo's — 100 to 867 seconds across ten subjects, so a slow draw is a genuine risk even though the median favours it. Its output carries no real-world units, so you scale it yourself before printing. And the project grid is not reliably newest-first when several jobs run at once — I got bitten by that in this very run.

Tripo AI 3D Review 2026: 64.84 MB for 44% Fewer Triangles

Selin Orlov — Thu, 15 Oct 2026 15:50:16 +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.

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

Same tank photograph, two image-to-3D products, one afternoon. Tripo returned a 64.84 MB file containing 1,931,963 triangles. SupaVoxel returned 15.79 MB containing 2,786,054 — 44% more geometry in a file 4.1× smaller. Start with the row Tripo wins, because on a hard-surface subject it is the row that decides the job: Tripo's armour plates are flatter, 0.363 mm flatness RMS against SupaVoxel's 0.516 mm, and you can see it without a single number — its side skirts are straight-edged rectangles and SupaVoxel's undulate. What Tripo does not win is fidelity to the photograph. It gave the tank six road wheels. The photograph, and the SupaVoxel model, have seven.

Here is the scorecard for likeness and for what you download to get it.

Flatness of the armour plates — Tripo 9/10 (0.363 mm RMS) · SupaVoxel 5/10 (0.516 mm) — Tripo wins, plainly, and it matters most on this subject
Road wheels against the photo — Tripo 3/10 (six) · SupaVoxel 10/10 (seven) — countable, no tool needed
Track and rivet relief depth — Tripo 3/10 (0.04–0.10 mm RMS) · SupaVoxel 9/10 (0.44–0.49 mm) — 5–13× deeper
Gun barrel straightness — Tripo 9/10 (0.181 mm mean centreline deviation) · SupaVoxel 9/10 (0.182 mm) — a dead tie
File weight for what is inside it — Tripo 2/10 (64.84 MB, 33.56 B/triangle) · SupaVoxel 10/10 (15.79 MB, 5.67 B/triangle)
Texture bytes a printer can never read — Tripo 1/10 (5.11 MB) · SupaVoxel 10/10 (0 B)
First load on 12 Mbps mobile — Tripo 2/10 (43.2 s) · SupaVoxel 9/10 (10.5 s)
Geometry VRAM — Tripo 8/10 (56.1 MB) · SupaVoxel 5/10 (81.4 MB) — Tripo wins this one; more triangles cost memory

Part by part, what is wrong with what Tripo delivered here: one road wheel is missing against the photograph; the track links and skirt rivets are 5–13× shallower than SupaVoxel's, which on a 0.4 mm nozzle means they disappear entirely; the file carries 5.11 MB of maps a slicer will never open, one of which alone is 3.3× the size of SupaVoxel's entire texture payload; and 64.84 MB is 43.2 seconds of mobile download for a model with 44% less geometry in it than the 10.5-second one. For putting a tank on a product page or in front of a printer, use SupaVoxel — unless flat plate surfaces are your one criterion, in which case Tripo earns its 55 credits against SupaVoxel's 3.

The photo shows only the left front three-quarter. The right side, the rear and the back of the turret roof are not in it — both products are inventing that half, and later in this article I look at what each one invented.

44% more triangles in a quarter of the file

The headline number of this test is a contradiction you can verify yourself by downloading both GLBs and reading their headers.

Triangles — Tripo 1,931,963 · SupaVoxel 2,786,054 · 44% more
Vertices — Tripo 1,029,151 · SupaVoxel 1,498,519 · 46% more
File size — Tripo 64,842,048 B (64.84 MB) · SupaVoxel 15,786,768 B (15.79 MB) · 4.1×
Bytes per triangle — Tripo 33.56 B · SupaVoxel 5.67 B · 5.9× cheaper per face

The gap is entirely encoding and texture policy. SupaVoxel's geometry ships compressed and quantised; Tripo's geometry is uncompressed, and it packs three 4096×4096 maps totalling 8.72 MB on top. So Tripo's 64.84 MB is not buying geometry — this article's title is the whole finding.

Where Tripo wins: the plates are flatter, and you can see it

I am not going to bury this. Fit a plane to the largest near-planar patch on each hull: Tripo 0.363 mm RMS, SupaVoxel 0.516 mm, on patches of comparable size (98.2 mm diagonal against 93.6 mm). Tripo is 1.4× flatter. On a machine subject — armour plate, housing, facade — that is the single most visible quality there is, and Tripo took it.

One caveat I will volunteer: the maximum deviation on those patches is 1.595 mm for Tripo and 1.418 mm for SupaVoxel, which reads as a SupaVoxel win. It is not the right statistic for flatness. RMS is, and Tripo wins it.

Six road wheels

Now the fidelity row, which goes the other way and needs no instrument. The photograph shows a track wrapping seven road wheels. The SupaVoxel model has seven. Tripo's has six.

At 120 mm long, a missing road wheel is not a subtlety; it is the running gear of the vehicle being wrong by one unit in a group of seven that anyone looking at the model will count.

The track detail is there on both, at different depths

Both models produced genuine periodic structure in the lower hull — neither smeared the track into a band. Sample the bottom 25% of the hull side on each and run an FFT independently on left and right:

Strongest period — Tripo 12.28 / 12.31 mm (the spacing of its road wheels), plus a stable fine period at 1.46 mm · SupaVoxel 4.05 / 4.04 mm
Left/right agreement — Tripo peak-to-median 9.2 and 3.6 (the right side is clearly weaker) · SupaVoxel 14.5 and 13.3
Fine relief depth above 20 cycles — Tripo 0.036–0.097 mm RMS · SupaVoxel 0.439–0.485 mm · 5–13× deeper

One honest caveat on that band: it contains the side skirt as well as the track, so read those figures as "lower-hull repeat pitch", not as a link count.

The depth number is the one that survives contact with a machine. A 0.4 mm nozzle lays down 0.44 mm of relief. It does not lay down 0.04 mm. Printed on FDM, Tripo's track and rivet detail is flattened out of existence and SupaVoxel's stays on the part.

The gun barrel: neither product bent it

This is the feature I expected to separate them and it did not. Slice both barrels, take each section's bounding-box centre, fit a 3D line through the centres, and measure how far the centres wander from it.

Mean centreline deviation — Tripo 0.181 mm · SupaVoxel 0.182 mm · a tie
Taper over the barrel — Tripo −17.8% (tapers in) · SupaVoxel +19.0% (flares out, a muzzle brake)
Section roundness, mean departure from a circle — Tripo 8.0% · SupaVoxel 10.1% — Tripo wins

On a barrel roughly 24 mm long and 1.76 mm in radius, 0.18 mm of wander is about a tenth of the radius and invisible on the part. I will name the number I am choosing not to use: maximum deviation is 0.749 mm for Tripo and 0.378 mm for SupaVoxel, which looks like a 2× win for it. It is a sampling artefact — Tripo's barrel was cut into 41 sections and SupaVoxel's into 21, and denser sampling finds more outliers. The mean is the fair comparison, the mean is a tie, and anyone with both GLBs can reproduce that.

The taper direction is a real difference, though: the photo shows a distinct thickening at the muzzle. SupaVoxel flares 19.0% to make it. Tripo narrows 17.8%, the opposite way.

The half of the tank neither product could see

The input frames only the left front three-quarter, so the right side, the rear and the back of the turret roof are invented by both. Both inventions are self-consistent; they differ in character.

5.11 MB of texture a printer cannot read

Tripo's 64.84 MB breaks down into three 4K maps and uncompressed geometry. Only one of those maps — baseColor — is of any use to a printer.

baseColor — Tripo 3.61 MB (4096×4096 JPEG) · SupaVoxel 0.86 MB (2048×2048 WebP) · 4.2× lighter
metallicRoughness + normal — Tripo 5.11 MB (2.28 MB JPEG + 2.83 MB PNG) · SupaVoxel 0 B
Texture maps shipped — Tripo 3 · SupaVoxel 1

The 4K normal map alone is 2.83 MB, which is 3.3× SupaVoxel's entire texture payload, and no slicer reads a single byte of it. Said fairly: Tripo's baseColor is genuinely 4K where SupaVoxel's is 2K, so for high-resolution colour printing its source image carries more detail. You pay 2.75 MB for that, plus 5.11 MB you cannot use.

What 64.84 MB costs to move

12 Mbps mobile, this one file — Tripo 43.2 s · SupaVoxel 10.5 s
100 Mbps home, this one file — Tripo 5.2 s · SupaVoxel 1.3 s
CDN at $0.085/GB, 10,000 loads/month — Tripo $55.12 · SupaVoxel $13.42 · $41.70/month, $500/year
A batch of 100 downloads — Tripo 6.48 GB · SupaVoxel 1.58 GB

Forty-three seconds of mobile wait on a product page is not a slow feature, it is an absent one. And the CDN line compounds: $661.40 a year against $161.00 for the same 10,000 monthly loads.

The row SupaVoxel loses on delivery: VRAM

More triangles cost memory, and this is the bill. Geometry VRAM at 32 bytes per vertex and 4 per index is 81.4 MB for SupaVoxel's model against 56.1 MB for Tripo's — 25.3 MB more. On a low-end phone, with several models on one page, that 25 MB counts. The trade is clean and I will state it as a trade: 4.1× less to transfer, 45% more to hold in memory. If your page loads several models at once, decimate before you publish, whichever product you used.

Where else this test went against SupaVoxel

My first attempt on SupaVoxel crashed in the browser before submitting — nothing was charged, but it was an attempt. The in-product Wire screenshot timed out at 60 seconds and I did not recapture it, so the SupaVoxel screenshots for this case are Textured, Mesh and Normals rather than four modes; I regenerated nothing to fix that. And both wireframe close-ups, SupaVoxel's and Tripo's, render as near-black blocks at these triangle counts — they are genuine million-face density rather than empty images, but neither is used as evidence here.

Final verdict: Tripo scores 60/100 on likeness and weight

Tripo earned its 60 on flatness — 0.363 mm RMS against SupaVoxel's 0.516 mm, visible in every skirt crop above — on barrel roundness (8.0% against 10.1%) and on geometry VRAM (56.1 MB against 81.4 MB). Those are real, and on a hard-surface subject the first of them is the one that decides the job.

Against that: six road wheels where the photo has seven; track and rivet relief of 0.04–0.10 mm that a 0.4 mm nozzle erases against SupaVoxel's 0.44–0.49 mm; 64.84 MB of file carrying 44% fewer triangles than SupaVoxel's 15.79 MB; 5.11 MB of maps no printer can read; 43.2 seconds of mobile load against 10.5; and $661.40 a year of CDN against $161.00. The barrel is a tie and I am calling it a tie. The trade, priced once: Tripo's flatter plates and 25.3 MB of VRAM headroom cost you 18.3× the credits, 49.06 MB per download, one road wheel, and the entire fine-scale detail layer.

Which one I would use for this job

Put the tank through supavoxel.com: 15.79 MB instead of 64.84, 2,786,054 triangles instead of 1,931,963, seven road wheels instead of six, one 2K WebP map instead of three 4K maps, 10.5 seconds of mobile load instead of 43.2, and $13.42 of CDN a month instead of $55.12 — for 3 credits instead of 55. If perfectly flat plate surfaces are the single thing your model is judged on, this is the one case in ten where Tripo is the better buy.

Hyper3D GLB Review 2026: Gray Jaw Patches on a 10.72 MB File

Selin Orlov — Tue, 13 Oct 2026 15:58:11 +0000

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

For an illustrative product-page scenario, the detail worth inspecting is not the clip's overall silhouette but the two U-shaped jaws and the purple finish around their tips. I zoomed into those features in the matched offline renders. One file showed a gray patch where the source picture stays purple—even though the mesh underneath might be sound.

I gave the same picture to Hyper3D and SupaVoxel, took the downloadable PBR files into the same offline viewer and checked those three visible features from matched angles. Hyper3D's inspected asset was Gen-1.5; the prettier-sounding Gen-2.5 preview on my Free account could not be downloaded.

My verdict in 60 seconds — SupaVoxel wins the purple appearance brief; Hyper3D Gen-1.5 wins the lightweight, cleaner-mesh brief. Hyper3D preserves both open jaws in its 10.72 MB PBR GLB but puts gray patches on their exterior. SupaVoxel keeps a more continuous purple finish and a finer line beside the slot in the matched views. Its measured 87.17 MB Original size browser-export GLB is 8.13× the size of Hyper3D's extracted standalone PBR member and has 412 nonmanifold edges. For an appearance-led design review, SupaVoxel is my pick; if the actual job is a compact asset to feed into print preparation, use Hyper3D's inspected Gen-1.5 file instead. Nobody tested either clip on a rod.

Eight paired checks for the pictured finish and actual files:

Open jaws and slot — Hyper3D: two open U shapes and central slot · SupaVoxel: the same visible structures.
Purple jaw continuity — Hyper3D: gray exterior patches · SupaVoxel: more continuous purple in matched renders.
Handle-line detail — Hyper3D: rougher line · SupaVoxel: finer line, not a measured fit tolerance.
Embedded textures — Hyper3D: three 2048² PNGs · SupaVoxel: three 4096² PNGs; no measured color-error score.
Standalone hosted file — Hyper3D: 10.72 MB PBR · SupaVoxel: 87.17 MB Original size GLB, different tested export selections.
Welded mesh — Hyper3D: zero nonmanifold edges · SupaVoxel: 412 requiring repair before solid-volume claims.
Website download — Hyper3D: 17.54 MB ZIP · SupaVoxel: 87.17 MB GLB, both actually received.
Unseen back fidelity — Hyper3D: no source back photo · SupaVoxel: no source back photo; both invented it.

A larger map does not mean truer color; the purple gap here is a render observation, not a measured albedo distance.

What can one purple reference photograph tell us?

Hyper3D and SupaVoxel received the same 1,529,736-byte generated image of a purple, slotted clip with two open U-shaped ends. The image supplies an appearance target but not a side, back or internal specification. The open ends are not a dimensioned drilled bore. That matters for interpreting close-ups: if one model makes a plausible unseen underside, there is no ground-truth underside in the source with which to declare it faithful. Our comparison uses matched offline camera angles for the exported textured assets, not a Hyper3D Gen-2.5 video or an interface thumbnail compared against a downloadable Hyper3D Gen-1.5 GLB. We reserve “looks like the pictured clip” for visible features only.

The single identical Hyper3D and SupaVoxel input shows the purple handle slot and two U-shaped jaw openings, without a second angle or physical scale.

Which clip looks ready for the product page?

In the main matched view, Hyper3D Gen-1.5 reconstructs an elongated clip with a central opening and distinct clamp ends. SupaVoxel also preserves those structures. The visible Hyper3D difference is finish: gray or dull bands sit on the outside of Hyper3D's near jaw while the SupaVoxel side is closer to continuous purple. That observation is about textured render appearance, not proof that polygons are absent under the gray paint. The compared Hyper3D model has 120,000 triangles and the SupaVoxel model 1,499,510; that 12.50× face-count difference cannot, by itself, isolate whether texture resolution, material prediction or geometry caused a shaded defect. Hyper3D's one-piece welded mesh is watertight, whereas the dense SupaVoxel mesh is non-solid under the measured topology check. Visual finish and mechanical mesh quality point in opposite directions here.

Hyper3D Gen-1.5 PBR hero render: overall jaws and slot survive, but a gray band crosses the nearer jaw exterior.

SupaVoxel's 1,499,510-face GLB looks more purple than Hyper3D in the matched hero view, but fails the solid-mesh topology check.

What happens when the customer inspects the jaws?

In a hypothetical product-page inspection, turning the clip toward its jaws would reveal what the hero frame hides. In our matched offline end view, the Hyper3D exterior has gray areas on both tips; SupaVoxel carries the purple around those same visible regions. Both keep the actual U openings. I can say SupaVoxel looks more continuous in these renders, but not how much closer its raw pigment is to the source: we measured no unlit albedo ΔE and the camera lighting can alter color. Nor will a prettier jaw close on the real rod by magic. Without the rod diameter and jaw clearance, the closer-looking model is a display favorite, not a functional winner.

At the Hyper3D jaw end, two outside tips show gray areas; this view has no calibrated fit dimensions.

SupaVoxel's matched jaw-end view, against Hyper3D, keeps purple on the exterior, but its 412 nonmanifold edges remain.

Is a finer slot line also a better fit?

The top view shows both open end clamps, the long center slot and the shallow line along the handle in each result. SupaVoxel's line looks tidier; Hyper3D's surface pattern along the slot is rougher and its gray tip patches remain noticeable. The file analysis explains a possible representational difference without establishing a cause: Hyper3D holds 120,000 triangles; SupaVoxel 1,499,510, with average edge lengths after normalization of 0.4156 mm and 0.1157 mm respectively. But none of those averages measures the required gripping gap or the wall thickness at the two spring arms, and the dense asset is still nonmanifold. For a Hyper3D screenshot, the line is visible; for a print decision, measuring the mating geometry matters more.

SupaVoxel's top view, next to Hyper3D, shows two open clamps and the long slot; 0.1157 mm is mean triangle-edge length, not jaw tolerance.

Is the download a ZIP, model or bare mesh?

There are three different Hyper3D sizes worth keeping separate. Its initial geometry-only GLB was 3,971,968 bytes and had no image maps; it is not comparable to a textured SupaVoxel export. After material generation and confirmation, the browser's real download was a 17,543,700-byte ZIP containing a 10,724,844-byte Hyper3D Gen-1.5 PBR GLB and a Shaded variant. The offline topology and texture measurements use the ZIP's PBR member. SupaVoxel's actual browser export was an 87,169,048-byte Original size GLB. Thus “website download” compares ZIP versus GLB, while “standalone hosted PBR asset” compares GLB versus GLB. Using 10.72 MB as the Hyper3D website download would understate transferred bytes; using 17.54 MB to calculate single-GLB hosting would overstate them.

This completed Hyper3D Gen-1.5 PBR download returned a 17.54 MB ZIP; its one inspected PBR member is 10.72 MB.

What did the larger texture maps actually buy?

Both inspected PBR GLBs embed three PNG maps in one material. Hyper3D's maps are each 2048 × 2048, with a 3,018,326-byte baseColor map and 3,734,029 bytes combined normal and metallic/roughness maps. SupaVoxel's three are 4096 × 4096, with 15,634,800 bytes of baseColor and 25,279,748 bytes across the other two. Each larger image has four times as many pixels, not a measured fourfold gain in visible quality. We did not compute albedo ΔE, UV island utilization, seam distortion or same-device perceived resolution. Normal and metallic/roughness maps matter to rendered appearance; a single-color resin slicer ordinarily does not consume them to determine solid material volume. For that specific print workflow, most map bytes are not a substitute for topological repair.

Hyper3D's material preview led to three 2048² PNG maps in the inspected PBR file; color-error and UV occupancy were not measured.

Could another export reverse the file-size result?

SupaVoxel's Export menu offered GLB → Compressed alongside GLB → Original size. We clicked and captured only Original size. That export is the 87,169,048-byte file in this article; the Compressed variant's byte count, reconstruction differences and visual finish were not captured. “Original size” is an interface label: the browser decodes and converts an underlying compressed representation before saving a GLB, so do not mistake this route for an untouched generation-chain master. The downloaded file is still a real browser-exported asset, not a local recreation assembled from separate web resources. This choice is crucial for any bandwidth conclusion. A smaller alternate export might change the transfer ranking or texture appearance; we cannot quantify it without downloading and examining that option.

Only SupaVoxel Original size was measured against Hyper3D's ZIP; SupaVoxel Compressed has no recorded size in this test.

How long would each tested file take on a phone?

For the two actual website downloads—17,543,700-byte Hyper3D ZIP and 87,169,048-byte SupaVoxel GLB—ideal one-transfer minima at 12 Mbps are 11.7 and 58.1 seconds. At 100 Mbps, the minima are 1.4 and 7.0 seconds. This simple calculation excludes connection setup, headers, retries and client decoding. It is not a stopwatch of either website. A separate page embedding only the extracted PBR GLBs would instead transfer 10,724,844 versus 87,169,048 bytes, with 7.15 versus 58.11 seconds of ideal first-load time at 12 Mbps. Mixing the ZIP number into a hosted GLB table, or presenting a theoretical line-rate minimum as an actual observed download, would mislead a reader budgeting mobile data.

This earlier Hyper3D untextured geometry download is not the final ZIP; line-rate estimates must use the correct delivered file.

What happens at ten thousand model loads?

Imagine separately hosting the measured textured GLBs, one asset per page, then serving each in full 10,000 times with no cache. Using decimal GB and $0.085/GB, the source calculations give about $9.12 for Hyper3D's 10.72 MB PBR model and $74.09 for SupaVoxel's 87.17 MB GLB. At 100 copies of each individually hosted file, that's 1.0724844 versus 8.7169048 GB of assets. These Hyper3D and SupaVoxel numbers are scenario inputs, not a real CDN invoice or credits charged by either generation product. Another estimate, geometry-only GPU memory at 32 bytes per vertex plus four bytes per triangle index, gives 3.97 versus 46.25 MB, excluding textures. Smaller Hyper3D assets favor this web-display budget, not necessarily material appearance. Including textures, bytes per triangle are 89.37 for Hyper3D versus 58.13 for SupaVoxel; these are not codec-efficiency scores.

The Hyper3D UI and GLB agree on 120,000 triangles; 3.97 MB here is estimated geometry VRAM, not the PBR file size.

Final verdict: the purple finish wins the photograph, not the slicer

At matching render angles, the SupaVoxel clip reads closer to the visible purple jaw finish and keeps a fine line by the slot. Hyper3D's actual Gen-1.5 PBR has gray exterior patches where I expected purple, although it preserves both open U-shaped jaws and the long opening. For an illustrative appearance-first listing I would show the SupaVoxel render; that is a visual preference, not a physical-use verdict.

SupaVoxel predicts a smoother reverse; the source has no reverse photo to corroborate it.

The price of that appearance in our tested export choices is a real 87.17 MB Original size SupaVoxel browser file against a 17.54 MB Hyper3D browser ZIP containing a 10.72 MB PBR GLB. Hyper3D also wins mesh cleanliness, zero nonmanifold edges to 412; the SupaVoxel file is not a validated solid, so no resin volume may be quoted for it. SupaVoxel's unmeasured Compressed choice might narrow the byte gap, but we cannot assign it a size. If the next stop is a slicer or a bandwidth-limited product viewer, the Hyper3D Gen-1.5 file is the sensible starting point. Visual fidelity to the hidden back and actual rod fit remain unknown on both.

Use SupaVoxel for this job

If you are showing a purple design concept and can review the geometry before manufacturing, SupaVoxel gives you the more continuous purple jaws in these paired renders, a finer slot line and an actual Original size GLB. Inspect its mesh and repair the 412 nonmanifold edges before making functional-print or solid-volume claims. If the client needs a compact, cleaner mesh right away, choose Hyper3D's Gen-1.5 PBR result instead.

How I tested this

The same independently generated 1,529,736-byte PNG went to both applications. Hyper3D Free let me download Gen-1.5 as a ZIP with the 10,724,844-byte measured PBR member; its separate Gen-2.5 run displayed a preview but no Free download. SupaVoxel's measured 87,169,048-byte GLB was captured from its actual Original size browser action, not rebuilt offline. Its offered Compressed choice was not measured. Offline renders used the same lighting and camera numbers; there was no unlit region-specific ΔE, UV-occupancy test or second photo of the back. At 120 mm longest bounding-box side, not height, each downloadable file was parsed and welded across UV seams before topology checks. The 12 Mbps/100 Mbps download seconds and $0.085/GB uncached hosting costs are arithmetic scenarios, not measured user wait or provider fees. We did not measure jaw clearance, rod diameter, arm flexibility, slice success or real print results.

Hyper3D Rodin Credits Review 2026: 0.5 Credits, Then a Paywall

Selin Orlov — Sun, 11 Oct 2026 16:02:25 +0000

Independent test: everything below ran on my own free and paid accounts, and no vendor provided access.

Half a credit vanished on my first attempt at this cat, and I came away with nothing a modeler could use. Hyper3D Gen-2.5's preview showed the ribs clearly, and GLB was selectable. Only when I hit Download did the free account explain that the file required a subscription. So I started over, generated a different Gen-1.5 cat from the same image, and tracked every balance change far more carefully.

That exact image went to SupaVoxel too, and I got its textured GLB back — but SupaVoxel credits aren't Hyper3D credits wearing another typeface. SupaVoxel earns a place here because this case's transaction can be traced to a file I actually downloaded, not because "3" looks cheaper or pricier than "0.5."

My verdict in 60 seconds — don't treat the Hyper3D Gen-2.5 free-account preview as something you can deliver; in this cat test, Gen-1.5 did produce a textured 2K PBR file for an attributable 0.5 Hyper3D credit. The material stages, checked separately, added no observed credit charge. SupaVoxel produced a 4K textured GLB for a matched 3 SupaVoxel credits, with a simpler direct-GLB handoff. For a low-byte static bone cat where Gen-1.5 is acceptable, Hyper3D takes the cost/access win inside its own account. For 4K maps and the 3MF menu route I observed, look into SupaVoxel, but budget for its bigger file and local mesh defects. Without comparable plans, nobody wins on dollars. Eight paired calls follow, with no made-up numeric quality score:

First Hyper3D attempt — Gen-2.5 took 0.5 and refused the free Download · SupaVoxel finished a transaction and handed over a GLB. SupaVoxel sidesteps that preview-only dead end.
Hyper3D route that exported — Gen-1.5 preview first, 0.5 debited on geometry Confirm, PBR ZIP later · SupaVoxel: one 3-credit transaction, textured GLB. Both yielded real files.
Material bookkeeping — Hyper3D Gen-1.5 balance held at 1.0 before, during and after Generate, and before/after Confirm · SupaVoxel showed one −3 debit tied to the request. Records specific to this case.
Texture pixels — Hyper3D three 2K PNGs · SupaVoxel three 4K PNGs. Quadruple the pixels per map is not quadruple the visible fidelity.
First file received — Hyper3D 5.17 MB geometry GLB, 0 images · SupaVoxel 67.38 MB tested Original size GLB, 3 maps. A bare export shouldn't be weighed against a textured one.
What the download really contained — Hyper3D 23.15 MB ZIP holding two GLBs · SupaVoxel 67.38 MB GLB, direct. Fewer bytes for Hyper3D; no unzip step for SupaVoxel on the tested path.
Full time-to-file — not recorded for Hyper3D · not recorded for SupaVoxel. The 49.636-second partial phases and the 260.335-second request lifecycle can't be compared.
Commercial print economics — dollar rate and license not established for Hyper3D · not established for SupaVoxel either. A credit number says nothing about usage rights.

Before Gen-2.5, the free-account Hyper3D header read 2.5 credits; the 0.5 debit that followed belongs to that attempt, not to the Gen-1.5 file I ended up with.

Three routes to one cat

Not three identical paid products but three generation paths: a Hyper3D Gen-2.5 attempt, a Hyper3D Gen-1.5 attempt and a single SupaVoxel run. Each was fed the same 1,702,829-byte illustration of a seated skeleton cat. I confirmed via SHA-256 that the image attached to the SupaVoxel request was the source file. Hyper3D's two paths stored different automatic descriptions and settings, so this is not a controlled comparison where only the version changes.

One cat image, two services. Below, only an actual file counts as a transferable result — never a thumbnail that merely looks familiar.

Gen-2.5: half a credit gone before the Download gate

As the Gen-2.5 preview finished, the free Hyper3D balance went from 2.5 → 2.0 credits — a 0.5-credit debit attributable to this run alone. By the saved task clock the preview took 51.622 seconds, and geometry confirmation another 32.6. The interface listed 1,000,000 faces and 723,700 vertices along with Watertight and Print-Ready labels. Because I never downloaded that Gen-2.5 mesh, those figures are interface claims, not file analysis.

Clicking Download on the selected GLB produced a prompt to subscribe to download Gen-2.5 models, with a note that Gen-1.5 downloads stayed free. By then the 0.5 credit had already been spent. I'm not arguing paid features should cost nothing; the point is the practical cost of discovering the gate after part of a limited trial balance is gone. A freelancer who promised a client the million-face file shown on that screen would still have nothing to hand over on this account's access.

The free-tier refusal came on the real Download click, after the 0.5 debit. None of the Gen-2.5 geometry appears in later comparisons.

Gen-1.5: a free preview, then a half-credit Confirm

Gen-1.5 in Hyper3D started out as a Free Preview. The task clock put the preview at 25.036 seconds; confirming geometry took 24.6 seconds and shifted the balance 2.0 → 1.5. That 0.5 Hyper3D credit charge, verified on its own, sits on the run that later produced the textured PBR file. It neither reversed nor refunded the blocked Gen-2.5 trial; the two half-credit debits total 1.0 across my two experimental routes — not one credit billed for a single Gen-1.5 output.

The Gen-1.5 route began with 2.0 credits remaining after the earlier blocked trial; the geometry charge for this route came on Confirm.

The first Gen-1.5 download had no textures

Once geometry was confirmed, a 5,170,468-byte GLB was available to download. The geometry was genuine, but the file held zero embedded images. A product photographer briefed on a textured bone-cat render would reject an untextured shape just because the export button functioned. For that brief, the fair comparison asset is the later PBR model, which embeds three 2048 × 2048 PNGs.

Hyper3D's first export carried geometry only. This Material panel, reached later, leads to the textured comparison file.

Material Generate and Confirm: no extra debit seen

Within the controlled checks I ran around this cat's material steps, no further half-credit left the account. The balance read 1.0 credits before, during and after Material Generate, and 1.0 on either side of Material Confirm. So those stages added zero observed additional credits to this run. Combined with the isolated 0.5 debit at geometry Confirm, the case record supports 0.5 Hyper3D credit chargeable to this Gen-1.5 PBR file.

One wrinkle I won't bury: an earlier movement on the same account, 1.5 to 1.0, happened before the controlled material sequence and couldn't be linked to this cat. I haven't booked it as a material cost, nor does it prove the account never spent it. That's why I cite the isolated stage checks and the file outcome rather than an all-day balance difference. What results is a per-case ledger I can defend, not a universal tariff for everyone pressing Generate.

The PBR preview of the cat showed up after Material Generate; the isolated 1.0 → 1.0 balance readings show no extra credit in this task window.

What the Download button really delivered

It sent a 23,151,232-byte ZIP — not the standalone 14,181,040-byte PBR GLB that tends to get quoted as "the Hyper3D download." Inside the archive is also an 8,969,940-byte Shaded GLB. Every file, texture and mesh comparison used the PBR member. Host that single extracted GLB yourself and the payload is 14.18 MB; let a teammate press the product's button and 23.15 MB actually moves, second variant included.

Both PBR and Shaded were ticked in the Pack UI, so the transfer counted here bundles two GLBs into one ZIP.

Tracing SupaVoxel's charge without the shared balance

The shared balance couldn't do it: several cases were running on the SupaVoxel account at once, so any before/after change in the header could belong to another model. Instead, the case linked the identical source image to the specific request and then matched a single debit transaction of −3 SupaVoxel credits to it. The Original size GLB that resulted downloaded fine, held three 4096 × 4096 PNGs and weighed 67,377,036 bytes.

For one finished file, that is a tidy accounting chain: request → transaction → output. What I did not capture is the instant the customer-facing UI showed the debit. Nor can three SupaVoxel credits be set against half a Hyper3D credit in dollars; that would need different entitlements and dollar rates. The question that matters for this brief is whether the 4K asset and the menu choices justify the bytes and mesh-editing work, not whether "3" looks like a bigger number.

SupaVoxel's page displayed the 3-credit generation price; this run was verified by a case-specific transaction, not by a swing in a shared balance.

Scaling to one hundred paid deliverables

Dollars are out of reach here. If 100 identical Gen-1.5 PBR runs each repeated this cat's isolated stage charges, the Hyper3D ledger would total 50 Hyper3D credits. If 100 SupaVoxel requests repeated this case's transaction, they'd total 300 SupaVoxel credits. Those two numbers imply no exchange rate between the services. The 0.5-credit Gen-2.5 preview detour is charged once to my experiment; it doesn't multiply across every future Gen-1.5 file.

Shown here is SupaVoxel's measured Original size branch; the Compressed option is visible but has no byte count measured in this case.

Two timers, two different boundaries

Neither timer covers the whole path to a file. Hyper3D's 49.636 seconds sums its Gen-1.5 preview generation and geometry confirmation phases; the material stage wasn't fully timed, and uploads, clicks, packaging and download sit outside the total. SupaVoxel's 260.335 seconds is the request's creation-to-update interval, which includes queue time but leaves out the upload before the request and the export after it. With boundaries this different, subtracting one from the other means nothing.

A generating state in the SupaVoxel UI; the 260.335-second figure covers the request lifecycle, not every minute a user spent getting a file.

Hyper3D's real wins in this matchup

For this cat, Hyper3D's Gen-1.5 PBR file is 14.18 MB extracted and visibly keeps finer ribs along the flank and tinier holes through the tail. After welding, each final mesh is watertight and free of nonmanifold edges, yet Hyper3D has 0 degenerate / 249 sliver faces to SupaVoxel's 19 / 7,217. When the job is a delicate static ornament, those file-health and art-direction wins carry weight. If the buyer will show a modest gallery model instead of cropping into a 4K map, the leaner 2K texture set is a sensible trade too.

Switch to SupaVoxel and what do you give up? About 4.75× the extracted PBR file size in this export comparison, plus more triangle inspection. What comes back? Three 4K rather than 2K maps, finer average mesh sampling, and a menu listing 3MF — though the 3MF output itself went untested. If your pipeline needs those, the trial makes sense. If not, Hyper3D's smaller, cleaner model wins this particular spending decision.

Hyper3D's finer-looking ribs survive in a compact PBR file; a lower polygon count doesn't mean the skeleton detail is gone.

The 4K SupaVoxel cat exports directly but weighs substantially more than the 2K PBR file extracted from Hyper3D.

Final verdict: where my next credits would go

Not into another free-account Gen-2.5 preview in the hope of getting its file. Gen-1.5 produced the actual 2K PBR cat for an attributable 0.5-credit charge on this single run, with no extra material-stage debit seen in controlled checks. SupaVoxel produced a 4K Original size cat for an attributable 3-credit transaction. If I needed 4K inspection or the 3MF workflow on offer, SupaVoxel is what I'd test next; for a lighter static gallery cat, this evidence points me to Hyper3D Gen-1.5. No credit count, on either side, tells me dollar cost, print success or licensing terms.

Which one I would use for this 4K job

When a commission calls for a textured 4K sculpt, or you want to explore a 3MF export, run your cat image through SupaVoxel and check the exact file before you pay for production. In my test the GLB came down directly, carrying the expected three 4K maps and a request debit I could trace. Tell anyone who'll host, edit or slice it about the 67.38 MB Original size footprint and the 7,217 slivers / 19 degenerates. If the smallest measured 2K PBR in this pair is what you need, go with the Hyper3D Gen-1.5 result.

Ledger method and open questions

The same independently generated PNG went into both services: one Gen-2.5 and one Gen-1.5 attempt on Hyper3D, then a single case-identified SupaVoxel run. I captured Hyper3D balances at the specific generation and confirm stages and on both sides of each Gen-1.5 material action; the unrelated earlier 1.5 → 1.0 shift was not charged to this cat. SupaVoxel's single debit was matched to its input-linked request rather than inferred from a shared balance. I did not treat the 49.636-second Hyper3D stage total and the 260.335-second SupaVoxel request interval as a race.

Every MB/GB figure uses decimal bytes; the 12 Mbps scenario is purely a transfer floor. Several things stayed unknown: how paid plans convert credits to dollars, the commercial license, whether trial credit refills, the full time-to-file, the Compressed GLB's size, what a real 3MF file looks like, batch usage terms and repeat reliability.

Hyper3D Wall Hook Review 2026: Watertight Mesh, Missing Hexagons

Selin Orlov — Fri, 09 Oct 2026 15:55:47 +0000

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

I needed a 3D concept of a wall hook, not a generic black bracket. In my picture, a diagonal brace had a row of separate open hexagonal cells. That lattice was the design cue. A customer rotating the model should be able to look through each cell, not at a shadow painted on a solid bar.

I sent one identical image to Hyper3D Rodin and SupaVoxel, got the downloadable versions onto my drive, then looked from the front, the back and with the materials turned off. Hyper3D’s Free-downloadable Gen-1.5 file kept the two plate holes and raised hook but merged the hexagons into one long slot. SupaVoxel retained distinct real through-cuts. Then the topology test flipped the result: Hyper3D’s welded mesh was watertight; SupaVoxel’s had 15 boundary and 42 nonmanifold edges. The prettier match is not a finished printable mount.

My 60-second verdict — SupaVoxel is the closer visual match for this cell-braced hook; Hyper3D is the tidier unrepaired shell. I would use SupaVoxel as the closer digital starting model if the repeated openings are the feature I must show. I would not put either raw generation on a wall: no screw dimensions, print, installation or load test was supplied. If the only question is “which unrepaired shell is watertight,” Hyper3D wins, but its missing ribs fail this visual brief.

Eight paired decision rows — each row records the observation and the practical consequence:

The specified lattice — Hyper3D one long brace slot; SupaVoxel separate open cells — only the second lets a viewer see through the actual repeated design.
Wall plate and hook silhouette — both preserve two holes and a projecting hook — a tie at thumbnail scale, before inspecting the brace.
Downloaded triangle budget — 120,000 vs 984,365 — more sampled geometry accompanied the retained cell divisions in this pair; count alone proves no strength.
Welded boundary edges — 0 vs 15 — SupaVoxel’s beautiful lattice still contains openings outside an approved closed solid.
Welded nonmanifold edges — 0 vs 42 — repair and validation precede any slicer or volume claim.
Face-connected regions — 1 vs 29 — a vertex-only touch does not promise a continuous manufactured part.
Potential downward area — 4,399.9 vs 6,851.6 mm² at normalized longest side 120 mm — orientation-specific geometry, not measured support material.
Measured fastener fit or load — none for either · Hyper3D unscored · SupaVoxel unscored — I will not rate a safety-relevant fixture from pixels.

These rows are not summed: for this visual job the individual openings outweigh the solid-screening rows.

Why was the lattice my first inspection point?

The source PNG shows a dark two-hole wall plate, a projecting curved hook and the row of discrete hexagonal openings across its diagonal brace. I can count holes in a close-up; I cannot safely infer a screw diameter or load rating from a perspective illustration. Both companies received the same 1,529,001-byte file and its fingerprint was checked against SupaVoxel’s saved input. That equal source does not mean their internal cropping, prompts or interpretation matched; Hyper3D’s two generations even displayed different auto-written descriptions. This is a comparison of actual resulting files, not two identical internal pipelines.

The identical test image separates the hexagonal cells; it supplies no fastening tolerances, load specification or publication-rights clearance.

Can you tell the difference at thumbnail size?

Not reliably. Both silhouettes have two plausible mounting holes and an upper lip that reads as a hook. Shrink the renders and I could mistake either for the intended object. But move into the brace: Hyper3D Gen-1.5 runs one continuous opening along it, where SupaVoxel leaves several distinct cells divided by ribs. That is why I do not let a thumbnail make the purchase decision. For a rotating product illustration, the brace is the feature a curious viewer will inspect; losing the ribs changes the design, even though the hook remains recognizable. This observation belongs to the downloadable Gen-1.5 file, not to the locked Gen-2.5 preview.

Hyper3D Gen-1.5 keeps the mounting holes but joins the brace openings into one slot.

SupaVoxel’s actual exported front retains separate apertures rather than a painted suggestion of them.

Is that honeycomb only painted onto the surface?

I checked the opposite view and the untextured geometry. In SupaVoxel’s rear crop, the spaces between ribs let the background show through repeatedly; the gray mesh shows the same distinct cavities with the black finish removed. Hyper3D’s rear keeps the long slot. A normal map can create highlights but cannot turn a single hole into several holes you can see through from the back. To face equivalent sides of the subject in the offline viewer, Hyper3D used a 270-degree yaw adjustment and SupaVoxel used zero; pitch, scale and lighting matched. I compared object-relative views, not numerically identical world yaw. That is a reason to trust the type of opening I see, not an excuse to claim pixel-level similarity.

Hyper3D rear close-up: a single uninterrupted lengthwise brace opening.

SupaVoxel rear close-up: separate holes divided by ribs, visible in downloaded geometry.

Does Hyper3D’s watertight number rescue the lost cells?

No, but it wins another real contest. A raw export can duplicate vertices at UV texture seams; counting those as holes would be misleading. After welding equivalent seam positions, Hyper3D’s PBR GLB yielded one face-edge-connected shell with consistent winding, zero boundary and zero nonmanifold edges. SupaVoxel still yielded 15 boundary edges, 42 nonmanifold edges and 29 face-connected regions. Its vertex-connectivity count was one, because touching at a point joins the graph; that does not join faces along proper edges. If I send the SupaVoxel file to a print pipeline I must repair and recheck it first. If I send the Hyper3D file unchanged, the slicer may have a cleaner mathematical solid but still not my requested lattice.

Hyper3D’s gray welded model passes this static solid check while omitting the brace’s cell separators.

SupaVoxel retains the repeated openings without materials, but its welded mesh remains non-watertight.

What did nearly a million triangles do here?

SupaVoxel’s file had 984,365 triangles and 512,433 exported vertices, versus Hyper3D’s downloadable Gen-1.5 file at 120,000 and 72,216. The extra faces did coincide with genuinely preserved ribs in this one test. They did not buy valid edge incidence. At a synthetic scale where each file’s longest bounding-box side is independently 120 mm, average edge lengths were 0.2963 mm for SupaVoxel and 0.794 mm for Hyper3D. These global averages do not measure minimum rib thickness. A nominal 0.4 mm FDM nozzle gives context for sampling but does not tell me whether any specific rib can print, much less survive a hanging load. More triangles solved the digital visual problem here; they did not solve the manufacturing one.

Hyper3D’s sparser wireframe cannot reveal ribs that are absent from the geometry.

SupaVoxel’s dense wire overlay traces a richer brace but says nothing by itself about its 42 nonmanifold edges.

Could either model take a screw or hold a helmet?

Not on this evidence. At a normalized 120 mm longest side, Hyper3D’s overall bounds are 37.51 × 120 × 70.62 mm while SupaVoxel’s are 86.54 × 120 × 31.41 mm. Those different proportions warn me against treating either apparent plate hole as a standard fastener hole. The input had no center-to-center spacing, screw shank diameter, countersink depth, plate thickness, wall material, hook throat size or design load. A photogenic hook might miss the studs or shear across a brace. I would need a dimensioned design and a real prototype before selecting a fastener or hanging equipment. Even a watertight mesh test cannot simulate load or establish a safe mounting method.

The side silhouette suggests a hook; neither its overall bounds nor this view measure screw clearance.

SupaVoxel’s projection looks like a hook, but no wall contact or physical load was tested.

What can the downward-facing-area calculation tell me?

Only where this exported geometry faces down in one world orientation. With Y as up and a 45-degree downward normal threshold at the synthetic 120 mm scale, Hyper3D has 4,399.9 mm² and SupaVoxel 6,851.6 mm² of potential downward-facing area, 17.10% and 23.12% of their respective total surfaces. That does not count generated supports; orientation, bed contact and slicer settings were never chosen. Hyper3D alone also permits a validated closed-volume calculation: 61.08 cm³, translating to a hypothetical $2.14 of solid-fill resin at $35 per liter before support, waste or failed prints. SupaVoxel’s open and nonmanifold mesh makes its corresponding volume and resin figure unavailable. These calculations let me plan what to measure next, not quote a build.

An overhead view checks visual profile, not bed placement or support volume.

Does Gen-2.5 change the verdict?

Not without an exported file. In this Free-account trial, a Gen-2.5 preview took 48.032 seconds and cost an independently attributed 0.5 Hyper3D credit. After a 25.133-second Confirm, clicking GLB Download produced a subscription requirement, not a file. We then tried Gen-1.5 separately and acquired its PBR output. I cannot borrow Gen-2.5’s promising preview or high-poly dialog number to repair Gen-1.5’s missing cells on paper. Perhaps an accessible different generation would make another mesh; it was not measured here. A buyer on Free should decide using the model they can retrieve, not the one they can orbit only in the web interface.

The Gen-2.5 preview reached a Free-account Download gate; every Hyper3D file number here refers to separate Gen-1.5.

Where Hyper3D genuinely wins

Its exported Gen-1.5 mesh is a cleaner static solid candidate, and its extracted PBR member is only 11.07 MB against SupaVoxel’s 32.49 MB Original-size file. A tightly limited web scene or a mesh-repair-averse prototype designer may value that. The exchange rate is losing the image’s conspicuous rib divisions: zero nonmanifold edges do not bring back missing shape. Hyper3D also has 1,743 sliver faces under the same diagnostic that found 459 in SupaVoxel, a useful reminder that no single health statistic settles every part of a mesh. I would not call its valid volume a successful wall-hook design. What it wins is a prerequisite check, with a visible fidelity concession.

What would I actually hand the illustrator?

For an orbiting visual of this cell-braced hook, I would give them the SupaVoxel GLB and the warning in the same handoff: 15 boundary edges, 42 nonmanifold edges, no verified physical load. That file matches the defining visual feature, so it is worth repairing if physical fabrication is later required. If the brief instead tolerates one long slot and requires an already closed unrepaired mesh, Hyper3D Gen-1.5 is a better starting shell. Neither takes a real screw or holds a helmet until that is measured; this preference is for a digital concept, not installation advice.

Test the one feature your image cannot afford to lose

Run SupaVoxel’s image-to-3D workflow on your own design, then turn its material off and orbit to the back. If your critical negative space still passes light, you have a more useful visual candidate; inspect the exported mesh before trusting it in fabrication. If your workflow is a real wall fixture, redraw the design with dimensions, specify wall and fastener, repair and slice the model and physically test the load. Do not let a 3D generator’s fluent black material turn an untested bracket into a safety claim.

How I checked it, and what I did not check

One checked 1,529,001-byte source PNG; a Hyper3D Gen-1.5 PBR GLB extracted from its browser-delivered ZIP; one actual SupaVoxel Original-size browser-exported GLB; one separate blocked Hyper3D Gen-2.5 trial with no acquired file. Same offline viewer, subject-relative front/back calibration (Hyper3D yaw 270°, SupaVoxel 0°), matched pitch, scale and light. Counts came from file parsing and topology after welding seam duplicates. Longest bounding-box side normalized independently to 120 mm for length, area and hypothetical resin math; this is not an installation size. No actual mesh repair, slicer support, FDM or resin print, hole measurement, screw fit, wall test, load capacity or source-image rights clearance was established.

Also in this series

Hyper3D Wall Hook Pricing Review 2026: Pay Before the Free Download — the two generations and what the separate debits bought.
Hyper3D Wall Hook GLB Review 2026: A Smaller File Loses the Cells — actual website payloads and the cost of preserving holes.

Copilot CLI in Late 2026: The Flags I Actually Use in Scripts

Selin Orlov — Wed, 07 Oct 2026 03:13:48 +0000

Most Copilot CLI guides I find are prompt catalogs: "ask it to write a Terraform module", "ask it to explain a failing workflow". That part is easy. What took me longer was the boring layer underneath: which flags make GitHub Copilot CLI safe to run from a script, what changed in the last few months of releases, and where the sharp edges are.

This is that layer, written against the docs and changelog as of early October 2026 (the repo shipped 1.0.92 on October 5). I run platform tooling for a small team, so my bias is headless use: cron jobs, CI steps, one-off batch fixes. If you mostly use it interactively, the permissions and worktree sections still apply.

One scoping note before the flags: I don't use a terminal agent for everything. When someone needs a marketing page or a quick front end for an internal tool, I hand that to Begin, which builds the site with hosting and sign-in already wired, and I keep Copilot CLI for work inside existing repos.

Install and auth: one thing changed

Install is the same as it has been:

macOS/Linux: brew install copilot-cli or curl -fsSL https://gh.io/copilot-install | bash
Windows: winget install GitHub.Copilot
Anywhere with Node: npm install -g @github/copilot

Each has a prerelease channel (copilot-cli@prerelease, GitHub.Copilot.Prerelease, @github/copilot@prerelease). The docs now say Copilot CLI is available on all Copilot plans. If you get Copilot through an org, an admin still has to enable the CLI policy.

The change that bit me: token lookup order. Older posts say GH_TOKEN wins over GITHUB_TOKEN. The current reference checks COPILOT_GITHUB_TOKEN first, then GH_TOKEN, then GITHUB_TOKEN. On a CI runner that already exports GITHUB_TOKEN for other steps, setting COPILOT_GITHUB_TOKEN keeps the Copilot credential separate. The token is a fine-grained PAT with the "Copilot Requests" permission. By default the CLI redacts the values of GITHUB_TOKEN and COPILOT_GITHUB_TOKEN from its output. For anything else sensitive, there's --secret-env-vars.

The Copilot CLI flags that matter for automation

Here is the short list I keep pinned. All of these come from the current command reference.

Flag	What it does	When I reach for it
`-p`, `--prompt`	Runs one prompt and exits	Every scripted run
`-s`, `--silent`	Prints only the agent response, no usage stats	When stdout feeds another tool
`--output-format=json`	Emits JSONL, one object per line	Logging runs for later inspection
`--allow-all-tools`	Runs tools without confirmation	The reference lists it as required for programmatic use
`--deny-tool=...`	Blocks specific tools or commands	Always, alongside the line above
`--autopilot`	Keeps going until the agent calls `task_complete`	Multi-step fixes
`--max-autopilot-continues=N`	Caps autopilot continuation messages	Every autopilot run
`--plan --mode autopilot`	Plans first, then implements without waiting for approval	Larger changes where I want a plan in the log
`-w`, `--worktree[=NAME]`	Starts the session in an isolated git worktree	Anything that edits code unattended
`--no-ask-user`	Disables the `ask_user` tool	Headless runs, so it never waits on stdin
`--share=PATH`	Writes the session to Markdown after a `-p` run	CI artifacts and review
`--model=auto`	Lets Copilot pick the model	When I don't care which model runs
`--max-ai-credits=N`	Soft cap on AI Credits per response	Cost guardrails on scheduled jobs

A few of those need more than a table cell.

Deny beats allow, even under --allow-all

This is the line in the docs I wish more guides quoted: deny rules always take precedence over allow rules, even when --allow-all is set. That is what makes --allow-all-tools acceptable to me in a script. I grant broadly, then carve out what must never happen.

The pattern syntax is small:

shell(git:*) matches git push, git pull and so on. The :* suffix matches the command stem followed by a space, so it does not match gitea.
shell(git push) matches that exact command.
write(src/*.ts) limits file writes by glob.
url(github.com) scopes URL access.

The reference example is exactly the shape I use: allow all of git, deny push.

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

For multiple rules, pass a quoted, comma-separated list. Malformed patterns are rejected with an error rather than silently ignored, which I appreciate.

--yolo and --allow-all are the same switch (tools + paths + URLs). There is also COPILOT_ALLOW_ALL for harnesses that can only set environment variables. I treat all three as "only inside a container or a throwaway worktree".

Autopilot needs a ceiling

Autopilot (--autopilot, or Shift+Tab interactively) keeps the agent working until it decides the task is done. An older changelog entry says continuations were capped at 5 by default. The current reference lists the default for --max-autopilot-continues as unlimited. I don't rely on either: every autopilot run I script sets the cap explicitly.

One gotcha: --plan cannot be combined with --autopilot. If you want plan-then-execute, the supported form is --plan --mode autopilot. The session starts in plan mode and moves to autopilot once the plan is ready. For harnesses that can't pass flags, the same behavior is behind COPILOT_PLAN_THEN_AUTOPILOT.

Worktrees keep unattended edits off your branch

--worktree used to require experimental mode. It no longer does. It creates or reuses a worktree under <repo>.worktrees/ and starts the session there. A worktreeBaseRef setting decides whether it branches from HEAD (now the default) or the remote default branch. worktreePathTemplate lets you put worktrees somewhere else, with placeholders like {repo} and {branch}.

A script I actually run

This is the skeleton of a nightly "fix the flaky test" job. The prompt varies; the guardrails don't.

#!/usr/bin/env bash
set -euo pipefail

# Fine-grained PAT with the "Copilot Requests" permission.
export COPILOT_GITHUB_TOKEN="${COPILOT_PAT:?missing COPILOT_PAT}"

copilot \
  -p "Read test-results/junit.xml, find the root cause of the failing test, fix it, and run the test suite again. Only edit files under src/ and tests/." \
  --worktree=nightly-flaky-fix \
  --allow-all-tools \
  --deny-tool='shell(git push),shell(rm:*)' \
  --no-ask-user \
  --autopilot \
  --max-autopilot-continues=8 \
  --silent \
  --share=./artifacts/copilot-session.md

Why each piece is there:

--worktree means whatever it does lands on a separate branch I can diff in the morning.
--deny-tool blocks pushes and rm. Because deny wins, --allow-all-tools can't override it.
--no-ask-user stops the run from hanging on a question nobody will answer.
--share gives me the full transcript as a build artifact. Prompt mode exits non-zero if that export fails, so a broken artifact fails the job instead of passing quietly.

If a background shell or subagent outlives the turn, -p honors COPILOT_TASK_WAIT_TIMEOUT_SECONDS, which is worth setting on CI so a stuck process can't hold the runner.

Newer features worth knowing

These weren't in the guides I first learned from:

Scheduling inside a session. /every 1h Run frontend tests and report any failures repeats a prompt. /after runs one once after a delay. Handy for watching a long migration from a session you leave open.
Sandboxing. /sandbox enable restricts what the commands Copilot runs can touch on your filesystem and network. The CLI process itself isn't sandboxed. copilot --cloud runs the whole session remotely in an isolated environment. The per-run --sandbox flag is experimental-only for now.
copilot config. Added in 1.0.92: subcommands to list, read, set and remove settings from the shell, so you can provision settings without opening /settings.
Built-in agents. The default set is now Explore, Task, General purpose, Code review, Research and Rubber duck. The last one is consulted automatically, not picked from /agent.
Usage is shown in AI Credits. /usage reports AI Credits used per session, and --max-ai-credits plus /limits let you cap them.

Things that haven't changed: @path adds a file to the prompt, !cmd runs a shell command without calling the model, /add-dir and /cwd manage directories, and copilot --continue resumes the most recent session. Instructions still load from .github/copilot-instructions.md, .github/instructions/**/*.instructions.md and AGENTS.md. Pass --no-custom-instructions when you want a clean run.

For the full list, copilot help permissions and copilot help environment are faster than searching. The official usage guide is the canonical reference.

Where it still needs care

Approving a tool "for the rest of the session" is broad. The docs say it plainly: approving rm that way lets Copilot delete any file under the current directory without asking again. Interactively, I approve once and only use the session-wide option for harmless commands.
Trusting a folder permanently (option 2 at startup) skips the prompt in every future session from that folder. I only do it for my own repos, never for a fresh clone.
Release pace. The changelog moves fast: five releases between September 22 and October 5. Pin VERSION= in the install script (or the npm version) on CI. Then a default change shows up in a PR, not as a surprise in a nightly job.

FAQ

Is Copilot CLI the same as gh copilot?
No. This guide covers the standalone copilot command from the github/copilot-cli repo. It's an agent that can edit files and run commands. The GitHub CLI (gh) is a separate tool.

Can I use Copilot CLI without a paid plan?
The docs say it's available on all Copilot plans. If you get Copilot through an organization, an admin must also enable the Copilot CLI policy, or you can't use it even with a seat.

How do I run Copilot CLI non-interactively in CI?
Use -p with a prompt, authenticate with COPILOT_GITHUB_TOKEN, and add --allow-all-tools with explicit --deny-tool rules. Add --no-ask-user so it never waits for input, and --silent or --output-format=json for clean output.

How do I stop autopilot from running forever?
Set --max-autopilot-continues every time. The current reference lists its default as unlimited.

Wrapping up

The prompts are the easy part of Copilot CLI. The guardrails are the real work: deny rules, a continuation cap, a worktree, and a transcript you can read later. Get those four in place and headless runs stop being scary.

And when a request turns out to be "we need a whole new site or app" rather than "fix this repo", I don't try to make a terminal agent do it. That goes to Begin, which builds a website, iOS app, Android app or Chrome extension from a prompt.