Time for some updates.

About Tokens

Generating images requires GPU compute time, and that costs money. The idea of Tokens is to give a rough estimate on how much compute is required, so people have an idea what a generation will cost.

Ideally it shouldn't be too complicated. There are three factors which have a large impact:

• Image resolution
• Number of sampling steps (indirectly influenced by strength)
• Batch size (how many images are computed at once)

Also SDXL is a bigger up-front and maintenance cost than SD1.5.

The Data

I did some initial tests and whipped up a formula that was used to compute Tokens. Now there's actual usage data, which allows to compare Tokens predicted versus actual compute time required. Initially the variance was quite high ( /-80% on average). After the latest updates it's down to /-30%, but it hasn't been live very long.

Resolution

Image size is tricky. Other services usually offer some fixed choices (1MP, 2MP) with various aspect ratios and things are easy. But when working with a canvas, resolutions need to be very flexible. The gist is, large resolutions are really expensive.

Non-linear progression

Where a 2048x1024 image takes 18 seconds, 2048x2048 already takes 60 - twice the pixels, more than three times the cost. Double resolution again, 220 seconds. It quickly becomes very inefficient. The latest version now takes this into account.

Maximum resolution

The plugin's performance settings have a "Maximum resolution" setting, which limits the image size used for diffusion. If the canvas is bigger, some relatively cheap but decent upscaling is used to make it fit. This is especially helpful for people who aren't aware of how costly high resolutions are, and load fotos or illustrations at camera/print resolutions.

In v1.17.2 the default maximum resolution is now 6MP (6 millionen pixels). This number can be tweaked in performance settings, but the maximum the service accepts is 8MP (and that's already very expensive). If you want diffusion at higher resolutions use the Upscaling workspace, it does not have a limit and uses tiling to scale better.

Fill

Actually what is the resolution of the image? It's not always clear. Inpainting (selections at 100% strength) for example will run an initial pass on a downscaled image with a lot of context, then upscale, but also crop to a smaller region around the selection. So there are multiple resolutions. Also because it's two passes, the number of steps that run is actually higher than what is configured.

The latest changes take some of this into account, but it's perhaps still not close enough. The biggest outliers currently fall into this category.

Conclusions

It's quite difficult to find a good trade off between keeping it simple, but also making it fair!
I don't really like subscriptions, but I can now see the appeal...

Examples

Formula

I'm not going to post it here as it may still change, but hey, it's open source.

UI

Also in v1.17.2 the UI now shows you how much generation will cost when you hover over the button.

Next

• There are some outstanding updates to models and support for a few more Control layers. But they have to be synced up with Plugin development.
• Payment options roll out in the next days
• LoRA support will be a bit further into the future. It's tricky to run them efficiently on on-demand servers with limited caching. From user perspective upload and caching can be automated, but it still takes some time, which should probably be transparent.