kbx

Hey, I'm the Chrome PM for the built-in AI APIs. I wanted to jump in on the privacy concern mentioned here.

It’s a totally valid question, and transparency is the only way this can work. On-device processing is an important core design goal of these APIs.

There are NO logs of the input / output interactions sent to any server, not even for training purposes. The only metrics we have are on performance, stability, and other generic API usage signals like any other APIs. These are all controlled by existing user preferences in Chrome.

Hey, Chrome PM for built-in AI here.

Thanks for the write-up and the comparison, but more importantly for using the API in production!

You’re highlighting the "state of the art" gap we’re working to close. Cloud models will always have the advantage of massive parameter counts, but our bet is that for a huge class of simpler or high-volume tasks, the upsides of on-device (e.g. zero-cost, permission-less start with no quotas/infra, network-resilience, privacy) make it a compelling trade-off.

The models have been getting better at a rapid clip, and the team is heads-down on optimizing performance and reliability. To that end, we're always grateful for feedback. If you hit specific bugs, crashes, or quality regressions, filing a report with repro steps is the best way to help us improve. You can file those on crbug.com under the "Chromium > Blink > AI" component.

It's on track to ship in Chrome 148: https://chromestatus.com/feature/5134603979063296

The parameters are not part of this initial release but can be added back with the origin trial you discovered.

Chrome PM for built-in AI APIs here.

I love this "de-snarkifier" idea and it seems to have broad interest. I couldn't resist hacking (well, vibe coding[1]) a "Snarknada" prototype to explore the viability, including patterns for low-latency and accuracy.

You’ve hit on exactly why we think on-device is the right move for this class of use cases. If you tried to "de-snark" an entire infinite-scrolling feed via a cloud API, the token costs would be astronomical for a developer. Plus, people (rightly) don't want to send their private social feeds or DMs to a third-party server just to clean up the tone.

Moving this to the device should make high-frequency "Semantic Mutation" financially and technically viable for the first time. If you (or anyone else) starts building this more seriously than my PM vibe coded toy, and hits specific friction points, I’d love to hear about them: it helps us prioritize the roadmap.

[1]: If you're using a coding agent (Cursor, Claude Code, etc.), I recommend pointing it to https://www.npmjs.com/package/built-in-ai-skills-md-agent-md. Most models were trained on the now-obsolete window.ai namespace, and this skill file helps them use the current APIs correctly.