Skip to main content
Electron has the richest models namespace of any SDK. Download control exists only here.

What is available

Downloading

On a desktop, models are the largest thing your app will ever fetch. Put the progress on the taskbar or dock icon with setProgressBar as well as in the window.

Pause, resume, cancel

None of these exist on any other SDK. They are what makes a multi-gigabyte download survive a user closing the laptop lid.

After a crash

Call interrupted() on launch. It is the difference between a user losing a 4GB download and not noticing it stopped.

Loading

A desktop has real headroom, so a larger contextLength and higher threads are reasonable here in a way they are not on a phone.

Which backend will serve it

Generated from packaging facts about the linked addon. On win32-arm64 you will see qhexrt alone, with no CPU fallback behind it; on win32-x64 and darwin-arm64 you will see llamacpp, onnx, and sherpa.

Unloading

Residency policy

ResidencyPolicy, ResidencyDecision, ResidencySlots, and ResidentModel control which models stay loaded when memory is contended. On a desktop app with a chat model and a voice session in play, this is what stops one evicting the other on every turn.

Deleting, with a dry run

deletePlan exists only on Electron. Show it before deleting, rather than deleting and reporting afterwards.

Will it fit

Ask before starting a download rather than failing partway.

Registering your own model

Gated repositories

null falls back to the environment lookup the core resolves (HF_TOKEN, then $HF_TOKEN_PATH, then $HF_HOME/token, then ~/.cache/huggingface/token), so hf auth login is honoured. An empty string clears the token and disables that fallback. The token lives in the platform secure store and is re-applied on the next initialize().

Renderer access

Everything above works identically through window.runanywhere in the renderer, so a settings page can drive downloads without the main process proxying each call: