DEV Community: Ilan Kim

NovelAI V5 upscaling measured: Enhance at 35 and 45 Anlas vs ComfyUI Anima i2i, and how much the style shifts (ΔE)

Ilan Kim — Thu, 01 Oct 2026 04:11:06 +0000

NovelAI's Enhance changed V5 images more than a local Anima i2i pass in ComfyUI did: the mean color difference from the original (ΔE2000) was between 10 and 15 for Enhance, and between 8.7 and 10.4 for Anima i2i even at denoise 0.55. If you only want a bigger image, the standalone Upscale at 1 Anlas stayed closest to the original.

This is for anyone who has hesitated over which route to take when enlarging a V5 image. On 2026-10-01 I prepared three originals with nai-diffusion-5-full, ran them through NAI Enhance 1.5×, Enhance Max and the standalone Upscale, and then ran the same originals through 15 ComfyUI jobs on an RTX 5090. A few terms if NovelAI is new to you: Anlas is NovelAI's generation credit, Enhance is the web UI option that enlarges an image and redraws it, and Anima is the model I run locally in ComfyUI. I usually generate in NovelAI first and move to Anima when I get stuck.

Enhance 1.5× cost 35 Anlas, Max cost 45 Anlas

Even on Opus, NovelAI's top subscription tier, Enhance and Upscale are not free. One of the conditions for free generation is that no other image is used as a base, so feeding in an existing picture takes Anlas off your balance (subscription page checked 2026-10-01).

I ran each action in the web UI and checked the balance after every one. Generating the originals cost 0 Anlas, as in the earlier post. Here is what each action deducted:

Action	Output size (portrait original)	Anlas deducted
Original generation 832×1216, 28 steps	832×1216	0
Standalone Upscale	1664×2432	1
Enhance 1.5×	1280×1856	35
Enhance Max	1467×2144	45

The two portrait images and the one landscape image all cost the same. That is higher than the 30 and 38 written in a community tool. The button in the Enhance window also showed 35 and 45, so look at that number before you click.

Enhance output records a strength 0.5 i2i request

Enhance output PNGs carry the request that produced them. NovelAI hides generation data inside its PNGs (the "stealth metadata" covered further down), and opening it shows the request as it was sent. Both levels were an Img2ImgRequest with strength 0.5, noise 0 and 28 steps. The two levels differed like this:

Item	Enhance 1.5×	Enhance Max
i2i request resolution	1280×1856	832×1216 (original size)
Final output	1280×1856	1467×2144
End of prompt	`-2::upscaled, blurry::,` appended automatically	nothing appended
Seed	new random value every time	new random value every time
Character prompts	carried over from the original	carried over from the original

The i2i request size was the enlarged size for 1.5× and the original size for Max. Max also had upscaled_enhance: true recorded separately, so Max appears to enlarge the image after the i2i pass.

Metadata alone cannot settle the processing order inside the server, so I left that as unverified. Magnitude 2 in the Enhance window is the same value as Strength 0.5.

The seed changes every time you click. Feeding in the same original again gives a different result, so save a result you like right away.

Enhance changed the image more than Anima i2i at 0.55

The reference is the original enlarged to the output size with Lanczos. ΔE2000 looks at color difference, and grayscale SSIM looks at how much of the lines and shapes survive. The values are the range across the three originals:

Method	Scale	Mean ΔE	SSIM	Cost
NAI standalone Upscale	2×	0.85~1.04	0.966~0.981	1 Anlas
ESRGAN (`RealESRGAN_x4plus_anime_6B`)	2×	2.07~2.59	0.904~0.931	0
Anima i2i denoise 0.25	1.5×	4.33~5.72	0.717~0.790	0
Anima i2i denoise 0.40	1.5×	6.29~7.90	0.615~0.700	0
Anima i2i denoise 0.55	1.5×	8.69~10.44	0.555~0.631	0
Anima i2i denoise 0.40	2×	5.38~6.95	0.693~0.765	0
NAI Enhance 1.5×	1.5×	10.63~15.43	0.481~0.606	35 Anlas
NAI Enhance Max	about 1.76×	10.19~14.29	0.498~0.638	45 Anlas

By the numbers, Enhance changed the image the most. Apart from the background image, saturation changed by 0.03 or less. SSIM fell at the same time, so the lines and shapes changed too. The exception is Enhance 1.5× on the background image, where saturation rose by 0.10 and the blue channel by 19.

Cropping the face shows the same order. Upscale is hard to tell apart from the original. Enhance 1.5× redrew the bangs and the eye highlights. Max changed even the eye shape and the irises. Anima i2i 0.40 kept the outlines closer to the original.

The usual community answer is that moving to a local model changes the style because the checkpoint is different. I had taken that on trust and assumed Enhance would be the safe option. Yet Enhance, which uses the same V5 model, changed the image just as much. Even with the same model, an i2i pass changes this much.

In the two-character image, Enhance kept the eye color and Anima changed it

The difference was clearest on the two-character original, which I generated with the prompt split across two character prompt slots. The blue-haired character with glasses has blue eyes in the original. Enhance kept the blue eyes at both levels. Anima i2i turned them green from 0.40 on.

Green is the other character's eye color. The glasses frames also went from black to gold. On the Anima side I used core nodes only, so both characters' attributes were written on a single line.

That line contains only green eyes, not blue eyes. The NAI character slots did not have blue eyes either. This one image cannot tell whether the cause is the single-line prompt or the difference between models.

The Enhance request carried both character slots unchanged. The glasses frames, though, became thick and square, and Max also changed the shape of the mouth. In this one image, the eye color survived and the details were redrawn.

Sign lettering was rewritten by every i2i pass

On the rainy neon street, no i2i pass kept the lettering. Enhance changed the layout and colors of the signs wholesale. Anima i2i 0.40 kept part of the large sign's shape, and at 0.55 that changed as well.

Most of the sign lettering in the original is meaningless characters anyway. It is still a problem if you liked the sign design, and in that case you should use only Upscale or ESRGAN.

Local ComfyUI post-processing on an RTX 5090: 2 to 38 seconds per image, 0 Anlas

The local setup is ComfyUI 0.33.1 on Windows 11, with torch 2.11.0+cu128 and an RTX 5090 32GB. I used core nodes only, with no custom nodes, and queued the 15 jobs one after another through the HTTP API (POST /prompt). Run times per job type were:

Job	Pipeline	Run time
ESRGAN 2×	`UpscaleModelLoader` 4×, then Lanczos to 2× size	1.63~1.66 s
Anima i2i 1.5×	Lanczos 1.5×, then `VAEEncode` and `KSampler` 30 steps	17.77~19.17 s
Anima i2i 2×	Lanczos 2×, then the same i2i	37.73~38.28 s

Anima ran at cfg 4.5 with er_sde and simple. The seed was 20261001, with no artist tags. The first run took 21 seconds because of model loading, so I left it out. The times are for this one GPU.

Anima is the only local model I kept. Its weights are non-commercial, but the images it generates can be used commercially; the Anima README says so. NoobAI-XL, which is on the same PC, prohibits commercial use of its outputs, so I left it out (checked 2026-10-01).

Stealth metadata disappears on a ComfyUI save but survives webp

NovelAI PNGs hide the prompt in the alpha channel, with the settings stored alongside it in the least significant bits. This is what NovelAI's stealth metadata is. I reimplemented the logic of the official reader and read the file at each stage:

Stage	Result
NAI original PNG, Upscale and Enhance output	survives
macOS `sips` PNG re-save	survives (text chunks are lost)
Lossless webp, lossy q90 webp (Pillow, sharp)	survives
ComfyUI `SaveImage` PNG	lost (saved as RGB, no alpha)
JPEG conversion	lost
Half-size resize (one original)	lost (`magic not found`)

If you only convert to webp and upload, the full prompt goes along with it. It read back intact even from a q90 lossy webp.

The original PNG also has the prompt in its Comment and Description text chunks. To hide it, strip both the alpha channel and the text chunks, then read the final file again before uploading to confirm.

One pass through ComfyUI and the NAI metadata is gone. In its place, SaveImage writes the workflow as a prompt chunk. If you need the NAI generation info, keep the original PNG separately.

Choose by how much of the original you want to keep

If you only want to enlarge the image as it is, the NAI standalone Upscale stays closest. If you have a local GPU, ESRGAN also stays around ΔE 2.
If there are several characters and you don't mind the details being redrawn, look at Enhance first. In this round's single two-character image, it kept the eye color. The result is different every time, so save it right away.
To save Anlas, start Anima i2i at denoise 0.25 to 0.40. With several characters, check the result with a crop.
For backgrounds where signs or lettering matter, avoid i2i and use only Upscale or ESRGAN.

