Chrome built-in AI — dos and don’ts

First-party Chrome guidance on shipping features with built-in AI. Where that page documents what the APIs are, this one documents how to build on them without the result being bad — session lifecycle, input hygiene, output handling, and UX. T1, and paired with its sibling rather than duplicating it: same docs site, different subject.

Its value to this spoke is that it’s the incumbent describing the failure modes of in-browser AI in its own words, which is more revealing than a launch post.

The engineering guidance

Most of it follows from one fact — the model is local, and the constraint is the user’s machine, not a billing account.

• Warm the model early. Initialize the session “as soon as you’ve clearly established the user’s intention to use the AI feature”; waiting for the click makes the user pay for model load. Pass system instructions at create() rather than in the first prompt(), then clone() that base session per task instead of re-creating it.
• Memory is yours to manage. Call destroy() on sessions you’re done with; don’t hold several large ones open. That’s a sentence you never write against a cloud API — server-side, sessions are someone else’s RAM.
• Don’t reuse a session across unrelated tasks — stale context bleeds into the new one.
• Strip the input. “Only pass to the model what’s strictly needed”; no raw unprocessed text, metadata, HTML tags, or unfiltered lists, because latency grows sharply with input size.
• Constrain output with a JSON schema (responseConstraint) rather than asking in prose, since “models might include conversational filler that breaks your parser.”
• Don’t enforce length in the schema. A maxLength: 125 makes the model compress meaning into “high-density tokens like foreign languages or emoji” and produce nonsense — let it generate, then truncate client-side. The schema constrains the tokens, not the meaning.
• Cache repeated inputs in sessionStorage/IndexedDB with normalized keys and a conservative TTL (the sample uses one hour).

Untrusted output, and a recommendation to fake latency

1. The browser tells you its own AI output is hostile. “Treat all LLM output as untrusted content. Sanitize the full combined output, not just chunks” — because “malicious code could be split across updates” — and never set innerHTML per streaming chunk. So a model running on the user’s own device, shipped by the browser vendor, is still handled as an injection source, and streaming makes it worse: a payload split across chunk boundaries passes a per-chunk filter and reassembles in the DOM. That’s the ai-browser trust problem stated at the platform layer, where the browser’s own docs can’t wave it away.

2. It recommends faking latency. Consider “an artificial delay of one or two seconds if a response is nearly instant”, because users may trust a result more when they perceive effort. On-device inference removes the network round-trip, and the guidance’s answer is to put some of it back — as theatre. It’s a small thing and it’s honest about its reasoning, but it is advice to misrepresent how much work was done in order to buy trust, sitting in the same document that tells developers to keep the user the final editor and to never force an AI result as the only option. Recorded as the source’s recommendation, flagged as the one piece of guidance here that isn’t about making the feature better.

The UX rules, which are about control

The user-facing half is consistent and worth reading as a position: show progress rather than “surprise users with instant UI replacements”; never overwrite a draft “without a way to go back, revert, or compare versions”; offer a stepper or history so results can be explored; “make the user the final editor of all generated content”; don’t “force an AI-generated result as the only option.”

That is the assistant pole (ai-browser) written as engineering requirements — reversibility, comparison, human final say — by the same vendor whose consumer assistant markets the same restraint. The agentic challengers sell the opposite. Chrome is consistent across both layers of its stack.

Related

chrome-built-in-ai · ai-browser · gemini-in-chrome · browser-wars-2026 · synthesis