Chrome built-in AI

First-party Chrome developer documentation for built-in AI — the browser exposing on-device AI models as web-platform APIs, so a web app can run AI tasks with no cloud call. Tier T1 (official developer.chrome.com docs). It is the developer-platform layer beneath this spoke’s ai-browser thesis: where Gemini in Chrome is the end-user assistant, built-in AI is the API surface web developers build on — the same vendor (Google) supplying both the consumer feature and the substrate. Status: origin trials (experimental, on the path to a web standard), with polyfills for browser-support gaps.

The model and the APIs

The browser manages the models locally; Gemini Nano is the primary on-device model. On top sit task-specific APIs:

• Prompt API — general-purpose language-model calls (the flexible base).
• Summarizer — summaries in various formats/lengths.
• Translator + Language Detector — in-browser translation and language ID.
• Writer / Rewriter — generate new content / change tone or length.
• Proofreader — grammar and readability.

The split mirrors the assistant features gemini-in-chrome ships (summarize, draft, translate) — but here they are primitives a site can call, not a chat panel the user talks to.

Why it’s here — the on-device substrate

Two things this adds to the spoke:

• A second way “AI in the browser” arrives. The ai-browser axis had assistant vs agent; this adds a consumer-feature vs developer-platform cut. Chrome ships both — Gemini-in-Chrome for users, built-in AI APIs for sites — so the incumbent’s AI play is two-layered, and any web app (not just the browser’s own assistant) can become AI-powered.
• On-device is the bridge between the AI and privacy currents. Built-in AI runs locally: data stays on the device, it works offline, latency is instant, and there is no per-call server cost. That puts an AI capability on the same privacy/local-first footing as the spoke’s privacy current (Brave/DuckDuckGo/Ladybird) — AI and privacy stop being opposed when the model is on-device.

Building on it (2026-07-28)

The companion page chrome-built-in-ai-dos-donts covers production practice, and two of its rules change how this substrate should be read.

The local-model bargain has a bill attached: the developer now manages session lifecycle and memory (create() once, clone() per task, destroy() when done), strips inputs because latency scales with them, and caches repeats — work a cloud API’s operator would absorb. “No per-call server cost” means the cost moved to the user’s machine and to whoever writes the page.

And the browser treats its own on-device output as hostile: “Treat all LLM output as untrusted content. Sanitize the full combined output, not just chunks,” because “malicious code could be split across updates.” Running locally, from a first-party model, buys nothing on the injection front — which sharpens rather than resolves the trust question the ai-browser category faces.

Cross-spoke

• ../llm-inference-wiki owns on-device execution as a subject — Gemini Nano running locally is the browser-embedded cousin of that spoke’s local-llm-stack (Ollama/llama.cpp/LM Studio); the inference engine is theirs, the browser platform API is here.
• ../agentic-tooling-wiki — the Prompt API is a model-call surface an in-page agent could build on; agent frameworks are that spoke’s subject, the browser API is here.

Related

chrome-built-in-ai-dos-donts · ai-browser · gemini-in-chrome · browser-wars-2026