All the pictures in this post were made with AI. Images: AI-generated (NovelAI Diffusion V5, ComfyUI Anima; cover image OpenAI Images).

Takeaways

NAI Enhance (35 or 45 Anlas) redrew V5 images more than local Anima i2i at denoise 0.55, while the 1 Anlas standalone Upscale and ESRGAN stayed closest to the original. Every i2i pass rewrote the sign lettering, and a webp conversion keeps the prompt in the stealth metadata, so strip it before you post.

Unverified

The internal processing order of Enhance: I could not confirm it. The metadata only records the request size and the upscaled_enhance value, and it does not show at which stage the server enlarges the image.

Seed-to-seed variance of Enhance results: I did not measure it. There is only one result per setting, so I don't know how much ΔE moves across repeated runs.

Enhance strengths other than Magnitude 2: I did not run them. I used only the default of 2 and did not check the price or the amount of change at other strengths.

Processing time on the NAI side: I did not measure it. A person clicked one image at a time, so all I have is a rough sense of the time, and queue waits were mixed in, so I kept it out of the table.

The Curated model and other local models: out of scope. The originals used only nai-diffusion-5-full, and locally I ran only Anima.

Changelog

Version	Description
1.0	2026-10-01 first version (9 NAI Enhance 1.5×, Max and Upscale runs plus 15 ComfyUI jobs, measuring Anlas, ΔE, SSIM and metadata)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Crack cash payouts: the 8.8% is other-income tax, not a fee — what you receive, May filing, business registration

Ilan Kim — Wed, 30 Sep 2026 08:44:45 +0000

When you convert Crack cash to money, the 8.8% that disappears is not a fee: it is income tax withheld on "other income" (기타소득) under Korea's Income Tax Act, so converting KRW 1,000,000 leaves KRW 912,000 in your bank account. If you have little other income, you can get most of it back by filing Korea's comprehensive income tax return in May.

Crack (크랙) is a Korean AI character-chat platform run by Wrtn (뤼튼); creators earn "cash" there when users spend paid Crackers on their works. I wrote this for creators who are building up cash on Crack. I've worked on payment and settlement code as a backend developer. On 2026-09-30 I saved the original text of Crack's announcement and cash guide, then recomputed the 8.8% from the articles of the Income Tax Act. I also read the Crack cash screen on my own account and the tax calculation in Crack's public web code. This is not tax advice. Your actual tax depends on your own income mix and the facts of your situation.

The 8.8% is withholding tax on other income

Other income (기타소득) is the Korean tax category for irregular income such as lecture fees, and the payer withholds tax before paying you. The 8.8% is exactly what the other-income withholding formula produces. 60% of the payment is deducted as deemed necessary expenses, and the remaining 40% is taxed at 20%. Local income tax of 10% of that is added on top.

Here is the calculation for a KRW 1,000,000 conversion:

Conversion           KRW 1,000,000
Other-income amount = 1,000,000 × (1 − 0.6) = 400,000   Income Tax Act Enforcement Decree Art. 87(1-2)
Income tax          = 400,000 × 20%          =  80,000   Income Tax Act Art. 129(1)6(d)
Local income tax    = 80,000 × 10%           =   8,000   Local Tax Act Art. 103-13(1)
Total KRW 88,000 = 8.8% of the payment, deposit KRW 912,000

In Korean, those citations are 소득세법 시행령 §87 1의2, 소득세법 §129①6라 and 지방세법 §103의13①.

Crack's own documents point the same way. The screen where you register your conversion details carries a personal-data collection notice. As its legal basis it cites Income Tax Act Articles 21, 127, 145 and 164. Article 21 defines other income, and Article 145 sets out how other income is withheld. Article 144, the withholding provision for business income, is not on the list.

The Crack Originals notice is more direct. On payouts to original authors, it says they are "transferred to your account after 8.8% other-income tax withholding" ("기타소득세 8.8% 원천징수 후 계좌로 이체"). The 3.3% that Korean freelancers usually see deducted is business-income withholding. Crack cash is handled differently.

Converting KRW 1,000,000 puts KRW 912,000 in your account

What lands in your account is the conversion amount minus 8.8%. The rate at which cash accrues depends on your work's rating and whether it is registered for Crack Only. Your paid Cracker usage is multiplied by that rate, and the resulting cash arrives on the 1st of the following month.

As an example, I took a work with 100 million paid Crackers used in a month. I picked a large number to reach the range where the deduction actually bites. I assumed all accrued cash is converted at once:

Tier	Accrual rate	Cash earned (KRW)	8.8% withheld (KRW)	Deposit (KRW)
Regular creator, Safety	1.0%	1,000,000	88,000	912,000
Official creator, Unsafety (from 9/1)	1.0%	1,000,000	88,000	912,000
Official creator, Safety	1.5%	1,500,000	132,000	1,368,000
Official creator, Unsafety + Crack Only	2.0%	2,000,000	176,000	1,824,000
Official creator, Safety + Crack Only	2.5%	2,500,000	220,000	2,280,000

Crack Only started on 2026-08-12. Only official creators' works can apply (per the notice as of 2026-09-30). In exchange for publishing a work exclusively on Crack for 18 months, the rate goes up by 1 percentage point. Each series has a cumulative payout cap of KRW 1 billion, counted afresh from September 1.

The conversion screen calculates the same way. In the public web code, the amount you enter is multiplied by a taxRate supplied by the server. Fractions of a won are dropped. The screen shows the requested payout amount (지급 요청 금액) and the tax deduction (세금 공제). Below those come the expected payout amount (예상 지급 금액) and expected payout date (지급 예상일). The guide adds that the tax calculation on the screen is an example.

My account holds 0 cash, so I couldn't bring up that screen myself. When you tap 현금으로 바꾸기 (Convert to cash), you're first told to register your conversion details (전환 정보). The guide says Crack takes some time to verify the registered details.

Cash-out starts at KRW 10,000 and pays on the 10th and 25th of each month

Crack announced a revamp of its payout policy on 2026-07-29. From September 1, cash can be converted to money. The name also changed from Wrtn cash to Crack cash. Exchanging cash for goods in the old cash store ended that day.

The conversion terms are in the Crack cash guide (revision of 2026-09-03):

The minimum request is KRW 10,000, with no cap per request.
There is no conversion fee.
Payouts go out on the 10th and 25th of each month (the next business day if that date is a holiday), and you must apply at least 5 business days before a payout date.
You register your name, resident registration number and a bank account in your own name, and submit copies of your ID and bankbook.
Minors aged 14 or older also submit a guardian consent form, a family relation certificate and the guardian's ID. Their limits are KRW 2,000,000 per request and KRW 10,000,000 per month.

The balance is shown in won, not in cash units. In its Super Week notice, Crack said one Cracker is worth KRW 1. But I found no sentence stating that 1 cash equals KRW 1. The amounts in this post assume 1 cash = KRW 1.

Conversions of KRW 125,000 or less are not taxed under the statute

Under Income Tax Act Art. 84, no tax is imposed when the other-income amount per payment is KRW 50,000 or less. Working backward with the 60% expense deduction, the boundary is a KRW 125,000 conversion. Up to KRW 125,000 the tax is KRW 0; at KRW 200,000, KRW 17,600 is deducted.

However, Crack's documents don't say whether it treats one conversion as one payment under that article. The web code has no branch by amount either; it applies the same rate. The guide only says tax "may be" deducted.

I don't recommend splitting conversions into small pieces to stay under the boundary. Without knowing how Crack counts payments, all you'd get is more requests.

Cash saved over several months is reported in one lump on the payment date

Withholding happens on the day money is actually paid out. If you convert several months of cash at once, it is not split by the month it accrued. The guide says it is reported in a lump sum based on the payout date. It also tells you to keep that in mind when filing your comprehensive income tax return.

So on the payment statement Crack files with the National Tax Service, the amount is grouped under a single payout date. The figures to check in May are your conversion history, not your accrual history. If you note the amount and the deduction for every conversion, reconciling later is easy.

Crack's 8.8% and May income tax: at KRW 3,000,000 of other-income amount or less, you can choose separate taxation

Korea's comprehensive income tax return (종합소득세) for the previous year is filed in May. As long as Crack cash is treated as other income, which path you take depends on your total other-income amount for the year. If your other-income amount is KRW 3,000,000 or less, you can choose separate taxation.

That total also includes other withheld other income, such as lecture fees. Other income that the statute always taxes separately or always combines is left out of it (Income Tax Act Art. 14(3)8(a)).

If Crack is your only such income and the 60% expense deduction applies, the boundary is KRW 7,500,000 of conversions. If your actual expenses exceed 60% and you deduct those instead, the boundary goes up (proviso to Enforcement Decree Art. 87(1-2)).

