Built-In Browser AI: Prompt API and On-Device Limits

Q: What is built-in browser AI and how is it different from a normal AI API?

Built-in browser AI is an on-device large language model that the browser itself ships and exposes to web pages through JavaScript interfaces, so your code can run inference locally with no API key, no network round-trip, and no per-token cost. In Chrome the model is Gemini Nano, and it powers a set of task APIs — Summarizer, Translator, Language Detector — plus the general-purpose Prompt API. The crucial difference from a cloud AI API is that a cloud API is always available if you have a key and pay per token, whereas built-in AI may simply not exist for a given user: it is present only on Chrome desktop, only on hardware that meets a bar, and only after a multi-gigabyte model download has completed. That inverts the design problem. With a cloud API you design for cost and latency; with built-in AI you design for absence, because the majority of your sessions will not have the model at the moment they need it, and your feature has to keep working anyway through a fallback path.

Q: Is the Chrome Prompt API stable in 2026, and which built-in AI APIs are generally available?

As of 2026 the picture is a mix of stable and trial. The Summarizer, Translator and Language Detector APIs reached general availability in Chrome 138 stable, and the Prompt API — the general text-in, text-out interface accessed through the global LanguageModel object — reached stable in Chrome 148. The Writer and Rewriter APIs were still in origin trial across roughly Chrome 137 to 148, and the Proofreader API ran as an origin trial around Chrome 141 to 145. All of them are powered by the same on-device Gemini Nano model and follow the same lifecycle of feature-detection, availability check, optional download, and session creation. The practical guidance that follows from this is to prefer the GA task-specific APIs — Summarizer and Translator — where they fit your use case, because they are stable, tuned for their job, and easier to reason about than open-ended prompting, and to reach for the Prompt API only when your task is genuinely open-ended and cannot be expressed as summarise, translate, or detect.

Q: Do I still use window.ai to call built-in AI?

No, and this is one of the most common sources of broken tutorials. The early preview of Chrome built-in AI exposed a single window.ai object with nested methods, but the shipped surface replaced that with discrete global interfaces: LanguageModel for the Prompt API, Summarizer for summarisation, Translator for translation, LanguageDetector for language detection, and Writer, Rewriter and Proofreader for their respective tasks. Each one is feature-detected on its own, for example by testing whether the string LanguageModel or Summarizer is present in self, and each exposes its own availability() and create() methods. A large amount of blog content and sample code written during the preview still references window.ai, and copying it will fail silently on current Chrome. The safe rule is to verify every interface name against the current official Chrome for Developers documentation rather than against year-old posts, because this API surface changed shape during its path to stable and older material is actively misleading.

Q: What are the four availability states and why do they matter?

Every built-in AI interface exposes an availability() method that returns one of four values: unavailable, downloadable, downloading, or available. These matter because they encode the single biggest difference from a cloud API — the model might not be on the device yet. Unavailable means the browser supports the interface but this device cannot run the model, typically because the hardware does not meet the requirements, so you must fall back to a cloud or in-page path. Downloadable means the model can be fetched but has not been yet, and downloading means a fetch is in progress; in both cases the model is a multi-gigabyte download that will not complete inside a user interaction, so you must not block the user and should instead fall back immediately while optionally triggering the download in the background. Only the available state means you can call create() and run inference locally right now. Code that feature-detects the interface but skips the availability() branch will appear to work on the developer machine, where the model is already downloaded, and then fail for real first-time users whose model is still downloadable.

Q: What hardware and platform does Chrome built-in AI require?

The requirements are strict enough that they exclude a large share of real users, which is exactly why fallback design is mandatory. Per Chrome documentation, the Prompt API requires a desktop operating system — Windows 10 or 11, macOS 13 Ventura or newer, Linux, or ChromeOS on a Chromebook Plus — with no support for Android or iOS. The device needs at least 22 gigabytes of free storage on the volume that holds the Chrome profile, because the model and its working files are large, and it needs either a GPU with more than 4 gigabytes of VRAM or a CPU with at least 16 gigabytes of RAM and four or more cores. The initial model download requires an unmetered network connection and happens once. Stacking these constraints together, the honest planning assumption is that only a minority of your total sessions can run the model today, so built-in AI should be treated as a progressive enhancement layered on top of a baseline experience that works without it, not as a platform you can assume is present.

Q: How should I architect a feature that uses built-in AI without breaking on other browsers?

The architecture that survives production is a single internal capability, such as a summarize(text) or draft(prompt) function, with three interchangeable backends behind it. The first backend is built-in AI, used when feature detection and the availability() check both pass, giving you zero-marginal-cost local inference on qualifying Chrome desktop sessions. The second is an in-page model running on WebGPU through a library such as WebLLM or transformers.js, which gives non-Chrome browsers an on-device path without a server, at the cost of fetching a model of hundreds of megabytes. The third is your cloud API, which is the universal floor that every user gets when neither local option is viable, including mobile and unsupported browsers. Two rules keep this honest: keep the routing decision a first-class, unit-tested, observable function rather than scattered conditionals, and remember that the tiers are not equal in quality, because a small on-device model does not produce the same output as a frontier cloud model, so you must not silently mix them where cross-device consistency matters.

Q: Is built-in AI genuinely private and free?

For calls that actually run on-device, yes on both counts, and that is the whole point of the capability. When availability() returns available and you run a prompt through the local model, the input and output never leave the device: there is no network request, so the data is not sent to Chrome, to Google, or to any server you operate, which is a materially stronger privacy position than a zero-retention cloud contract because the data simply never travels. And because the computation runs on the user’s own hardware, there is no per-token bill — the marginal cost of each local call is zero to you. The important caveat is that these benefits apply only on the local path. If your fallback sends the same data to a cloud API, that fallback traffic has the normal privacy and cost profile of any cloud call, so you should not round-trip to the cloud out of habit on sessions where the local model was in fact available, because doing so pays the full complexity of the design while keeping none of its benefit for those users.

Q: Will built-in AI ever work in Firefox and Safari?

It is plausible but not guaranteed, and the signal to watch is standardisation rather than any single vendor announcement. The Summarizer, Writer, Rewriter, Translator and Prompt interfaces are being incubated toward cross-browser specifications in the W3C Web Machine Learning Working Group, which is where a Chrome-originated API surface would need to mature before other browsers could ship a compatible version. If and when Firefox or Safari implements the same feature-detected globals, correctly written code that already branches on interface presence and availability() would light up those new backends automatically, without product changes. Until that happens, the correct assumption is Chrome-desktop-only, and the correct design is to keep an on-device WebGPU fallback and a cloud fallback so that non-Chrome users are served regardless. The architectural payoff of doing this properly is that adopting a future browser backend becomes a configuration change in your routing layer rather than a rewrite, because the capability was always abstracted behind one internal interface.