I'm not sure this is a winnable game for programming languages.
- Keep a small stdlib, like JavaScript (especially earlier JavaScript): everyone complains about missing features, warring communities form around jQuery promises vs. Promises/A+ vs. callbacks, supply chain attacks, left-pad/is-even dependencies, etc.
- Grow a big stdlib while keeping backward compatibility, like C++: lots of cruft left around that must never be used, sitting next to newer stuff with similar names. People complain about the bloat.
- Grow a big stdlib and then break backward compatibility, like Python 2 -> 3: everyone is sad, the ecosystem churns for years.
I admit there are probably better and worse versions of each strategy, e.g., it seems to me like JavaScript's slow-but-steady accretion of primitives over time has gone OK, and it seems like apart from Python 2 -> 3 some of the PEPs I see for deprecations and replacements are reasonable. But no language has ever hit on a strategy that everyone loves, as far as I can tell.
What type of project actually uses C++ 23 modules in real life? What kind of toolchain enables that? When I worked on Chromium, they were indefinitely in the "maybe in 5-10 years the tooling will be ready" camp.
The tooling people have - as of about a year ago said they are ready. Now everyone who considers themselves early adopters is using then. Most are waiting for the early adopters to figure out what the best practices are so we don't make a mess
Fascinating to see that Chromium/Gecko/WebKit are now more "open" browser engines than Ladybird, at least in one important respect.
(Servo is arguably in the middle, accepting outside contributions as long as you don't use AI.)
It's understandable that a team without much funding would have to close off contributions to spare on labor costs. But, it makes me feel that people don't give Google/Mozilla/Apple enough credit for the economic resources they put into enabling openness.
(Personal bias/experience alert: I'm currently retired, but formerly worked at Google on Chrome. I saw many of my coworkers nurture outside contributors, and did some of that myself, both informally and through programs like internships.)
Those corporations are not doing that out of the good of their hearts. They are doing so to assert control, in order to protect their business value. If it stopped being economical for them, they would stop tomorrow.
I do not think we should be eternally grateful for monopoly building.
Fingerprinting concerns here are really overblown. At least in Chrome's implementation, the model version / responses will give you ~2 bits over the browser major version: whether the machine can support the model, and whether the model is downloaded yet or not. (Really <2 bits, since these ratios aren't 50/50 in the population.)
I was formerly the design lead / spec editor for this API while I worked at Google. I retired in 2025-09, before it got shipped. The following contains no inside knowledge.
I am sympathetic to all of Mozilla's concerns here, even though on balance I believe Chromium's decision to ship was the right one.
---
On interoperability, I agree that this is a tough case. But I am more optimistic than Mozilla that developers will use this API in a way that can work across different models.
First, they will be somewhat forced to, because Chrome will change the model over time. (It already changed from Gemini Nano 2 to 3, and I suspect it'll change to 4 soon if it hasn't already.) Edge is already shipping a Phi-based version. A small number of users are using other models via extensions like https://aibrow.ai/. And it's very possible Safari might join the party, exposing the Apple Foundation Models that ship with iOS via this API. (When the Foundation Models API came out, we were struck by how similar it was to the prompt API designs that preceded it, and were hopeful that Apple was going to do a surprise announcement of shipping the prompt API. It hasn't happened yet, but I still think it might soon.)
Second, we designed the API to steer developers in that direction as much as possible, e.g. encouraging the use of structured output constraints. There are also lots of clear error paths, that almost force developers to use this as a progressive enhancement. (E.g., the existence of low-memory/disk space devices.) So it's very unlikely we'll see developers build sites that are gated on this API existing. It'll mostly be used to sprinkle some AI magic, or let users do cool things without entering some cloud API keys.
I made similar arguments for the writing assistance APIs at [1]. As I said there, the prompt AI is trickier than the writing assistance APIs. But I believe it's a difference of degree, not kind. The web has many nondeterministic APIs that access some underlying part of the system, from geolocation to speech recognition/synthesis, all the way up to these AI-based ones. The question is where you draw the line. Mozilla seems to be giving some signals (not yet definite) that translation is on the OK side of the line, but summarization/writing/rewriting/prompting is not. That's a very reasonable position for them to take on behalf of their users. I imagine the Chromium project is hoping that over time, in-the-wild experience with these APIs shows that the benefits outweigh the risks and costs, and so Mozilla (and Apple) follow in shipping them as well. That's definitely happened in other cases, e.g., Mozilla recently indicating interest [2] in implementing WebBluetooth, WebHID, WebNFC, WebSerial, and WebUSB after years of taking a wait-and-see attitude.
You can learn more about my general thoughts on this question of shipping APIs first, and how the Chromium project takes on first-mover risks, at [3], which I wrote during my time on the Chrome team.
---
On the prohibited use policy, I agree that this is just absurd on Chrome's part. This is not how web APIs should work. It smacks of lawyers trying to throw something out there to cover themselves, or of corporate policy being set at the top level for "all AI uses" and then applied even for web APIs where that makes less sense.
The only saving grace is that I suspect it won't actually trigger. Because, as Mozilla points out, it's quite impractical to enforce. But it's still wrong.
I hope Chrome changes this, although I'm not holding my breath.
I did find it interesting that Gemma seems to have a similar terms of use [4]. (Open-weights, not open-source!) As do the Apple Foundation Models in iOS [5]. So unfortunately if the Chrome team were to push for a no-TOS API, they might be forging new ground, which is always difficult in a large company.
---
On the issue of insubstantial developer signals, I think this is just a failure of the current Chrome team in terms of collecting and collating signals. If one pokes around and knows where to look in various threads, you can find a lot more positive signals than the outdated ones in [6]. I wouldn't have let that Intent to Ship get out the door without properly updating that section of the explainer, for sure. (But hey, not my job anymore!!)
On interoperability, time will tell I guess. I've only been working on Firefox for a few months, but general interop issues are way worse than I realised when we worked together at Chrome. Firefox frequently gets bug reports for not behaving like Chrome, even when Firefox is complying with the spec, and Chrome is not. We end up having to just behave like Chrome.
On developer signals… I'm sure there's better evidence of positive sentiment than Chrome provided, but there's a lot of negative sentiment too. I think it would be fair to call the developer signal "mixed", or maybe even "polarised".
Sucks to be corresponding via The Second Worst Website In The World (TM), but here we are. Hope all's well on your end.
A minor correction from Edge's perspective: we've participated in OT using Phi models, but have not shipped to Stable, and are unlikely to given the current shape of things. Developers have not given us feedback that they're relaxed about compatibility, but I would obviously welcome that sort of data in case anyone has it to hand.
> So it's very unlikely we'll see developers build sites that are gated on this API existing.
I think this is an oddly optimistic outlook from someone who until recently worked at Google. A company that has shipped, and probably still ships, lots of sites and versions of sites gated behind "does your user agent say it is Chrome".
I just wonder how a highly non-deterministic API like the Prompt API can work in a system that heavily focuses on interop between new and old websites.
What's going to happen is that people build stuff with the current iteration and a few years later a model update will work entirely differently and break the existing implementations. I understand that every once in a while OpenAI also shuts off older models through API but that's a central process.
What if I have Firefox 150 users that haven't updated yet and Firefox 155 users that have different models, while Chrome 160 and Chrome 170 users also exist and have different models. Is it expected that I build entirely different implementations for every browser version out there? Don't the work groups try to prevent exactly that within HTML & CSS through feature gating?
(Former Chrome team member who worked on this API, now retired.)
There was such a process! They shipped as first Dev Trial around 2025-04, then Origin Trial in 2025-05. Since then a number of people tried it and gave lots of feedback, leading to model quality improvements, language support expansion, API additions like structured responses and tool use, etc. You can find a lot of feedback and case studies if you search around.
Wow. I had no idea that people would misinterpret what I was saying in this way. I was not meaning to imply it was an expectation of users or developers. I was meaning it as a statement of what was currently a growing industry trend by OS and browser vendors, of shipping or preparing to ship LMs.
By now the statement could probably be amended from "expected to gain access to" to "shipping with".
I hope the team maintaining the project now makes such an update, since apparently it's confusing so many people!
I thought it was clear and am also surprised by the reaction (en-US speaker). "Is/are expected" is generally used as a passive-voiced form of "we/they predict" (obviously without having to specify a specific pronoun). E.g. "It's expected to rain tomorrow" means a weather forecast says it will rain tomorrow and usually not that people want it to rain tomorrow.
I wonder if this phrase has different connotations among other English readers? A lot of these comments are fairly early for US timezones.
I don't think US vs. non-US has anything to do with it. It's an ambiguous phrase, whose meaning is usually resolved by context.
"It's expected to rain tomorrow" is a prediction, whereas "students are expected to behave themselves" is an expectation (with consequences, presumably).
In the former case we clearly aren't saying we want it to rain, just that we believe it's likely, whereas in the latter example we are clearly expressing that we do want students to behave.
It's ambiguous because "expect" has two different meanings:
This is part of it, and also we just didn't want to use up the last of the user's disk space! It's disrespectful to use up 3 GB if the user only has 4 GB left; it's sketchy if the user only has 10 GB. At 22 GB, we felt there was more room to breathe.
One could argue that users should have more agency and transparency into these decisions, and for power users I agree... some kind of neato model management UI in chrome://settings would have been cool. But 99% of users would never see that, so I don't think it ever got built.
I no longer have any inside knowledge, but from my time on this team they were very quick about getting the latest small (Google) models into Chrome. I expect that if Gemma 4 (or its equivalent Gemini Nano) isn't already in Chrome, then it will be soon.
Note that the article here was last updated 2025-09-21, and as of that time it was already on Gemini Nano 3.
How do you envision short term and long term target usage of it?
And do you guys communicate between other browsers when doing something like this to try to settle on something common? I don't mean W3C but practically, it's a small world after all.
I can't speak for "you guys" anymore, as I'm retired, but from my personal perspective/recollection:
The target usage for the prompt API is anything that would benefit from the general capabilities of a language model, and can't be encompassed by the more-specific APIs for summarization/writing/rewriting. Realistic use cases currently are things like sentiment analysis, keyword extraction, etc. I have a number of ideas on how to integrate it into my current retirement project around Japanese flashcards, e.g. generating example sentences. If the small (~10 GiB) model class keeps getting smarter, the class of things possible on-device in this way gets larger and larger over time.
But overall, yeah, the goal with the prompt API, as with all web APIs, is to put something out there for discussion as early as possible, and get input from the broad community, especially including other browsers, to see if it's something that they are interested in collaborating on. https://www.chromium.org/blink/guidelines/web-platform-chang... (which I also wrote) goes into how the Chromium project thinks about such collaboration in general.
- Keep a small stdlib, like JavaScript (especially earlier JavaScript): everyone complains about missing features, warring communities form around jQuery promises vs. Promises/A+ vs. callbacks, supply chain attacks, left-pad/is-even dependencies, etc.
- Grow a big stdlib while keeping backward compatibility, like C++: lots of cruft left around that must never be used, sitting next to newer stuff with similar names. People complain about the bloat.
- Grow a big stdlib and then break backward compatibility, like Python 2 -> 3: everyone is sad, the ecosystem churns for years.
I admit there are probably better and worse versions of each strategy, e.g., it seems to me like JavaScript's slow-but-steady accretion of primitives over time has gone OK, and it seems like apart from Python 2 -> 3 some of the PEPs I see for deprecations and replacements are reasonable. But no language has ever hit on a strategy that everyone loves, as far as I can tell.
reply