If you choose separate taxation (분리과세), the withholding is final. If you have no other comprehensive income, you don't need to file in May (Art. 73(1)8). In return, you don't get back the tax already withheld.

If you choose to combine (합산), it is added to your other income and recalculated at the basic progressive rates. I ran the numbers for someone with no income besides Crack. I included only the KRW 1,500,000 basic personal deduction and the KRW 70,000 standard tax credit:

Annual conversions (KRW)	Other-income amount (KRW)	National tax withheld (KRW)	Separate taxation	Tax determined if combined (KRW)	National tax refunded (KRW)	Refund incl. local tax (KRW)
1,000,000	400,000	80,000	Available	0	80,000	88,000
7,500,000	3,000,000	600,000	Available	20,000	580,000	638,000
20,000,000	8,000,000	1,600,000	Not available, must combine	320,000	1,280,000	1,408,000
50,000,000	20,000,000	4,000,000	Not available, must combine	1,445,000	2,555,000	2,810,500

Once that total exceeds KRW 3,000,000, there is no choice. Combining is mandatory and you file by May 31. Even someone who converted KRW 50,000,000 in a year gets a refund if Crack is their only income. Withholding is 20% of the income amount. The tax on a KRW 18,500,000 tax base at the basic rates comes out lower than that.

If you have a salary, combining costs you more from the 24% marginal bracket up

If you have employment income, the other-income amount sits on top of it. Compare the 20% withholding with your marginal rate. I calculated for an employee who converted KRW 10,000,000 in a year, which is an other-income amount of KRW 4,000,000:

Existing tax base (KRW)	Marginal rate	National tax difference if combined (KRW)
10,000,000	6%	Refund 560,000
30,000,000	15%	Refund 200,000
70,000,000	24%	Additional payment 160,000
120,000,000	35%	Additional payment 600,000

If the added amount stays inside the 6% or 15% bracket, combining works in your favor. From the 24% bracket up, combining means paying more. If the added amount crosses a bracket boundary, compare the tax with and without combining. When combining costs more and that eligible total is KRW 3,000,000 or less, ending it with separate taxation is the better choice.

The KRW 4,000,000 in this example is over KRW 3,000,000, so combining is mandatory. This is a simple comparison that leaves out any change in deductions on the employment side.

Creators paid out every month should check the business registration test

Right now Crack handles cash conversions as other income. But the platform doesn't decide the income category. Income Tax Act Art. 19(1)21 does. Income from activity carried on continuously and repeatedly for profit is business income.

Korea's National Tax Service published a tax guide for YouTubers and other new types of business, 유튜버 등 신종업종 사업자 세무안내 (PDF, Korean). It says that even without a matching industry code, doing the activity continuously and repeatedly creates an obligation to register as a business. The test is scale and frequency, not whether you have registered. A creator who gets paid out every month may well meet it.

If it becomes business income, a few things change:

Necessary expenses are no longer a fixed 60%; they come from your books or the official expense rates.
If you create alone, it may qualify as VAT-exempt personal services. The basis is VAT Act Art. 26(1)15 and Enforcement Decree Art. 42.
Under the National Health Insurance dependent rules, business income is counted separately.

Health insurance dependents: KRW 20,000,000 a year; dependent tax deduction: KRW 1,000,000 of income amount

If you're listed as a dependent on a family member's National Health Insurance (피부양자) or claimed as a dependent on their tax return (부양가족), this part may matter more. To stay a health insurance dependent, your total income must be KRW 20,000,000 a year or less. Business income is looked at separately. With no business registration and KRW 5,000,000 a year or less, it is treated as zero.

I couldn't confirm whether other income is counted as gross receipts or as income amount here. If it's counted as income amount, the boundary is KRW 50,000,000 of conversions.

The basic deduction for a dependent requires a total income amount of KRW 1,000,000 or less. With Crack income only, that is KRW 2,500,000 of conversions. Whether amounts taxed separately count toward it is left as unverified.

Finding the withholding record for Crack payouts on Hometax

Hometax (홈택스) is the National Tax Service's e-filing site. Type 원천징수영수증 (withholding receipt) into its integrated search (통합검색) and 14 menus come up. Only one of them is for the person receiving income: 지급명세서(원천징수 내역)등 조회 (payment statement / withholding history lookup), under 나의 소득·연말정산 (my income and year-end settlement). The rest are for companies making payments.

The May return is filed under 세금신고 (tax filing) → 종합소득세 신고 (comprehensive income tax return). If you missed the deadline and only want your refund, there is a separate 종합소득세 기한후 환급신고 (late refund filing for comprehensive income tax) menu. I couldn't confirm when Crack payouts show up on the screen after you log in.

Checklist before you convert your cash

Prepare a copy of your ID and a copy of a bankbook in your own name. Minors need three additional guardian documents.
Verifying conversion details takes time, so register them well ahead of the 5-business-day cutoff before a payout date.
Every time you convert, save the tax deduction and deposit amounts shown on the screen.
Before May of the following year, check the Crack payouts in Hometax's payment statement lookup.
If your eligible other-income amount for the year (Crack included, always-separate items excluded) is KRW 3,000,000 or less, choose whichever of separate taxation or combining works in your favor. If it's more, file a combined return.
If payouts keep coming every month, first ask your tax office or a tax accountant whether it counts as business income.

Takeaways

The 8.8% Crack deducts on cash-out is other-income withholding, not a fee, and if your other income is small, filing in May can get most of it back. Record every conversion, check the payout on Hometax before May, and if you're paid out every month, ask a tax office or accountant whether it is business income.

Unverified

This post is not tax advice. I couldn't confirm the items below from original documents or screens, so they are stated with conditions. The conclusion can change depending on your facts.

Cash-to-won conversion: there is no official statement. There is only a balance shown in won and a notice saying one Cracker is worth KRW 1.
Which item of other income applies: Crack hasn't said. Whether it's Art. 21(1)15 or item 19, the deemed expense is 60% either way, so the 8.8% is the same.
Whether the minimum taxable threshold applies per conversion: not confirmed. The web code applies the same rate regardless of the amount.
Whether it counts as business income: this is a question of fact. I found no industry code or official ruling for AI character creation.
Whether it qualifies as VAT-exempt personal services, and whether the penalty for not registering applies: not confirmed.
Expense rates for tax year 2026: they are published in April 2027. So I did not calculate the tax for the business-income case.
How other income is counted for health insurance dependents: I couldn't confirm whether the basis is gross receipts or income amount.
Whether separately taxed amounts count toward the dependent tax deduction: I couldn't settle it from the statute alone.
When payouts appear on Hometax: unknown, since I didn't see the screen after logging in.
The actual rate on the conversion screen: I couldn't bring the screen up because my account balance is 0. I don't know whether the server's taxRate is 0.088.
How long the first payout takes to arrive: I haven't seen a case from the September payouts.

Changelog

Version	Description
1.0	2026-09-30 First English version, adapted from the Korean original (Crack announcement and cash guide text, Income Tax Act articles cross-checked, conversion math reproduced, Crack cash screen checked)

Cover image: AI-generated (OpenAI Images)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Parsing VRM in Flutter without a package: vrm_dart fails on VRM 1.0 (LateInitializationError), so read the GLB chunks yourself

Ilan Kim — Tue, 22 Sep 2026 08:20:59 +0000

You do not need a package to read VRM metadata in Flutter. A VRM file is a glTF 2.0 GLB: a 12-byte header, then a JSON chunk carrying the model name, author, license, expressions, mesh list and the index of the thumbnail, then a BIN chunk carrying the thumbnail bytes. The one Dart library that exists, gatari/vrm_dart, throws LateInitializationError on every VRM 1.0 file and, on VRM 0.x, returns a null thumbnail unless the image happens to be named "Thumbnail". The parser I ended up with is 101 lines of dart:convert and dart:typed_data and reads all of it on both versions.

This is a full rewrite of a post I wrote in December 2024. It is for anyone who needs to show a VRM model's name, author and thumbnail inside a Flutter app. On 2026-09-22, on macOS Apple Silicon with Flutter 3.47.2 and Dart 3.13.2, I ran vrm_dart and a hand-written parser against five sample files, then dropped the parser into a Flutter package and ran flutter test.

The problem

Feed a VRM 1.0 file to vrm_dart exactly the way the 2024 post did. parse() returns, and the first access to the metadata throws:

== Seed-san.vrm (10917800 B)
parse(): ok
vrmMeta access: LateError: LateInitializationError: Field 'vrmMeta' has not been initialized.
thumbnailByteData: null

