The APIs and their four states

Chrome ships a set of on-device AI APIs backed by a local model: Summarizer, Translator and LanguageDetector on the web since Chrome 138, the Prompt API (LanguageModel) on the web since Chrome 148 according to Google's status page, and Writer, Rewriter and Proofreader still in trials. Each has a static availability() method that resolves to one of four strings, as defined by the Writing Assistance APIs specification:

unavailable: the device or the requested options are not supported.
downloadable: a download is needed and has not started.
downloading: a download is in progress.
available: a session can be created now.

A deployed challenge widget calls Summarizer.availability(), waits for the promise and records the result as a string, so this value is now part of what a session reports.

The published requirements

Chrome's documentation lists the conditions for the on-device model: Windows 10 or 11, macOS 13 or later, Linux, or ChromeOS on Chromebook Plus; at least 22 GB of free space on the volume that holds the profile (the model is removed again if free space later drops below 10 GB); and either a GPU with more than 4 GB of video memory or, since Chrome 140, a CPU path with 16 GB of RAM and at least 4 cores. The download, about 4 GB, needs an unmetered connection and starts only when a page calls create() with user activation.

The APIs are exposed in top-level windows and same-origin iframes. A cross-origin iframe gets them only when the embedding page delegates them with allow="summarizer", and they are not available in Web Workers. Enterprises can block the model download with a policy, and hardened fleets do.

What we measured

We ran Google Chrome 156 headless on a Linux VM with 8 vCPUs, 31 GB of RAM and no GPU:

Summarizer, LanguageModel, Translator and LanguageDetector were all defined and all answered downloadable, in both headless modes.
With the profile on a volume with only 8 GB free, below the documented 22 GB, the answer was still downloadable. The disk check apparently applies when a download starts, not when availability is queried.
On a page that is not a secure context, all four were undefined.
Writer, Rewriter and Proofreader were undefined.
The first availability() call on a fresh profile took about 3.3 seconds; later calls took 1 to 6 ms.

The VM meets the documented CPU path, so unavailable was not expected there. A machine below both paths, or a container limited to fewer cores or less memory, may answer differently; we did not measure that.

What the answer reveals

The four strings are less of a hardware fingerprint than the requirements suggest, because a fresh profile on most qualifying machines answers downloadable, and the specification explicitly allows browsers to report downloadable even when the model is present, to limit fingerprinting. What the value does carry:

Presence. A desktop Chrome 138+ User-Agent on a secure page where Summarizer is undefined is an older, modified or differently configured build. A mobile User-Agent where it is defined contradicts the documentation.
State. available means the roughly 4 GB model was downloaded on that profile, which happens on long-lived profiles that someone used; fresh automation profiles sit at downloadable. unavailable on desktop points to a weak machine, a blocking policy or an unsupported OS.
Timing. The multi-second first call on a fresh profile is itself a hint that the profile is new.

Per-language-pair availability in Translator and the model version are further bits the specification itself lists as fingerprinting concerns.

The through-line

New browser APIs keep adding values a page can read, and each one has to fit the rest of the identity: the browser version (see Chrome's version is not one number), the platform and the history of the profile. A modified build that removes the API, or a persona that claims a version which ships it, have to keep it consistent. The full list of what the widget collects is in inside a challenge widget.