Prompt API#1213
Prompt API#1213
concerns: interoperabilityposition: negativetopic: APIvenue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG)Specifications in W3C Community Groups (e.g., WICG, Privacy CG)
Description
opened on Apr 28, 2025
Contributor
Specification title
Prompt API
Specification or proposal URL (if available)
No response
Explainer URL (if available)
Proposal author(s)
MDN URL
No response
Caniuse.com URL
No response
Bugzilla URL
No response
Mozillians who can provide input
No response
WebKit standards-position
No response
Other information
Blink just published an intent-to-prototype.
👍React with 👍7 arif891, welliton-seekmaro, sgbeal, Heliodex, siddharth-kulkarni-cs and 2 more👎React with 👎138 thebabydino, dionrhys, bivens-dev, hexaclue, SuNNjek and 133 more👀React with 👀3 stefnotch, t-morisawa and roke-julian-lockhart
Activity
added this to standards-positions reviewon Apr 28, 2025
moved this to Unscreened in standards-positions reviewon Apr 28, 2025
mentioned this in 2 issues on May 14, 2025
bgrins commented on May 20, 2025
Member
Our feedback here is largely the same as with the writing assistance APIs in #1213. In addition, the more general shape of this API has utility, but encourages model-specific behavior that increases interoperability risk. Developers will likely want fine-grained control over prompts and other features based on the model, in which case they would build for particular implementations — for example, Phi-4-mini in Edge — which would lead to worse behavior with other browsers or models (or sites blocking access).
As before, we think this needs much more baking in userland before web APIs are shipped. In addition to our trial web extension API, we’ve since raised a proposal within the web machine learning group to ship a web extension that exposes a Prompt-like API to pages with local inference with developer-specified models, as a way to offer shared model storage and gather feedback from early adopters.
👍React with 👍98 alex-kinokon, sgbeal, bvoigtlaender, maeln, forkrul and 93 more👎React with 👎1 arif891
domenic commented on May 20, 2025
Contributor
Thanks for the quick response! And yeah, we're on board with the web extension idea as well, although from what we've heard from web developers that'll probably be most useful for smaller models (e.g. sentiment classification).
I'm particularly curious to learn more about what you see as the difference between using a web extension to gather that feedback, vs. using an origin trial-type mechanism to gather feedback.
bgrins commented on May 22, 2025
Member
I'm particularly curious to learn more about what you see as the difference between using a web extension to gather that feedback, vs. using an origin trial-type mechanism to gather feedback.
Two things:
- Being able to select an exact model from a model hub is a key feature —both for in-page functionality, and because it’s not good for browsers to pick winners at this point — but implies a number of implementation details in a fast-moving space which aren’t ready to be standardized. An extension is a relatively low stakes way to quickly explore real-world use cases beyond what current proposals allow, and to get functionality working across browsers without the coordination cost of having three engine implementations ship the same (not fully-baked) semantics.
- Installing an add-on indicates to the user that they are stepping outside the bounds of normal web functionality (in this case shared cross origin storage). Similar logic to Add position for WebMIDI (Add-On Gated)#704, in a different context.
👍React with 👍27 sgbeal, XYenon, Hendrikto, YounessFkhach, ghishadow and 22 more
mentioned this on Jun 3, 2025
bgrins commented on Jun 6, 2025
Member
Marking as negative - with relevant discussion here and in #1067
👍React with 👍9 Hendrikto, bivens-dev, eranimo, ISSOtm, spartanatreyu and 4 more
mentioned this on Jun 10, 2025
michaelwasserman commented on Apr 3, 2026
Chrome Prompt API folks have sent a blink-dev I2S with some updated thoughts regarding Interoperability and compatibility risks.
We'd appreciate keeping discussion and WebML CG engagement alive, as it also pertains to followup experimentation for more interoperable sampling parameters and other early-stage explorations, even if the overall Prompt API sentiment remains negative.
Is there anything you can report from the first year of related web extension experimentation?
👎React with 👎3 colinstu12, Edescal and Valadramuz
mentioned this on Apr 9, 2026
jakearchibald commented on Apr 29, 2026
Last edited by jakearchibald
Member
We continue to oppose this API, and feel it has severe negative consequences to the interoperability, updatability, and neutrality of the web platform.
Calcifying around a single model
When crafting a system prompt, you tend to iterate based on the quirks of the model you're working with.
A personal example: I created a system prompt for creating announcements for a home automation system. The Gemini model I was using initially responded in a very US-American way, which didn't fit the British voice of my speaker. I told the model, via the system prompt, that the output was being spoken in a British voice, but the result was a bad US-American impersonation of British ("a'waight guv'nor apples and pears" etc etc), so I had to iterate further to 'tone it down' and speak actual British.
In this process, the system prompt becomes tailored to the model. Other models will have different quirks. Things added to the system prompt for one model may be an overcorrection for another.
Because of this, we will easily end up in a situation where a new competing model, even if superior to existing models, will be perceived negatively by developers/users, because the system prompts in the wild are designed for the quirks of the existing models, and therefore produce a worse result with the new model.
This will result in Mozilla and Apple having to licence Google's model, or ship a model that's quirks-compatible with the Google model in order to be interoperable. It may also become difficult for Chrome to update its own model for the same reasons.
Developers who are experienced enough to see this coming, are likely to do something like this:
undefinedjs const model = await LanguageModel.create(); const modelType = await model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string'); // 'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind' undefined
…and create a suite of system prompts that are designed for particular models. Perhaps blocking unrecognised models, or warning the user that their output may be inferior.
This is a throwback to early-2000s code branching that we shouldn't be sleepwalking back into.
Lack of model neutrality
According to Chrome's documentation, to use the prompt API you must 'acknowledge' Google's Generative AI Prohibited Uses Policy. Elements of this policy go beyond law. For example:
Do not engage … generating or distributing content that facilitates … Sexually explicit content
Do not engage in misinformation, misrepresentation, or misleading activities. This includes … Facilitating misleading claims related to governmental or democratic processes
This seems like a bad direction for an API on the web platform, and sets a worrying precedent for more APIs that have UA-specific rules around usage.
To give a more specific example, if a user of a website clicks "summarize" on a comment of an article, such that Google's Generative AI Prohibited Uses Policy is violated, who is Google going to go after?
- The user - because they clicked "summarize", which initiated the action that violated the policy, on their machine.
- The author of the comment - because they wrote the content that violated the policy.
- The owner of the website - because they created the facility to feed the violating comment to the user's UA's LLM.
Because of this, the developer will want to know which LLM they're talking to, so they can comply with its associated T&Cs, and avoid the owner of the model taking legal action against them. So again, experienced developers will query the model for its 'ID', and tailor usage to known models.
If the model is unknown to the developer, that means there are potentially unknown T&Cs. The only smart thing to do in this case is for the developer to block usage. Obviously this severely harms interoperability.
Overstated web developer position
The intent to ship on blink-dev states web developers as "Strongly positive", and links to the explainer for evidence.
The evidence provided there does not seem to fit the claim:
- A GitHub thread with two positive responses
- A single post on X
- A blog post that no longer exists (Server Not Found)
- A blog post that still exists
- A survey that seems to have asked if developers would be happy for this API to exist in extensions. The numbers involved in this survey, or who was given the survey, are not stated.
👍React with 👍936 sgbeal, rubyFeedback, randombit, martin-juul, joshhunt and 931 more😄React with 😄4 wilsonsilva, thdaraujo, mr-cheffy and NaveenPNair🎉React with 🎉1 NaveenPNair❤️React with ❤️135 mochienya, ginocingolani, EntityDeleter, glukki, ISSOtm and 130 more🚀React with 🚀1 NaveenPNair👀React with 👀34 EDM115, crutchcorn, deebloo, lynnntropy, fry69 and 29 more
mentioned this on Apr 30, 2026
24 remaining items
othermaciej commented on May 1, 2026
I am not aware of major existing or emerging native apps that access LLMs via a strategy like this:
Use one of a set of canned downloadable models chosen by the platform vendor and accept the luck of the draw on what you get on different platforms.
Do you know of any?
Apple's Foundation Models framework and Android's ML Kit are examples from native application platforms.
This isn’t really responsive to my question. Is there a notable cross-platform mobile app that uses AFM on iOS and ML Kit on Android for gen AI capabilities? It’s definitely not how chatbot super apps are built…
👍React with 👍5 dontwanttothink, lynnntropy, lobau, adrienne and Ma-ve
maceip commented on May 1, 2026
why even continue this charade?
chrome will ship it, mozilla might, safari afk.
as a developer it would have been nice if the three of you could have worked together to evolve a core set of features such that a web user could make the decision you are commenting on here.
instead, we have to manage your disagreement:
navigator.ml.createContext
window.ai.availability
browser.ml.chat.provider
<safari still working on paymentHandler>
the signal couldn't be any clearer: developers are not your constituents. when the two darlings of the current hype cycle put out their flagship "apps" , apps that could have been web, but they shipped CEF/Electron?! smdh. i cant blame them. you arent running a standards process -- its something else entirely. but there is hope; folks do care and work across the aisle:
| Draft / Working Group | Primary Collaboration | Core Focus |
|---|---|---|
| Privacy Pass | Google, Apple, Cloudflare | Anonymous tokens to bypass CAPTCHAs |
| MASQUE | Apple, Google | Proxying traffic for Privacy Relays |
| DAP (PPM) | Cloudflare, Google | Privacy-safe telemetry and measurement |
| Oblivious HTTP | Cloudflare, Apple, Google | Hiding IP addresses from target servers |
👍React with 👍1 adrienne👎React with 👎24 thebabydino, TheThing, SuNNjek, flipeador, Lehoczky and 19 more
shaedrich commented on May 1, 2026
Last edited by shaedrich
Draft / Working Group Primary Collaboration Core Focus Privacy Pass Google, Apple, Cloudflare Anonymous tokens to bypass CAPTCHAs MASQUE Apple, Google Proxying traffic for Privacy Relays DAP (PPM) Cloudflare, Google Privacy-safe telemetry and measurement Oblivious HTTP Cloudflare, Apple, Google Hiding IP addresses from target servers
Sorry, but attesting any genuine interest in privacy-safe anything to Google is just laughable—unless you unironically subscribe of the idea of a Google village.
👍React with 👍10 quassy, F1r3f0x, cyberalien, ELtd, aniforprez and 5 more
reillyeon commented on May 1, 2026
Last edited by reillyeon
This isn’t really responsive to my question. Is there a notable cross-platform mobile app that uses AFM on iOS and ML Kit on Android for gen AI capabilities? It’s definitely not how chatbot super apps are built…
Chatbot super apps (and I'm assuming you mean examples like ChatGPT and Claude here) are in a completely different category because they're using a server-side model. Once you're calling out to the server you aren't constrained to the limited RAM, compute and disk available on the device and can pick your model.
Edited to add: There's an open question on whether a browser should always use the OS-provided model if available. I think this is definitely true on more constrained mobile platforms (and this is Chrome's plan for Android). On desktop I think it's more reasonable for the browser to be opinionated, provide its own models, and amortize that cost across all of the sites that use them. That could also be a user choice.
I don't have access to information on which apps use these two native APIs but I did find this article about a company that is building cross-platform apps using these frameworks.
In addition to cross-platform applications I want to highlight that even for a developer only targeting one platform the "luck of the draw" still applies because neither framework guarantees that they're always going to be using the same model.
👍React with 👍1 michaelwasserman
mentioned this on May 1, 2026
chrisvls commented on May 4, 2026
Last edited by chrisvls
As a commercial application developer, there are some use cases for local models. The shape of this API conforms to Google's imperatives as a competitive model provider, not to mine as a product builder. Our experience is that prompts and models are tightly bound (not for lack of trying, we tried having prompts be model agnostic, results were not sub-optimal to bad). Our experience is that model behavior and quality on a specific use case is high variance. So we expect to change prompts and models frequently. As someone who has dealt with browser-specific quirks for 25 years, this is a different beast.
The legal questions are critical. If I can't discover the model and its terms and conditions, then I will have to provide the model. I am responsible for the results, with reasonable disclaimers. I can't indemnify reasonably against any model in the universe.
For all of these reasons, this experiment seems to favor model lock-in at the cost of application quality and, thus, user experience.
It is not clear that a standard is desired, given the above and the ability to roll our own. If we wanted a standard, it would include methods for interrogating the browser to see if a specific model was already on board, prompting the user if they want to download it if it is missing, browser ui that presents them with a link to terms, and offering a same-origin promise that the user agent will not disclose my app's inputs/outputs/choices to other origins, including the model provider.
👍React with 👍10 alkihis, cassidyjames, Eiim, Chudesnov, lobau and 5 more
chrisvls commented on May 4, 2026
why even continue this charade?
FLOCK and then Topics ultimately didn't ship. Maybe this discussion helps this idea go the right way.
venue: W3C CG Specifications in W3C Community Groups (e.g., WICG, Privacy CG)Specifications in W3C Community Groups (e.g., WICG, Privacy CG)
moved this from Unscreened to Position is proposed in standards-positions reviewon May 5, 2026
closed this as completedon May 5, 2026
othermaciej commented on May 8, 2026
Edited to add: There's an open question on whether a browser should always use the OS-provided model if available. I think this is definitely true on more constrained mobile platforms (and this is Chrome's plan for Android). On desktop I think it's more reasonable for the browser to be opinionated, provide its own models, and amortize that cost across all of the sites that use them. That could also be a user choice.
To be clear, I'm using OS models as an analogy for browser-provided models, since others have cited AI-powered apps on native platforms as a reason to urgently ship this API. In this analogy, it doesn't really matter whether the model is chosen by the OS or by the browser, just that the developer doesn't know what they are going to get. The question is just whether native apps find "get an unknown platform-provided model" to be a valuable capability, so much so that it is urgent to ship such an API to the web ASAP.
I don't have access to information on which apps use these two native APIs but I did find this article about a company that is building cross-platform apps using these frameworks.
Thanks for providing the example. I concede more than 0 apps have done this. However, despite the article's claims to hit # 1, I could not find the app in the top 200 on the App Store for Music, indeed I could not even find it searching for its own name in the App Store app. So I'm not sure how much stock we should put in the relevance of this data point. They did use this strategy for an auxiliary purpose (prompt refinement presumably before sending to their probably server-side main model) but it's unclear if it was effective.
👍React with 👍2 shaedrich and adrienne
CandelaGreen commented on May 9, 2026
Last edited by CandelaGreen
Hermes Agent with Qwen3.6 has been able to do most of these tasks for me. Instead the browser automation API needs more attention and Lynx mode for chat needs to come back.
In several of my workflows there is a human component (manually logging in to the website and doing AJAX expansion to make files visible), followed by the agent downloading/tagging/summarizing documents via chromedriver/webdriver. This could be unified in the browser without having an external POSIX shell.
- Lynx mode chat. The web has become a tire fire of complexity with too many cookies and too much javascript. All browsers should support a Lynx mode to quickly expose what agents are seeing, and for agents to browse in chat without needing to download and render every media asset to save both sides resources.
A better robots.txt at the HTML level. Robots.txt is too generic as it just deals with whole files. We need a more fine-grained robots tagging within a web page to note certain actions should be human only, or at least better design for the blind human/agent that doesn't need to download/render large image files.
Handoff between Lynxmode shell and traditional browser. Sometimes I want my Lynx shell chat to be in a different context, sometimes I want it to be in the same context as the web browser tab that is open. (Prompt API#1213 (comment))
I agreed with you until you mentioned ads.
AdWords (generically). I'm not sure if Jeff Dean ever turned this into a RFC, but agent driven browsers should be able to get a small list of old school Google AdWord style links and optionally render them for the person driving the agent. Display it off to the right of the Lynx shell as opt-in for those who respect advertising revenue driven content. (#1213 (comment))
mentioned this on May 14, 2026