The 2024 situation was this. The project had a Unity viewport and a Flutter UI, and the model list screen lived on the Flutter side, so the Flutter side had to read VRM metadata on its own. Unity has UniVRM and Unreal has VRM4U; Flutter had nothing. What I found was gatari/vrm_dart, a repository never published to pub. I copied two files into the project, and these three lines got me the thumbnail and part of the metadata:

final vrmByteData = await File(path).readAsBytes();
final vrmParser = VrmFileParser(ByteData.sublistView(Uint8List.fromList(vrmByteData)));
vrmParser.parse();

The post ended with the regret that BlendShapeGroup and the mesh list were out of reach. Since then the ground has moved. VRoid Studio exports VRM 1.0 from v1.20.0, released 2023-03 (checked 2026-09-22), so 1.0 files are now common. vrm_dart has had no commits since 2021-10-13, and a pub.dev search for vrm still returns zero VRM packages.

VRM 0.x files trip it up in two more ways. A file with no images at all, like the add-on test fixture minimal.vrm, dies inside parse():

== minimal.vrm (4660 B)
parse(): _TypeError: type 'Null' is not a subtype of type 'List<dynamic>' in type cast

And a 0.x file that does have a thumbnail still comes back with thumbnailByteData null when the image is not named "Thumbnail", even though the metadata's texture field points straight at it.

What the measurements show

vrm_dart only ever looks at the extension named VRM. VRM 1.0 stores everything under VRMC_vrm, with a different metadata schema and different names for the main fields: title became name, author became authors, licenseName became licenseUrl, and the thumbnail moved from texture to thumbnailImage. With no branch for that, the late field vrmMeta is never assigned, and the first read throws.

Start with the file structure. A VRM is a GLB, the binary container for glTF 2.0. The first 12 bytes are the header: the magic glTF, version 2 and the total length, each a little-endian uint32. Chunks follow. Each chunk is a length and a type, 4 bytes each, then the payload. The standard chunk types are JSON and BIN; unknown types are skipped. All five sample files had chunk lengths that were multiples of 4. minimal.vrm has a single JSON chunk and no BIN chunk at all.

The VRM data lives under extensions in the JSON chunk, and that is where 0.x and 1.0 diverge:

Item	VRM 0.x	VRM 1.0
Extension name	`VRM`	`VRMC_vrm`
Model name	`meta.title`	`meta.name`
Author	`meta.author`	`meta.authors` (array)
License	`meta.licenseName`	`meta.licenseUrl`
Thumbnail	`meta.texture` = index into `textures[]`	`meta.thumbnailImage` = index into `images[]`
Expressions	`blendShapeMaster.blendShapeGroups[]`	`expressions.preset` / `expressions.custom`
Meshes	`meshes[]` (plain glTF)	`meshes[]` (plain glTF)

The thumbnail path is the sharpest difference. The 0.x schema defines texture as "Thumbnail of VRM model", and because it is a texture index you go through textures[i].source before you reach images[]. The 1.0 schema defines thumbnailImage as "The index to the thumbnail image of the model in gltf.images" (checked 2026-09-22). In 1.0, name, authors and licenseUrl are required.

vrm_dart takes neither path. It searches the images array for an entry named "Thumbnail", so any other name is a miss, and it never reads thumbnailImage at all. The third problem is casting: the generated code casts images and bufferViews to non-null lists, which is where _TypeError comes from on a file that has neither key.

I compared the two parsers on five samples. For 0.x, the CC0 add-on test fixtures minimal.vrm and triangle.vrm. There is no public 0.x sample with a thumbnail, so I built two with Blender 5.2.2 LTS and VRM add-on 4.7.1, attaching a 64×64 PNG to triangle.vrm: one with the image named "Thumbnail", one named "swas_thumb". For 1.0, VirtualCast's Seed-san.vrm.

Sample	Version	vrm_dart meta	vrm_dart thumbnail	Direct parser
minimal.vrm	0.x	`_TypeError`	`_TypeError`	meta, 17 expressions
triangle.vrm	0.x	`_TypeError`	`_TypeError`	meta, 17 expressions, 1 mesh
triangle-thumb-Thumbnail.vrm	0.x	OK	317 B	meta, thumbnail, 17 expressions, 1 mesh
triangle-thumb-swas_thumb.vrm	0.x	OK	null	meta, thumbnail, 17 expressions, 1 mesh
Seed-san.vrm	1.0	`LateInitializationError`	null	meta, thumbnail, 18 expressions, 5 meshes

vrm_dart reads exactly one row completely: the 0.x file whose image is named "Thumbnail". That is presumably the kind of file the 2024 post happened to succeed on. The direct parser reads all five. Seed-san's thumbnail came out as a 512×512 PNG of 192,765 bytes, and its meshes are hair, hair_tail, head, robo_arm and wear.

Expression names changed between versions too. The 1.0 spec's expressions document lists the renames (checked 2026-09-22), and the 17 names in the 0.x samples and 18 in the 1.0 sample match this table:

VRM 0.x	VRM 1.0	Note
joy	happy	renamed
sorrow	sad	renamed
fun	relaxed	renamed
a, i, u, e, o	aa, ih, ou, ee, oh	lip sync
blink_l, blink_r	blinkLeft, blinkRight	spelling
lookup, lookdown, lookleft, lookright	lookUp, lookDown, lookLeft, lookRight	spelling
none	surprised	new in 1.0

What to do

Read the GLB header and chunks. ByteData from dart:typed_data is enough, and the JSON chunk goes through utf8.decode then jsonDecode:

   final d = ByteData.sublistView(bytes);
   if (d.getUint32(0, Endian.little) != 0x46546C67) throw const FormatException('not a GLB');
   final length = d.getUint32(8, Endian.little);
   Map<String, dynamic>? json; Uint8List? bin;
   var off = 12;
   while (off + 8 <= length) {
     final len = d.getUint32(off, Endian.little);
     final type = d.getUint32(off + 4, Endian.little);
     final data = Uint8List.sublistView(bytes, off + 8, off + 8 + len);
     if (type == 0x4E4F534A) json = jsonDecode(utf8.decode(data)); // 'JSON'
     if (type == 0x004E4942) bin = data; // 'BIN'
     off = (off + 8 + len + 3) & ~3;
   }
   final root = json ?? (throw const FormatException('no JSON chunk'));

Tell the versions apart from extensions. VRMC_vrm present means 1.0, VRM means 0.x, and neither means it is a plain glTF, not a VRM:

   final ext = (root['extensions'] as Map<String, dynamic>?) ?? const <String, dynamic>{};
   final is10 = ext.containsKey('VRMC_vrm');
   if (!is10 && !ext.containsKey('VRM')) {
     throw const FormatException('glTF but neither VRM (0.x) nor VRMC_vrm (1.0) extension');
   }
   final v = (is10 ? ext['VRMC_vrm'] : ext['VRM']) as Map<String, dynamic>;
   final meta = v['meta'] as Map<String, dynamic>;

Read the metadata with the version's field names: title, author and licenseName for 0.x; name, authors and licenseUrl for 1.0. If a 1.0 file's creditNotation is required, the specification obliges whoever uses the model to display its credit. It does not say where or in what form, so that part is your app's decision.
Resolve the thumbnail along the two separate paths. The image bytes are a slice of the BIN chunk given by byteOffset and byteLength of bufferViews[i]:

   Uint8List bufferView(int i) {
     final bv = (root['bufferViews'] as List)[i];
     final o = (bv['byteOffset'] ?? 0) as int;
     return Uint8List.sublistView(bin!, o, o + (bv['byteLength'] as int));
   }
   int? imageIndex;
   if (is10) {
     imageIndex = meta['thumbnailImage'] as int?;
   } else if (meta['texture'] is int && meta['texture'] >= 0) {
     imageIndex = (root['textures'] as List)[meta['texture']]['source'] as int?;
   }
   final image = imageIndex == null ? null : (root['images'] as List)[imageIndex];
   final thumbnail = image?['bufferView'] == null ? null : bufferView(image['bufferView'] as int);

Walk expressions and meshes with the right keys. On 0.x it is presetName and name inside blendShapeMaster.blendShapeGroups; on 1.0 it is the keys of expressions.preset and expressions.custom. Meshes are plain glTF: name and primitives.length from meshes[].
Keep dart:io out of the parser when it goes into a Flutter package. Take a single Uint8List, so a file path, rootBundle and file_picker bytes all go through the same function. I put it into a flutter create --template=package project this way; all 4 tests passed and the dependency count added is zero.
Treat image-less files as normal. images and bufferViews may be absent, and the BIN chunk may be absent too. The code above lets all of that fall through as null.

The Blender side of this is written up separately in Blender 5.x and the VRM add-on: 5.2 LTS needs 4.4.0+, 5.3 alpha blocks even 4.7.1. The 0.x thumbnail samples in this post were built with that post's setup.

