Why browser AI can download the same model twice

The Cross-Origin Storage article starts with a familiar browser-AI problem: separate applications may download identical model files into separate caches. It explores a proposed API that could reduce that duplication, using Transformers.js speech recognition as an example.

The potential improvement is about bandwidth and storage as much as inference speed. Reusing a local model download could make subsequent applications easier to start. However, the source describes an experiment with a proposed browser capability, not a universally available web-platform feature.

Read the proposal’s status and the demonstration’s requirements before designing around it. Keep a conventional cache path for unsupported environments. If measuring the example, distinguish first-download time from repeated inference so caching improvements are not mistaken for faster model execution.

Why two websites can mean two copies

A browser does not treat every website as one shared application. Storage is organized around security boundaries, and those boundaries affect where a downloaded model can be reused. A person may therefore encounter what looks like the same model in two browser applications and still see another download.

This is easy to mistake for an inefficient model runtime. The underlying issue may instead be that each application operates in a different storage context. Understanding that distinction helps developers explain the behaviour honestly rather than promising that a model will be downloaded only once everywhere.

Design the first-use experience

Before starting a large download, tell the user what the application needs and show meaningful progress. A stalled-looking page can cause a user to refresh, which may make the process even less predictable. Separate downloading, preparing and running the model so that each stage has a clear status.

If local inference is optional, consider a deliberate choice between modes rather than automatically downloading everything. A lightweight feature should not unexpectedly consume a large share of a mobile data allowance merely because a model is available.

Treat cached models as disposable

Browser storage is not a permanent archive. Users can clear it, private browsing may behave differently, and browsers may reclaim space. The application should recover from a missing or incomplete cache without requiring the user to understand the storage internals.

Store version information with the cached assets. A model update can include several files that must agree with one another. Mixing an old configuration with new weights is a different failure from having no cache at all. A robust update process makes the intended asset set explicit and avoids advertising readiness before the necessary pieces are present.

Keep the trust boundary intact

Sharing storage across applications is not automatically an improvement. Applications can have different operators, permissions and security expectations. A design that saves bandwidth but makes one site trust another site’s mutable artifacts creates a new problem.

If a shared distribution mechanism is used, model identity and integrity still need to be checked. The fact that a file is already on a device does not by itself prove that it is the correct version for the current application.

Test the lifecycle, not just the happy path

Try a first visit, a repeat visit, an interrupted download, a model upgrade and a cleared cache. Measure what is downloaded in each case. Those observations make it possible to describe the actual behaviour to users and to identify waste that the application can control, while respecting the isolation the browser intentionally provides.