What a model download costs

Every page offering a model in a browser is quiet about the same three things: which host the file comes from, what is left on your device afterwards, and how long the work takes on the hardware most people are holding. Here they are, in that order.

The transfer, itemised

Two files would arrive, not one, and the smaller of them is the one nobody mentions. The weights are the product; no model is published for this build yet, so their size has not been measured, and early estimates of around ninety megabytes are only estimates. The runtime that executes them is a WebAssembly build just under fourteen megabytes — that figure is measured, it is the file this site serves — and without it the weights are an inert file. Both are paid for on the first pass and not again.

The weights would come from our model file server. That is a deliberate choice with a cost attached: it is a request to a second host. It is accepted because the alternative is a public model hub learning which of this site’s visitors is deblurring what. The request carries the file name and nothing about your photograph.

The runtime comes from this origin instead. Same-origin removes the cross-origin module failure entirely and keeps the count of other hosts this page talks to at exactly one, which is a sentence the privacy page can then write without hedging.

Nothing moves before a control says how much

The ordering is the point. A control naming the exact byte length is pressed, and only then does a byte move. A page that begins a hundred-megabyte transfer and mentions it afterwards has already spent somebody’s data allowance, and on a metered connection that is money.

Stopping it

Escape aborts a transfer in flight. Nothing partial is written: the cache entry is created after a complete body of the expected length has been read, and a body that finishes at the wrong length is refused rather than kept. A truncated graph served from disk for the life of a browser profile is a far worse problem than a download that plainly failed, and it is the reason the write happens last.

What this build has today

None of it, yet. No export is published for this build to fetch, so no control here offers a download and no figure is printed as though it had been read off a served file. The arithmetic pass on the instrument routes needs no transfer at all.

What is left on your device, and how to remove it

WhereOne Cache Storage bucket, named for the release. A new set of weights becomes a new bucket rather than overwriting a path, so there is never a question of which version is on disk.
What elseNothing. No cookie, no local storage, no account, and no record of which frame you opened — the pass reads a bitmap and forgets it when the tab closes.
Removing itOne control under the rail. It drops the bucket, releases the session and its memory arena, and reports how much it freed.
Private windowsSome profiles refuse the Cache API outright. The feature still runs; it simply pays for the transfer again next session, and the rail says so instead of failing without explanation.
EvictionA browser may clear the bucket on its own when storage runs short. That is the browser doing its job, and the only consequence is one more transfer.

Seconds, on hardware people actually own

The figure that ships is a mid-range Android on single-threaded WebAssembly, not a desktop with a discrete graphics card. That is not modesty; it is that threads need cross-origin isolation, which this static site does not switch on, and a figure quoted from a configuration the page cannot run in is a false one.

Which is also why the estimate in the rail is a range rather than a number. It is produced by timing this processor on the identical loop the pass will run, and then multiplying by the arithmetic the real frame costs. Between the timing and the pass sit a thermal state, a garbage collection and whatever else the tab is doing, and a single figure would be precise about something that is not.

  • Cost scales with the pixel count and with nothing else. Four times the pixels is four times the wait, which is why the preview runs on a 1024-pixel working copy and the full frame is only rendered when you save.
  • A full-resolution phone photograph is roughly twelve times the work of that default. The export panel carries its own estimate for it, so the choice is made with the number in view.
  • The pass usually runs in a background worker, so the tab stays responsive and the progress readout moves per round. Where a browser will not start one, the status bar says the pass is running on this thread, and Stop still works between rounds.
  • Peak memory, not total time, is what ends a tab on iOS. The megapixel caps are lower there for that reason and are a guardrail rather than a preference.

Is it worth it

For one irreplaceable frame, almost certainly. For a folder of forty, almost certainly not — that is a different shape of job with a different answer, and it is not what this page is. And if the frame is merely soft rather than smeared, the honest answer is that a large download buys nothing a sharpening control with no download at all would not do better.

That last case is common enough to be worth stating as a rule: spend the transfer when you cannot read something, not when you would like it crisper.

Photographic visual for The Cost Of A 92 Mb Model

The Cost Of A 92 Mb Model