Images: both are the measurement logs (evidence/parse-glb.log and evidence/vrm-dart-legacy.log) redrawn as a table and a console view. The 1.0 sample is Seed-san by VirtualCast, Inc., under the VRM Public License 1.0.

Takeaways

Skip the package search: the VRM metadata you want is one JSON chunk behind a 12-byte header, and the only real work is branching on VRM versus VRMC_vrm. If you must keep vrm_dart, know that it only works on 0.x files whose thumbnail image is literally named "Thumbnail".

Unverified

Whether 0.x files exported by VRoid Studio or UniVRM actually name the thumbnail image "Thumbnail": the file the 2024 post read no longer exists, and this post's 0.x thumbnail samples were made with the Blender add-on.
The dart:io-free parser on mobile and web Flutter, fed through rootBundle or file_picker: I only ran flutter test on the host VM.
Malformed files whose JSON chunk is not padded to 4 bytes: all five samples were multiples of 4. The code rounds the next chunk offset up to a multiple of 4, but I did not test such a file.

Changelog

Version	Description
1.0	2024-12-03 original Korean post (partial VRM 0.x meta and thumbnail via vrm_dart)
2.0	2026-09-22 full rewrite (vrm_dart reproduced on Dart 3.13.2, zero-dependency direct parser measured on 5 samples across 0.x and 1.0, 4 flutter tests)
2.2	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Blender 5.x and the VRM add-on: 5.2 LTS needs 4.4.0+, 5.3 alpha blocks even 4.7.1 (blender_version_max is exclusive)

Ilan Kim — Tue, 22 Sep 2026 06:45:52 +0000

On Blender 5.2 LTS, VRM Addon for Blender only enables from 4.4.0 up, and on 5.3 alpha even the latest 4.7.1 refuses to enable. The cause is blender_version_max in the extension manifest, which is an exclusive bound: it names the first Blender version the extension does not support, not the last one it does. For 4.3.0 and newer, every combination the manifest gate blocks still enables through the legacy add-on zip, which has no version gate at all. The 3.9.0 line is the exception: it fails on both paths, because Blender 5.0 removed an API it imports.

This is for anyone who upgraded to Blender 5.x and found the VRM add-on missing from the panel or refusing to switch on. On 2026-09-22, on macOS Apple Silicon, I installed four add-on versions into four Blender versions two different ways and ran all 32 cells headless. The Blender builds were 5.0.1, 5.1.2, 5.2.2 LTS and 5.3.0 alpha; the add-on versions were 3.9.0, 4.3.0, 4.4.0 and 4.7.1.

The problem

Drop the 4.3.0 extension zip into Blender 5.2.2 LTS. The install reports success, and then the add-on never turns on. The console has the reason:

ERROR vrm: This Blender version (5.2.2) must be less than the maximum version (5.2.0)
Package was expected to be installed but not found: vrm

On 5.3.0 alpha the latest 4.7.1 hits the same wall, with only the version in parentheses changing to (5.3.0). Inside the app it is quieter than that: the Extensions panel shows no error, because the VRM entry is not listed at all.

Since Blender 4.2, add-ons ship as extensions, and an extension zip carries a blender_manifest.toml at its root declaring blender_version_min and blender_version_max. When those values do not match the running Blender, the files unpack fine and activation is refused.

VRM Addon for Blender publishes two zips per release:

Extension: VRM_Addon_for_Blender-Extension-4_7_1.zip
Legacy add-on: VRM_Addon_for_Blender-4_7_1.zip

The two behave differently on 5.x, and that difference is the point of this post.

What the measurements show

blender_version_max is not the last supported version. It is the first unsupported one. The manifest example in the Blender manual says so outright (checked 2026-09-22):

# Optional: Blender version that the extension does not support, earlier versions are supported.
blender_version_max = "5.1.0"

The wording of the runtime error, must be less than, means the same thing.

So 4.3.0 declaring blender_version_max = "5.2.0" is a statement that it supports up to 5.1.x. From 5.2.0 onward it is blocked whatever the patch number. The latest 4.7.1 declares 5.3.0, which covers 5.2 LTS and stops short of 5.3 alpha.

I downloaded the manifest from all 71 release tags to find the boundaries. blender_version_min is 4.2.0 on every tag. Only blender_version_max ever moved, and it moved four times:

`blender_version_max`	Add-on range	First tag	Blender it enables on
5.0.0	v3.9.0 – v3.15.0	2025-07-19	4.2 – 4.5
5.1.0	v3.16.0 – v3.21.1	2025-11-08	4.2 – 5.0
5.2.0	v3.22.0 – v4.3.3	2026-03-16	4.2 – 5.1
5.3.0	v4.4.0 – v4.7.1	2026-07-11	4.2 – 5.2 LTS

Sampling only the x.y.0 tags gets the boundaries wrong. Looking at v4.0.0 alone hid the entire 5.1.0 group of 22 tags. The "5.2 LTS needs 4.4.0 or newer" conclusion comes out of this table.

Then I checked what actually enables, across 32 cells. Each cell got a fresh BLENDER_USER_RESOURCES directory so it could not inherit state from a previous cell or from my own Blender config. O means the add-on enabled and the roundtrip passed, where the roundtrip is importing a VRM file, exporting it, and importing the export again, for both a VRM 0.x and a VRM 1.0 sample.

Extension install:

Add-on \ Blender	5.0.1	5.1.2	5.2.2 LTS	5.3.0 alpha
3.9.0	X	X	X	X
4.3.0	O	O	X	X
4.4.0	O	O	O	X
4.7.1	O	O	O	X

Legacy add-on install:

Add-on \ Blender	5.0.1	5.1.2	5.2.2 LTS	5.3.0 alpha
3.9.0	X	X	X	X
4.3.0	O	O	O	O
4.4.0	O	O	O	O
4.7.1	O	O	O	O

The legacy path has no version gate. 4.3.0 enabled on 5.2.2 and on 5.3.0 alpha and passed the roundtrip in both. That means the direct cause of the extension being refused on the spot is the manifest gate. It does not mean those combinations are free of other API incompatibilities — this run only went as far as activation plus a two-file roundtrip.

Of the four versions I tested, only the 3.9.0 line fails to activate at all. Install it the legacy way and it still raises during module load:

ImportError: cannot import name 'ShaderNodeTexPointDensity' from 'bpy.types' (unknown location)
This add-on is not compatible with Blender version 5.0 or later. Your current version is 5.2.2.

Blender 5.0 removed bpy.types.ShaderNodeTexPointDensity, 3.9.0 imports that type at module load, and the add-on carries its own guard that prints the second line. There is no install path that makes this combination work.

The silence in the Extensions panel has its own explanation. The panel queries the extensions.blender.org API filtered by Blender version, and the filtering happens server side. Ask with blender_version=5.2.2 and you get vrm 4.7.1 back; ask with 5.3.0 and there is no vrm entry in the response at all (checked 2026-09-22). The panel is not hiding an error, it is being handed an empty result.

The roundtrip passed in all 20 cells that enabled. Two samples were used: minimal.vrm for VRM 0.x, which is CC0, and VirtualCast's Seed-san.vrm for VRM 1.0, licensed under the VRM Public License 1.0. Exporting Seed-san grows it from 10,917,800 bytes to somewhere between 16,549,208 and 16,551,476 bytes — the exact figure varies slightly per combination, and all of them land near 152% of the original. I did not investigate why it grows. Whether it is related to the texture duplication issue #1114 is a separate question I have not answered.

What to do

Check your Blender version first. On 5.2 LTS you need add-on 4.4.0 or newer. On 5.0 and 5.1 the latest 4.7.1 enables fine. If you are pinned to an older add-on, read the right-hand column of the boundary table above.
If VRM is missing from the Extensions panel, grab the extension zip from the GitHub releases directly — VRM_Addon_for_Blender-Extension-<version>.zip — and use Install from Disk. The panel only ever offers the single latest version.
If the extension is refused with must be less than the maximum version, the legacy zip is a way through. Install VRM_Addon_for_Blender-<version>.zip from the same release as an add-on rather than an extension. It is also the only way to run 4.7.1 on 5.3 alpha. Be aware that this puts you outside the range the maintainer declares support for; if something breaks, moving the add-on to a version inside the supported range is the first thing to try.
The top-level folder name inside the legacy zip changes between versions. 3.9.0 unpacks to VRM_Addon_for_Blender-3_9_0, and the 4.x releases unpack to VRM_Addon_for_Blender-release. If you are enabling it from a script, discover the module with addon_utils.modules() rather than hardcoding the name.
Give up on the 3.9.0 line under 5.x. ShaderNodeTexPointDensity is gone and no install path gets around it.
If you took the legacy route, export a VRM and import it back. That roundtrip is as far as this measurement went.

