Post

My personal point of view on the Prompt API ->

fry69@fry69.dev

I hope the Prompt API ends up like SPDY -> HTTP/2 First dropped into the wild by Google -> adopted (by IETF in this case) -> re-imagined with proprietary quirks removed. In principle I like the idea of being able to prompt a local model somehow. But I want to have a say which model+system prompt.

Chrome is being used as a vehicle to assert Gemini as the default model. Dominant browser -> dominant LLM Imagine my surprise at an American corporation prioritising its own market position and profits over its users and humanity in general...

Anecdata, but I am strongly strongly strongly positive about this API. The interoperability and the ToS issues do not detract from the idea here at all. Those are browser implementation specifics/details that in no way detract from the massive potential this has for the web.

I would like to see Google have model selection in Chrome. Unbundling the Gemini model from the web could alleviate both the inter-op & ToS concerns & would be good for users. But I'm not prepared to obstruct web progress basically upon the fact that Chrome is the biggest browser by far! Boo.

idk if “solving interoperability & ToS issues” or “building vendor consensus and community buy in around a feature before it ships” are exactly obstructing web progress … the absence of this api prevents nobody from using an LLM in a web app; they can just use a library for that right now!

Having people download a couple GB for a likely less optimizable LLM runtime (web-nn maybe someday, but webgl/webgpu is… not ideal) doesn't seem like a serious proposition to me for 99.99999% of properties/sites/uses.

The positive sentiment is about future potential, but the API is here now in the present. The positivity would be more warranted if it had more time to bake. Discussions over how to overcome setbacks should've come before shipping

No, those are not comparable at all. I don’t think an argument is being made against LLMs being integrated to the web in any way, either. This particular proposal wasn’t appropriately thought through and poses unacceptable risks, is what I think most people opposed believe

It would be fairly easy to add a permission prompt into the spec, so this isn't really an issue with the API design, but Chrome does not currently ask user permission to trigger the model download or use the API.

I don't have _any_ uses for an LLM where I can't specify the model it will use. Not until the general standard for mini/on-device models is way better than the current bleeding edge.

@jakearchibald.com - "In Chrome when you create a LanguageModel it will either use the Google Cloud API or download a 4GB model to run locally". We don't use the Google Cloud API. If the model isn't available we will kick off a download, but the API just doesn't work without the modal locally.

is there a permission check on the users machine before downloading? is it possible that end users get llms downloaded to their machines without their knowledge?

WASM based LLM inference in the browser is possible for a while. Those often download models in that size. Any website can download up to ~10GB of data in localstorage IIRC, if enough space on disk is available. Or other blobs, like e.g. astronomical images than can easily be several GB in size.

i guess it’s not much different than wasm. but from what i know of google literally everything from users goes into the ad machine. i would assume prompts text would also. possibly along with training google models etc. feels like there should be a permission check around llms in general

There's no permission check, and it's downloaded without the user's knowledge. The spec has points that would allow for a permission check. But, to be fair, the web doesn't limit downloads - any page can download GBs without permission. Whether they should is another question.

I'm very grateful for people pushing back. I used the API, have some strong ideas how to make great things with it, but the legal aspects of it are broken as-is

I'm interested in this for generating alt text on edge devices. And model being different device to device and over time is a nightmare and a half. I am p annoyed that they released this with gemini nano 3 (instead of waiting for the gemma4-based gemini nano 4), it's a waste of space rn.

This is also an annoyance with the android aicore prompt api. You can specify release vs preview model, specify fast vs full model, and get the name of what that maps to, but you can't easily say "I want gemini nano e4b for this".

I gave a talk on this with inspirational but overall useless demos. The idea was that the model would solve problems by generating code and the prompt was not tailored much beyond telling it that. The code would then run sandboxes in the page and be endowed with references necessary to do things.

A user could say "I want this bulk action, create a button that'll do it for me" and get the AI to use APIs exposed by the UI to implement a custom feature no startup of company would want to put permanently in their product.

The story is true of every company: the moment you start having a big event around releases and features, is the moment that decisions start being made about crunching and pushing for not-fully-baked things to be included for that event.

you don't need to license Google's model, it's free and it's going to change - every model out there has a very limited life span; any LLM based app needs to be ready for different models the API itself may be half baked and definitely shouldn't be rushed through without consensus either way!

for that matter, their model is already outdated - other vendors already ship (free, open) models that are smaller, faster, and more intelligent the API may be rushed, but the system prompt and model lock-in concerns aren't real - or they are, but you're just describing the reality of using LLMs

yes but having different models in different browsers should be a good thing then? so we're encouraged to write prompts and workflows that work with more than one model?

Instance number 46285 of the Chromium team rushing a half-baked API out the door, explicitly avoiding standardization processes because they know their crap isn't compatible with the idea of a free and open web.

I find the hate mongering both inaccurate, distasteful, but most of all, quite low class. That just doesn't seem true to me, period, the team is doing enormous work to make the web much much better, and we need more people making good bets knt he web & trying. They don't deserve this rage.

That's a fair position. I should be clear that I don't mean to say that the Chromium contributors are a monolithic evil entity that only do bad things. They absolutely do good in much of their work, and we do greatly benefit from a lot of what they do.

However, having read discussions between some Chromium and Mozilla devs regarding other forever-experimental APIs, I feel this is an established pattern of behaviour from the Chromium project that has not improved, and is clearly driven by Google's desire for control over the web.

Correction: Chrome's doesn't use the cloud, it only uses the 4gb model. chrome://on-device-internals/ has a faulty "uninstall" feature, which made it look like the model was uninstalled, but it still worked, which made me think it (as the spec allows) was using the cloud.

i wonder if people are going to get as upset about google shoving this through the standards process as they got/still are about web components supposedly also shoved through by the googlers. guess we will have to wait 10 solid years to find out. as the vice president of web components, not a fan.