What ninety-two megabytes 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 and are roughly ninety-two megabytes. The runtime that executes them is a WebAssembly build just under fourteen megabytes, and without it the weights are an inert file. Together that is a little over a hundred megabytes for the first pass and nothing at all for every pass afterwards.

The weights would come from the network’s own object store. That is a deliberate choice with a cost attached: it is a request to a second host, and a shared one, which is a stronger common thread between this domain and its siblings than anything else on the page. It is accepted because the alternative is a public model hub learning which of this domain’s visitors is deblurring what, and because naming the host in the same release as the feature is the only version of that trade worth making.

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

Where	One 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 else	Nothing. 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 it	One control under the rail. It drops the bucket, releases the session and its memory arena, and reports how much it freed.
Private windows	Some 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.
Eviction	A 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, cross-origin isolation breaks the advertising this network carries, 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 working copy is 1024 pixels on the long edge by default.
A full-resolution phone photograph is roughly twelve times the work of that default. The control offering it carries its own estimate, so the choice is made with the number in view.
The pass runs in a worker. The tab stays responsive, the progress readout moves per round, and a multi-minute job never touches the main thread — a page that freezes reads as broken however correct it is.
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 hundred megabytes buys nothing a console 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.