Reading VRM files from a Flutter app rather than Blender is written up separately in Parsing VRM in Flutter without a package. The VRM 0.x thumbnail samples in that post were built with the 5.2.2 LTS and 4.7.1 combination from this one.

Images: both are the measurement logs (evidence/matrix-install.log) redrawn as a table and a console view.

Takeaways

Read blender_version_max as the first version that is excluded, and pick the add-on from the boundary table rather than from the panel. The legacy zip bypasses the gate, but bypassing a declared support range is a workaround, not a fix.

Unverified

Whether combinations enabled via the legacy bypass are fully functional: only the roundtrip was checked. Spring bones and the expression editing panels were not.
Windows and Linux behaviour: this ran on a single macOS Apple Silicon machine. The manifest gate is platform independent, but I could not confirm that 3.9.0 raises the same message elsewhere.
When the add-on will support Blender 5.3 after its stable release: these numbers are from 5.3.0 alpha. If blender_version_max moves to 5.4.0, the 5.3 column changes.

Changelog

Version	Description
1.0	2026-09-22 first version (Blender 5.0.1 – 5.3.0 alpha x add-on 3.9.0 – 4.7.1, 32 cells across extension and legacy installs)
1.2	2026-09-22 added the cross-link to the Flutter VRM parsing post
1.3	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Calling the NovelAI V5 API directly: nai-diffusion-5-full request body, params_version 4/3/1/0 identical, missing v4_prompt is a 500

Ilan Kim — Mon, 14 Sep 2026 01:09:22 +0000

nai-diffusion-5-full takes the same body skeleton V4 took, posted to https://image.novelai.net/ai/generate-image, and params_version — the one field every third-party tool fills in differently — returns a pixel-for-pixel identical image whether you send 4, 3, 1, or 0 with this body skeleton. JSON and multipart bodies gave the same result too. What does break it: drop either v4_prompt or v4_negative_prompt and you get 500 Internal Server Error rather than a 400, set Content-Type by hand on a FormData body and you get a missing multipart boundary 400, and post to the old host and you get a model must be a valid enum value 400.

This is for people calling NovelAI V5 from their own scripts rather than through a ComfyUI node or a GUI like NAIA (a community-built desktop front end for NovelAI). On 2026-09-14, on macOS 26.5.2 with Node v22.22.3 and an Opus account (tier: 3), I generated six images inside the free band and compared request formats, error responses, and balance changes; I also read the strings out of the official web client bundle the same day. Two terms if NovelAI is new to you: Anlas is NovelAI's generation credit, and Opus is the top subscription tier, which generates one image at a time at the common sizes and up to 28 steps without spending any, as long as no base image is involved and the allowance has not run out. The policy and the per-size cost table are in the earlier post, the measurements through a ComfyUI node are in the one after it, and this post covers only the request contract.

The problem

If you look at third-party tools' request bodies to work out how to call V5 yourself, the params_version value is different in every one of them. ComfyUI_NAIDGenerator, a ComfyUI node for NovelAI, sends 1. The README of ComfyUI_RS_NAI_API_Request, another ComfyUI node, says "V5 requests use params_version: 4 while older models keep params_version: 3". The changelog of NAIWeaver, a standalone NovelAI client, says "send params_version: 4" (all checked 2026-09-14). The official OpenAPI document has no required array and no nai-diffusion-5 string, so it cannot settle which one is right.

From there, nudging the body around gets you three responses. All three are verbatim from this round of testing:

POST https://api.novelai.net/ai/generate-image  (old host)
400 {"statusCode":400,"message":"model must be a valid enum value"}

POST https://image.novelai.net/ai/generate-image  (v4_prompt or v4_negative_prompt omitted)
500 {"statusCode":500,"message":"Internal Server Error"}

POST https://image.novelai.net/ai/generate-image  (FormData + Content-Type: multipart/form-data set by hand)
400 {"statusCode":400,"message":"missing multipart boundary"}

The first one has different wording from the "update to the image URL" 400 the balance lookup returns. The old host accepts the generation request itself but does not know the V5 model ID, so from the message alone it looks like you typed the model ID wrong.

The second is the confusing one. It is a 500 rather than a 400-class validation error, so it reads like a server outage, but the cause is your request body. The third one appears when you hand Node's fetch a FormData body and set the header yourself, because the boundary undici would have attached automatically disappears.

What the measurements show

params_version does not change the result with this body skeleton. Same prompt, seed 1234567890, 832×1216, 28 steps, one image per value:

`params_version`	Response	Response time	PNG `Source`	Anlas
4 (official web client)	200	2.5 s	`NovelAI Diffusion V5 0ADF9AB7`	9,930 → 9,930
3 (the value said to be for older models)	200	1.8 s	same	no change
1 (ComfyUI_NAIDGenerator)	200	1.9 s	same	no change
0 (a value no tool uses)	200	1.8 s	same	no change

Comparing the four images pixel by pixel with Pillow gives a mean absolute difference of 0 and 0% of pixels changed, so they are completely identical. The Comment metadata of the returned PNGs has no params_version field either. If the value were read and acted on, 0 should at least have been rejected, so with this skeleton it has to be treated as ignored. Whether that also holds for other field combinations — character prompts, inpainting and so on — I did not check.

So where does 4 come from? In the novelai.net bundle I pulled on 2026-09-14 (_app-b7172cc1a6a0b340.js), the default parameters in the nai-diffusion-5-full branch start with params_version:4, and there is migration code that raises stored settings to 4 if params_version<4. The string v5_prompt appears 0 times; v4_prompt appears twice.

The transport format makes no difference to the result either. Sending the params_version: 1 body as JSON and sending it as a JSON blob in the request part of a FormData both returned 200 with identical pixels. The debug toggle text in that same bundle describes the default as "Image generation requests will be sent as multipart form data." and the checked state as "JSON (pre-multipart-form format)", so multipart is the official client's default and JSON survives as the legacy format.

Transport	`Content-Type` handling	Response
JSON	`application/json` set explicitly	200, 917,294-byte zip
multipart	header not set (automatic boundary)	200, pixels identical to JSON
multipart	`multipart/form-data` set by hand	400 `missing multipart boundary`

You cannot leave out v4_prompt or v4_negative_prompt. With everything else left alone, a body with both keys removed, a body with only v4_prompt removed, and a body with only v4_negative_prompt removed all came back with the same 500, and none of them moved the balance. Together with the absence of v5_prompt in the bundle, I take this to mean V5 still requires the V4 structure as it is.

Authentication errors all arrive lumped into a single 401. Leave the Authorization header out entirely, or put a space inside the token value, and the response is the same 401 {"statusCode":401,"message":"Unauthorized"} either way. Since the response cannot tell you whether the token string is mangled or the header is missing, don't print the value: check its length and whether it is unchanged by trim().

For the free band, this adds the landscape size to the table in the earlier post. 1216×832 (pixel product 1,011,712) at 28 steps, one image, was also 0 Anlas, and across six generations usage.percent did not move from 87. The battery reading is an integer, which means per-image consumption below 1% is invisible in it.

I did not find an API that quotes the price up front this time. POST /ai/generate-image/request-price, which appears in the web bundle, returned 404 page not found on image.novelai.net and 404 Cannot POST /ai/generate-image/request-price on api.novelai.net. The web UI does show an estimated Anlas cost on the generate button, but I could not get the same number out of this path, and whether another path exists I could not confirm.

What to do

Use one host, https://image.novelai.net. Generation (/ai/generate-image) and balance lookup (/user/subscription) are both on it, while api.novelai.net rejects generation with model must be a valid enum value and lookups with "update to the image URL".
Use the body below as it stands. This JSON is the full body that returned 200 in the params_version: 4 row of the table above, and the prompt goes in the same string in three places: top-level input, parameters.prompt, and v4_prompt.caption.base_caption. Use 4 for params_version to match the official web client, but don't read any meaning into the value:

{
  "input": "1girl, solo, silver hair, school uniform, looking at viewer, upper body, simple background, masterpiece, best quality",
  "model": "nai-diffusion-5-full",
  "action": "generate",
  "parameters": {
    "params_version": 4,
    "width": 832, "height": 1216, "scale": 5, "sampler": "k_euler_ancestral", "steps": 28,
    "seed": 1234567890, "n_samples": 1, "ucPreset": 3, "qualityToggle": false,
    "sm": false, "sm_dyn": false, "dynamic_thresholding": false, "controlnet_strength": 1,
    "legacy": false, "add_original_image": false, "cfg_rescale": 0, "noise_schedule": "karras",
    "legacy_v3_extend": false, "uncond_scale": 1, "negative_prompt": "",
    "prompt": "1girl, solo, silver hair, school uniform, looking at viewer, upper body, simple background, masterpiece, best quality",
    "reference_image_multiple": [], "reference_information_extracted_multiple": [], "reference_strength_multiple": [],
    "extra_noise_seed": 1234567890,
    "v4_prompt": { "use_coords": false, "use_order": false, "caption": { "base_caption": "1girl, solo, silver hair, school uniform, looking at viewer, upper body, simple background, masterpiece, best quality", "char_captions": [] } },
    "v4_negative_prompt": { "use_coords": false, "use_order": false, "caption": { "base_caption": "", "char_captions": [] } }
  }
}

Save that JSON as body.json, put the file below in the same folder, and it runs as is. The key file is a text file with a pst- token on the line after a line labeled "novelai", and the token stays in memory only. Running it with node nai-v5-direct.mjs <key file> got me a 200 and an image_0.png whose pixels match the table above:

// node nai-v5-direct.mjs <key file> — the key file has a pst- token on the line after the "novelai" label
import { readFile, writeFile } from 'node:fs/promises';

const lines = (await readFile(process.argv[2], 'utf8')).split(/\r?\n/).map((l) => l.trim());
const token = lines[lines.findIndex((l) => /novelai/i.test(l)) + 1];
const body = JSON.parse(await readFile('body.json', 'utf8'));

const r = await fetch('https://image.novelai.net/ai/generate-image', {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
  body: JSON.stringify(body),
});
console.log(r.status, r.headers.get('content-type'));
if (r.ok) await writeFile('out.zip', Buffer.from(await r.arrayBuffer())); // image_0.png is inside
else console.log(await r.text());

For transport, set Content-Type: application/json explicitly if you send JSON, and do not set a Content-Type header yourself if you use FormData. Node 22's fetch builds the header with the boundary on its own for a FormData body.
The response is a binary/octet-stream zip with image_0.png inside. Check the model from the Source value in the PNG's tEXt chunk (NovelAI Diffusion V5 0ADF9AB7).
To stay at 0 Anlas, keep all of it: Opus, one image (n_samples: 1), no base image, a pixel product of 1,048,576 or less, and 28 steps or fewer — then read /user/subscription before and after the generation and compare the sum trainingStepsLeft.fixedTrainingStepsLeft + trainingStepsLeft.purchasedTrainingSteps. trainingStepsLeft is an object rather than an integer, so you cannot subtract it directly. usage.percent is too coarse to use for per-image checks.
Respect the API document's "all generation requests must be initiated by a human action" and its 429 note ("API clients should not attempt to retry") by sending human-initiated requests one at a time with a gap between them. This round of measurements ran with 6 seconds between requests and a concurrency of 1.

Image: the sample outputs in this post are AI images generated with NovelAI Diffusion V5.

Takeaways

With this body skeleton, params_version is ignored — 4, 3, 1, and 0 all return the same pixels — and JSON and multipart bodies produced the same image. The parts that actually matter are the host, image.novelai.net, and keeping both v4_prompt and v4_negative_prompt in the body, since dropping either one returns a 500 rather than a validation 400.

Unverified

How a 429 behaves: the API document explicitly forbids retrying, so I didn't provoke one on purpose. 429 isn't even documented for the image endpoints, so I don't know the actual message.
What happens when director_reference_* fields are sent to V5: V5 doesn't support Precise Reference, but the schema doesn't block these fields. Whether that is a 400 or "ignored and billed", I didn't run, because of the billing risk.
The actual charge for a 29-step or 2-image request: that is the paid band, so I didn't generate it. The price lookup path I tried was a 404, so the only figure I have is the 45 Anlas for the large size from the earlier post.
The absolute capacity of the Opus battery (allowance): usage.percent stayed fixed at 87 across six images, so I couldn't work backwards to a per-image draw.
How params_version behaves with other body skeletons: I didn't run it with character-prompt, inpainting, or img2img bodies. Large values such as 9 also fell outside the generation budget.

Changelog

Version	Description
1.0	2026-09-14 first version (macOS 26.5.2 · Node v22.22.3 · Opus, 6 free-tier generations)
1.1	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Running NovelAI V5 in ComfyUI: nai-diffusion-5-full works, and the Error fetching Anlas 400 is a moved endpoint

Ilan Kim — Sun, 13 Sep 2026 07:59:16 +0000

nai-diffusion-5-full and nai-diffusion-5-curated work as they are through the ComfyUI_NAIDGenerator node, even though the README says the IDs haven't been checked against the live API. The Error fetching Anlas 400 that shows up next to them has nothing to do with the models: the node still asks https://api.novelai.net/user/data for your balance, and NovelAI moved its user endpoints to image.novelai.net, so two spots in nodes.py fix it.

Overview

The Source metadata in the PNGs the node brought back read NovelAI Diffusion V5 0ADF9AB7 and NovelAI Diffusion V5 DB276663 respectively, and on an Opus account one image at Normal size (832×1216) and 28 steps cost 0 Anlas. Two terms if NovelAI is new to you: Anlas is NovelAI's generation credit, and Opus is the top subscription tier, which generates the common sizes without spending any.

I wrote this for people who read the README line "have not been independently confirmed against the live API yet" and hesitated, and for anyone hitting Error fetching Anlas the way issue #51 describes. I installed ComfyUI v0.35.0 fresh on macOS and pinned the node to its 2026-08-21 commit, 52da75a (package version 1.0.9).

The problem

Wire the Anlas Tracker node into Preview Any and run it, and the preview text reads Error fetching Anlas while the console prints one line:

[NovelAI] Failed to fetch Anlas balance: 400 Client Error: Bad Request for url: https://api.novelai.net/user/data

The node added the two V5 model IDs in PR #50 on 2026-08-21, but the README still carries the caveat that they were never compared against the live API. Issue #51, opened the next day, reports a generation 400 on a trial account together with Error fetching Anlas, and as of 2026-09-13 it has no replies.

Meanwhile NovelAI moved its user endpoints to image.novelai.net around the V5 launch. The 400 from the old host is exactly what I saw in my earlier Korean post, so I checked whether the node was failing for the same reason.

The cause

It is because _get_user_data in nodes.py calls /user/data with USER_API_BASE_URL = "https://api.novelai.net". Attach a token and call both hosts directly, and their answers diverge:

Call	Response
`GET https://api.novelai.net/user/data`	400 `{"statusCode":400,"message":"Please refresh NovelAI.net. If using a third-party tool, update to the image URL."}`
`GET https://image.novelai.net/user/data`	200, includes `subscription.trainingStepsLeft`

Without a token both hosts return 401, so reproducing this needs a valid one. Swapping the host isn't the end of it either. On the new host trainingStepsLeft is not an integer but a shape like {"fixedTrainingStepsLeft": 9898, "purchasedTrainingSteps": 32}, so the Tracker text prints the dictionary verbatim and the Generate node's before-and-after subtraction start_anlas - final_anlas dies with TypeError: unsupported operand type(s) for -: 'dict' and 'dict'.

The model IDs themselves were fine. Here is what a ModelOption → Generate → Save Image workflow returned over POST /prompt, with the same prompt, seed, and 28 steps as the earlier post:

Model	Size	Result	PNG `Source`	Subscription Anlas
`nai-diffusion-5-full`	832×1216	200, 4.1 s	`NovelAI Diffusion V5 0ADF9AB7`	9,898 → 9,898
`nai-diffusion-5-curated`	512×768	200, 1.6 s	`NovelAI Diffusion V5 DB276663`	9,898 → 9,898

There is one trap. The PNG that Save Image writes keeps only the prompt chunk, and the Source field NovelAI set is gone. The node saves the original separately under a running number such as output/NAI_autosave_00001_.png, so read the metadata from the file whose number matches the run you just made.

What to do

Fix _get_user_data in nodes.py in two places. Point the host at image.novelai.net, and normalize the dictionary-shaped trainingStepsLeft into an integer total:

-    USER_API_BASE_URL = "https://api.novelai.net"
+    USER_API_BASE_URL = "https://image.novelai.net"
@@
     response.raise_for_status()
-    return response.json()
+    data = response.json()
+    steps = data.get("subscription", {}).get("trainingStepsLeft")
+    if isinstance(steps, dict):
+        data["subscription"]["trainingStepsLeft"] = int(steps.get("fixedTrainingStepsLeft", 0) or 0) + int(steps.get("purchasedTrainingSteps", 0) or 0)
+    return data

Restart the server and run the Anlas Tracker again, and it shows 9930 Anlas. That is the subscription 9,898 plus the purchased 32, the same number the web UI shows as your total, and when I generated one more V5 image at Normal size after the patch, the console printed Generation cost: 0 Anlas.
For V5, picking nai-diffusion-5-full in ModelOption is all there is to it. On Opus, leave limit_opus_free on and Normal size at 28 steps or fewer stays in the free band.
I sent the same patch upstream as PR #52, along with a correction to the unconfirmed line in the README. I also posted the reproduction log on issue #51 with a link to this article.

Image: the sample output was generated with NovelAI Diffusion V5.

Takeaways

Both V5 model IDs work through the node as shipped, and the Error fetching Anlas 400 is the balance lookup still pointing at api.novelai.net. Fixing it takes the new host plus one normalization, because trainingStepsLeft now arrives as a dictionary rather than an integer.

Unverified

The generation 400 on a trial account: I don't have a trial account, so I couldn't reproduce the generation failure from issue #51. Whether it shares a cause with the balance lookup failure, I don't know.
Regression on V4.5 and older models: I judged from the code alone that the patch touches only the balance lookup function and leaves the generation path alone, and I did not re-run a V4.5 generation.

Changelog

Version	Description
1.0	2026-09-13 first written (ComfyUI 0.35.0 + ComfyUI_NAIDGenerator 52da75a, measured on an Opus account)
1.1	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

NovelAI V5 on Opus: usage limits, the 2026-09-21 subscription Anlas reset, and the api.novelai.net to image.novelai.net move

Ilan Kim — Fri, 11 Sep 2026 17:28:39 +0000

On an Opus account (NovelAI's top subscription tier), NovelAI Diffusion V5 still costs 0 Anlas (NovelAI's generation credits) up to Normal size (832×1216) at 28 steps and one image per request; Large (1024×1536) is where 45 Anlas starts coming out of your balance. From September 21, 2026, your unused subscription Anlas resets to 0 when your subscription period ends, and the balance endpoint has moved from api.novelai.net to image.novelai.net. The reset is tied to the end of your period, not to the effective date: on September 22, the day after it took effect, this account's balance was still untouched.

Overview

V5 shipped on 2026-08-21, and with it came a "battery" usage limit on Opus subscriptions. The announcement doesn't say how much a single generation draws or where you can see it, so I ran the numbers myself against the API. The reset itself is still a policy statement here: this account's paid period runs to September 29, so the day-after query only shows that nothing is wiped on the effective date. I measured on 2026-09-11 and 2026-09-13, and queried once more on 2026-09-22.

I wrote this for two groups: people deciding whether to keep or cancel Opus, and people driving the NovelAI API directly from tools like ComfyUI nodes. In that order: the per-size cost table, the new usage field, and the endpoint that moved.

The problem

Querying your balance at the old address now returns a 400. The response body is a single line:

GET https://api.novelai.net/user/subscription → 400
{"statusCode":400,"message":"Please refresh NovelAI.net. If using a third-party tool, update to the image URL."}

On top of that there's a policy change. The official blog post (2026-08-20) says a rechargeable battery-style usage limit applies to V5 only, refilling automatically over roughly a week, and that starting 31 days after the V5 release, unused subscription Anlas is reset to 0 when a subscription period ends. V5 launched on August 21, which puts the effective date at September 21.

Image models older than V5 and the text models stay unlimited. But Anlas was visibly draining on an Opus account while generating with V5, so I needed to find out under exactly which conditions it gets charged.

What I measured

On an Opus account (tier: 3) I generated one image at a time with the same prompt, seed, and 28 steps, calling GET https://image.novelai.net/user/subscription before and after each generation and diffing trainingStepsLeft. Balance queries have to go to that host now to get a normal response.

Model	Size	Anlas charged
`nai-diffusion-5-full`	512×768 (Small)	0
`nai-diffusion-5-full`	832×1216 (Normal)	0
`nai-diffusion-5-full`	1024×1536 (Large)	45
`nai-diffusion-4-5-full`	832×1216 (Normal)	0
`nai-diffusion-5-curated`	512×768 (Small)	0

Within what I measured, everything up to Normal size (832×1216) at 28 steps and one image per request was 0 Anlas, and subscription Anlas started coming out at Large (1024×1536). The ComfyUI node (ComfyUI_NAIDGenerator) implements the Opus free tier as up to 1,048,576 pixels (1024×1024), up to 28 steps, and one image — I didn't measure 29 steps, multi-image batches, or the exact pixel boundary this time. Large size is where subscription Anlas gets charged, and that subscription Anlas (fixedTrainingStepsLeft) is what disappears when your subscription period ends after September 21. If you only cancel renewal and still have paid time left, the clock is the end of that paid period.

I queried the same account again once the effective date had passed. On 2026-09-22 the subscription Anlas read 9,898, the same figure as the September 13 sample, and expiresAt was still 1790674321, which is 2026-09-29 18:32 KST. So at least on this account nothing was wiped on the effective date; it is simply still inside its paid period. That is one sample, but it rules out a blanket reset on the day itself. I'll query again after that renewal and report what the reset does.

The test account held 9,961 subscription Anlas and 32 purchased Anlas (purchasedTrainingSteps) as separate line items, and the 45 for the Large generation came out of subscription Anlas only (9,961 → 9,916). If the total the web UI shows doesn't match, check whether it's the sum of the two. The reset targets the subscription side; whether purchased Anlas is exempt is listed under Unverified below.

The battery sits at the end of the subscription response, in a usage field. It didn't move once across four V5 generations. When I queried again 46 hours later, percent had dropped to 98 — after a handful of additional V5 generations from the web UI on this account in between (count not recorded). So the battery is a meter that really does go down, and timeUntilNextPercent stayed at 7,888 even at 98%, so it isn't a live countdown. A third sample nine days later was back at 100%, so it does recharge, but September 19 — the date NovelAI's official account gave for the usage limit renewal, seen 2026-09-14 — falls inside that gap, so I can't tell natural recharge from the renewal. timeUntilNextPercent read 7,888 in all three samples. That's as far as the evidence goes:

"usage": {
  "percent": 100,
  "isNegative": false,
  "timeUntilNextPercent": 7888
}

I checked the V5 model IDs while I was there. Both nai-diffusion-5-full and nai-diffusion-5-curated returned 200 with an image, and the PNG Source metadata read NovelAI Diffusion V5 0ADF9AB7 and NovelAI Diffusion V5 DB276663 respectively. Sending an ID that doesn't exist returns Validation error: model nai-diffusion-5-nonexistent doesn't exist.

For reference, a Japanese write-up (note.com, 2026-08-21) put V5 generation cost at 11 Anlas for Small, 26 for Normal, and 39 for Large, while my measurement for Large was 45. That write-up doesn't state step count or account tier (the web UI default is 23 steps; my runs were 28), so it isn't directly comparable. Logged out, the web UI showed 26 Anlas for the default settings (V5 Curated, 23 steps, Normal size), which is the non-subscriber rate with no free tier.

What to do

Keeping Opus doesn't exempt you from the V5 battery usage limit. That said, within what I measured, the Anlas charging rules are the same as V4.5 — up to Normal size, 28 steps or fewer, one image at a time, it's 0 Anlas. Battery capacity and recharge rate are still unknown. A second sample 46 hours later showed 98%, but I didn't record how many images were generated in between, so how much use it takes to get blocked stays unverified.
If you plan to cancel, order matters. After September 21, whatever subscription Anlas is left disappears when your subscription period ends, so it's better to burn the subscription side down before that period runs out — with Large generations or multi-image batches.
In third-party tools, point the balance query at image.novelai.net. If generation works but the balance won't load, that's almost always this.

Image: the sample output was generated with NovelAI Diffusion V5.

Takeaways

On Opus, V5 is still free up to Normal size at 28 steps, and if you plan to cancel, spend down your subscription Anlas before your paid period ends once the reset policy takes effect on September 21, 2026. If a tool can generate but can't read your balance, the old host is the most likely cause, so check which balance endpoint it calls.

Unverified

How the subscription Anlas reset actually behaves: the effective date has passed, but this account still has paid time left, so there was nothing to observe. I'll re-query after its renewal on 2026-09-29.
Battery capacity and recharge rate: three samples show it going down and coming back up, but the generations in between weren't counted and the September 19 renewal falls inside the gap, so I couldn't derive a drain or recharge rate.
The reset notice text and battery display in the web UI: my browser session was logged out, so I couldn't capture the subscriber view.
Whether purchased Anlas is exempt from the reset: inferred from the official post mentioning subscription Anlas only.

Changelog

Version	Description
1.0	2026-09-11 first written (measured on an Opus account via API)
1.1	2026-09-13 second battery sample added (re-queried 46 hours later)
1.2	2026-09-22 re-queried the day after the effective date (subscription Anlas unchanged at 9,898, battery back at 100%)
1.3	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.