Thank you for your responses. LGTM2
Thanks, Vlad On Tue, Apr 7, 2026 at 7:16 PM Mike Wasserman <[email protected]> wrote: > > > On Tuesday, April 7, 2026 at 12:43:45 PM UTC-7 Rick Byers wrote: > > On Tue, Apr 7, 2026 at 3:00 PM Mike Wasserman <[email protected]> wrote: > > See responses inline, thanks! > > On Tuesday, April 7, 2026 at 7:45:10 AM UTC-7 Vladimir Levin wrote: > > On Mon, Apr 6, 2026 at 6:04 PM Mike Wasserman <[email protected]> wrote: > > *Regarding TAG review status:* > The scope of issues raised is broad. We conducted thoughtful > google-internal reviews <http://go/prompt-api-internal-tag-review> and > triage <http://go/prompt-api-internal-tag-triage>, and prioritized > addressing issues that couldn't be addressed after launch by > backwards-compatible spec and implementation changes. In that regard, > sampling parameters are not part of this initial launch proposal, and > various API identifiers have been renamed. > > > Thanks Mike. From the triage doc I see there were three ship blockers > identified and now addressed: > [Tag Review] - Quota vs. context window > <https://github.com/webmachinelearning/prompt-api/issues/177> > [Tag Review] - Interoperable model parameters > <https://github.com/webmachinelearning/prompt-api/issues/170> > measureInputUsage includes <model> start response token > <https://issues.chromium.org/issues/481450143> > > I agree the others are non-blocking. Thank you! Broadly from all the > public dialog and collaboration I've seen I trust you and the team to keep > investing in the tricky tradeoffs here and expanding the industry > alignment. So this is good enough for me for now. > > Is the explainer up-to-date with the proposed changes? I'm struggling to > understand exactly what will ship if this intent is approved. As an aside, > the explainer starts with "This proposal is an early design sketch ...", > which I suspect should be updated to indicate that this is close to > shipping. > > > Thanks for this question. While we've kept many aspects of the explainer > updated with changes for the initial web platform API launch, we've also > been representing enhancements slated for experimentation after the initial > launch (e.g. tool use, sampling parameters), and other parts have grown > stale. I'm preparing an explainer PR to update and clarify this document in > the next day or two. > > > Also in the explainer: "The following features have been recently renamed. > The legacy aliases are deprecated, and clients should update their code > ...". Was this an OT or developer trial or just people trying this out? > > > The API has been in Web Origin Trial from Chrome 139 (August 2025), and > launched general availability for Chrome Extensions in Chrome 138 (June > 2025). TAG feedback > <https://github.com/w3ctag/design-reviews/issues/1093#issuecomment-3515070512> > provided > in Nov 2025 suggested these renames; spec > <https://github.com/webmachinelearning/prompt-api/pull/192> and impl > <https://issues.chromium.org/issues/481707656> renames were performed in > Feb 2026. Their legacy aliases are deprecated in extension contexts and > will be removed in due course to align with the Web API. > > > Generally, I agree that we should ship something in this space like this > API so thank you for working on this! I'm a little worried about stability > of the API shape though. Specifically, I'm wondering if we've had developer > feedback on the shape of the API and that it accomplishes the needed goals. > Can you comment on this? As a concrete example, specifying "role" as > hard-coded strings either "user" or "assistant" seems a little brittle to > me as compared to some declared constant in LanguageModel. Again, I'm not > suggesting that these should change, but simply asking if real-world > developers had a chance to explore this feature and provide feedback > > > We believe API shape has stabilized through comprehensive experimentation > phases (lengthy Extension+Web Dev Trial, early partner programs and > hackathons, Extension Origin Trial and GA Launch, extended Web Origin > Trial), and is ready for shipping to the open Web in Chrome. Most developer > feedback about the API shape was in early Dev Trial stages, which > precipitated many improvements for ergonomics and extensibility, reflected > in commits > <https://github.com/webmachinelearning/prompt-api/commits/main/> during > the first half of 2025 by our retired spec editor. These included the > addition of an append() method, message and content sequence refinements > (e.g. interleaving multimodal content of the same role), continued support > for `prompt("write a poem")` shorthand, and more. > > Since then, many real world developers have integrated this API in real > sites and exploratory demos, while others have built polyfills and > incorporated use in JS toolkits. We've additionally solicited feedback > through additional channels (e.g. devtools console messages on session > creation), and recent API shape feedback has generally been positive; no > issues have been raised regarding the LanguageModelMessageRole enum and its > use in the LanguageModelMessage dictionary. Our team is happy to continue > discussing any thoughtful feedback through issues filed in the spec > repository or Chromium issue tracker. > > > Thanks! > Vlad > > > We still need to respond to the rest; some touch on inherent risks of > platform advancements in this nascent domain; many could benefit from > outlining non-normative best practices for implementers to respect device > resources and real world costs. We will expedite sharing those responses. > > *Regarding wpt.fyi test failures:* > Almost all failures are model download timeouts; we hope to devise a way > to retain or sideload models in wpt.fyi's continuous integration > infrastructure. > > > Thanks. Do you have a report of some kind about what's passing vs. failing > in a harness that avoids the model download issue? I ran a few of the tests > myself manually (on wpt.live) and they passed. So I'm assuming we're > broadly in good shape, right? Just want to know details (a few known > failures with bugs is fine). > > > Thanks for asking. Internally, we have a separate python script that > side-loads pre-downloaded models and configurations to run WPTs on Chrome > builds, those are run continuously on FYI internal.optimization_guide > <https://ci.chromium.org/p/chrome/g/internal.optimization_guide/console> "wpt > bots" with a separate set of /third_party/blink/web_tests/AIExpectations > <https://crsrc.org/c/third_party/blink/web_tests/AIExpectations>, which > enumerates known failures (inherent side-loading availability values, and > hopefully solvable platform-specific timeouts). There's a single new > Mac-x64 failure there that I've been meaning to address this week. > > I also took the liberty of manually running the 28 WPT files in > https://wpt.live/ai/language-model/ on Chrome Canary and observed: 90/95 > tests pass that pertain to proposed stable API surfaces. Two failures are > missing `gc()` WPT method references, two pertain to multimodal session > creation, and the last is a context usage measurement OBO. I will file > issues and followup with all of these. There are another 43 tests related > to experiments for params and tool use that aren't part of the initial API > launch. > > > *Regarding conformance testing and benchmarks / eval suites:* > Web platform tests should continually expand to include more substantive > conformance coverage, ideally including support for more objective analysis > of natural language. We have also conducted initial research > <https://docs.google.com/document/d/16r6Rdw-yomYu1GBce12IMLqrM8sVAX2Wy9YytbTlh3Q/edit?tab=t.0#heading=h.yzph7ln63fw4> > on cross-browser interop and are collaborating on followups, including > Microsoft fixing several bugs and planning model training around those > shared use cases of interest. Microsoft collaborators also explored a very > rough quality benchmark > <https://sushanthr.github.io/PromptAPI/quality.htm>. We are also > discussing internally and with partners about use cases and data sets that > can be shared publicly and use to represent performance baselines on > different representative devices. We don't have yet a formal open/public > discussion yet, but we have been iterating on some eval tests, e.g. > https://web-ai.studio/cortex. We will continue to iterate and engage with > the goal of formalizing open quality and performance eval suites. > > *Adding color to the "strongly positive" web developers feedback > statement:* > We have run a number of hackathons, especially the Google Chrome Built-in > AI Challenge 2025 <https://googlechromeai2025.devpost.com/>, and have a > good number of engagement from specific partner explorations. We also get > anecdotal positive organic signals from press articles, forum threads, and > direct > feedback <https://github.com/webmachinelearning/prompt-api/issues/200>. > > On Monday, April 6, 2026 at 1:23:22 PM UTC-7 Rick Byers wrote: > > On Fri, Apr 3, 2026 at 3:53 PM Mike Taylor <[email protected]> wrote: > > LGTM1 > > The only thing I was going to request was already taken care of: pinging > the Mozilla issue and providing a pointer to this thread (since it's been > about a year - maybe their position has evolved). > On 4/1/26 6:57 p.m., Deepti Bogadi wrote: > > Contact emails > > [email protected], [email protected], [email protected], > [email protected] > > Explainer > > https://github.com/webmachinelearning/prompt-api/blob/main/README.md > > Specification > > http://webmachinelearning.github.io/prompt-api > > Summary > > The Prompt API gives web developers direct access to a browser-provided > on-device AI language model. The API design offers fine-grained control, > aligned with cloud API shapes, for progressively enhancing sites with model > interactions tailored to individualized use cases. This compliments > task-based language model APIs (e.g. Summarizer API), and varied APIs and > frameworks for generalized on-device inference with developer-supplied ML > models. The initial implementation supports text, image, and audio inputs, > as well as response constraints that ensure generated text conforms with > predefined regex and JSON schema formats. > > This supports a variety of use cases, from generating image captions and > performing visual searches to transcribing audio, classifying sound events, > generating text following specific instructions, and extracting information > or insights from multimodal source material. > > This API has already been shipped in Chrome Extensions; this intent tracks > the shipping on the web. An enterprise policy > GenAILocalFoundationalModelSettings > <https://chromeenterprise.google/policies/#GenAILocalFoundationalModelSettings> > is available to disable the underlying model downloading, which would > render this API unavailable. Enterprise admins can also set the > BuiltInAIAPIsEnabled policy to block Built-In AI API usage, while still > permitting other on-device GenAI features. > > Language support log: > > - > > Chrome M139 and earlier only supported English ('en') > - > > Chrome M140 added support for Spanish and Japanese ('es' and 'ja') > > > > Blink component > > Blink > AI > Prompt > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%20%3E%20AI%20%3E%20Prompt%22> > > Web Feature ID > > https://github.com/web-platform-dx/web-features/issues/3530 > > Motivation > > Direct access to a language model can help web developers accomplish tasks > beyond those with dedicated APIs (e.g. Summarizer API) , and tailor their > usage for site-specific requirements. Compared to the low-level APIs > approach (e.g a custom AI model run via WebGPU, WASM, or WebNN), using the > built-in language model can save the user's bandwidth and disk space, and > has a lower barrier to entry. The design offers simple shorthands for > common patterns (e.g. await session.prompt(‘write a haiku’)), and > supports more complex use cases for handling structured content sequences, > streaming responses, availability checks, session management, and response > constraints. > > Initial public proposal > > https://github.com/webmachinelearning/charter/pull/9 > > Search tags > > LanguageModel <https://chromestatus.com/features#tags:LanguageModel>, Language > Model <https://chromestatus.com/features#tags:Language%20Model>, Prompt > API, Built-in AI > > TAG review > > https://github.com/w3ctag/design-reviews/issues/1093 > > TAG review status > > Issues addressed > > Can you elaborate on this? I see 14 issues > <https://github.com/webmachinelearning/prompt-api/issues?q=label%3A%22tag-tracker%22> > were filed in the spec repo based on TAG feedback, but all are still 'open' > with little comment. As you mentioned below, the interoperable model > parameters <https://github.com/webmachinelearning/prompt-api/issues/170> > one was addressed by leaving these as "experimental", so I assume they are > not covered by this I2S. > > Many of these issues don't seem particularly actionable to me - they > represent inherent risks in this space which, personally, I think we should > be comfortable taking, learning from and iterating on post-ship. It's fine > to disagree with TAG on this (especially since even TAG couldn't agree > among themselves - the issue is formally 'lacks consensus'). But maybe > there are still one or two things we should be doing now to reduce future > interop risk? > > Can you do a triage pass over the issues and flag which are fine to leave > for future consideration (as a non-breaking enhancement), which have been > mitigated for now (eg. model params), and which are ones the group just > disagrees with and wants to close? If there are any which seem like they > have a good chance of leading to future interop risk, just call those out. > Personally interop risk here seem unavoidable and I appreciate the amount > of effort that's gone into collaborating between two different > implementations (Google and Microsoft). Given the developer demand I do > think we should be shipping, I just want the transparency of being clear on > our thinking at this point to maximize learning. > > WebFeature UseCounter name > > kLanguageModel_Create > > Risks > > Interoperability and Compatibility > > The Prompt API is designed to provide a stable and interoperable surface > for language model interactions, acknowledging the inherent diversity and > non-deterministic nature of underlying models. Variance in behaviors and > responses is a well understood expectation amongst developers employing > this technology, and this API aims to provide an interoperable framework > for consistent web platform access across browsers and models. > > The Prompt API specifically aims to maximize compatibility by: > > - Codifying an interoperable API surface for generalized language model > interactions, so developers can write code that works across different > browser engines and models. This surface has demonstrated compatibility > with models from Google and Microsoft, and been polyfilled by extensions > and JS frameworks, using different backends. > > - Enforcing objective response conformance with constraints that ensure > output adheres to known JSON schemas or regexes for interoperable > processing of generated text. > > - Supporting progressive enhancement patterns, by offering availability > signals that encapsulate device and model support dimensions, and encourage > developers to consider this API as one option among varied compatible AI > offerings, including developer supplied models and cloud-based services. > > Shipping this API provides a critical opportunity to broaden real-world > implementation experience, explore future refinements, and collaborate with > the web community on interoperable model diversity within a robust, > predictable platform surface. > > Agreed, thank you! > > Gecko: Negative (https://github.com/mozilla/standards-positions/issues/ > 1213) > > WebKit: No signal (https://github.com/WebKit/sta > ndards-positions/issues/495) > > Web developers: Strongly positive (https://github.com/webmachine > learning/prompt-api/blob/main/README.md#stakeholder-feedback) > > Other signals: Microsoft Edge developers have been strong collaborators > with notable contributions including structured output, and experimental > tool use enhancements. Edge will be shipping this API using a different > underlying model. > > Ergonomics > > The API deprecated parameters and renamed identifiers, leaving legacy > access for previously launched extension contexts. We plan to align the web > and extension surfaces through careful additive changes and cautious > deprecation processes. Developers are encouraged to use the new identifier > names in both contexts and observe deprecation messages regarding planned > API alignments. > > Activation > > This feature would definitely benefit from having polyfills > <https://www.npmjs.com/package/prompt-api-polyfill>, backed by any of: > cloud services, lazily-loaded client-side models using WebGPU/WASM/WebNN, > or the web developer's own server. We anticipate seeing an ecosystem of > polyfills and client frameworks grow as more developers experiment with > this API. > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > Not Applicable; this API is not available in WebView. > > > Debuggability > > The API surface supports basic DevTools debugging. Perfetto tracing (via > optimization_guide and other events) is useful, and internal debugging > pages which give more detail on the model's status, e.g. > chrome://on-device-internals might be suitable to port into DevTools. The > team is maintaining extensions > <https://chromewebstore.google.com/detail/webai-extension/lmjgpcigjcffnphimblhcoccjfefamcp> > of DevTools panels for improving debuggability. It is possible that giving > more insight into the nondeterministic states of the model, e.g. random > seeds, could help with debugging. > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > > No > > The initial launch focuses on Windows, Mac, Linux, and ChromeOS (on Chromebook > Plus <https://www.google.com/chromebook/chromebookplus/> devices). An > implementation for Android using that platform’s OS-level built-in language > model is being prototyped and will ship after the initial launch. > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > No > > Web platform tests cover the API surface adequately: > https://wpt.fyi/results/ai/language-model These attempt to mitigate > execution environments differences, e.g. stub/full implementations > (content_shell, chrome), and device/model states (unavailable, > downloadable, downloaded). > > Yeah that's probably the most we can ask for in this intent. However most > of these tests appear to be failing on wpt.fyi. Can you please triage all > the failures on wpt.fyi and either fix them so they're passing or explain > why the failure doesn't represent a real interop issue? > > The core responses of real models can be unpredictable (especially without > sampling parameters) and may cause inconsistent test results, but some > facets are more readily testable, e.g. the adherence to structured output > response constraints. Test coverage and reliability improvements are > ongoing, including planning for WebDriver extensions. > > Are there tracking issues in the CG regarding conformance testing that you > can point to? Are there discussions somewhere around benchmarks / eval > suites? Just like with our other big non-determinstic area of competition > in browsers, web performance, having open benchmarks can be very useful for > promoting compatibility. > > > DevTrial instructions > > https://developer.chrome.com/docs/ai/prompt-api > > Flag name on about://flags > > prompt-api-for-gemini-nano-multimodal-input > > Finch feature name > > AIPromptAPIMultimodalInput > > Rollout plan > > Will ship enabled for all users > > Requires code in //chrome? > > True > > Tracking bug > > https://crbug.com/417526788 > > Launch bug > > https://launch.corp.google.com/launch/4461863 > > Measurement > > The API has use counters for all methods and attributes e.g.: > LanguageModel_Create LanguageModel_Availability LanguageModel_Prompt > LanguageModel_PromptStreaming LanguageModel_Append LanguageModel_ > MeasureContextUsage LanguageModel_OnContextOverflow > LanguageModel_ContextUsage LanguageModel_ContextWindow LanguageModel_Clone > LanguageModel_Destroy > > Non-OSS dependencies > > Does the feature depend on any code or APIs outside the Chromium open > source repository and its open-source dependencies to function? > > Yes: this feature depends on a language model, which is bridged to the > open-source parts of the implementation via the interfaces in > //services/on_device_model. > > Estimated milestones > > Shipping on desktop > > 148 > > Origin trial desktop first > > 139 > > Origin trial desktop last > > 144 > > Origin trial extension 1 end milestone > > 147 > > DevTrial on desktop > > 137 > > > Anticipated spec changes > > Open questions about a feature may be a source of future web compat or > interop issues. Please list open issues (e.g. links to known github issues > in the project for the feature specification) whose resolution may > introduce web compat/interop risk (e.g., changing to naming or structure of > the API in a non-backward-compatible way). > > Params may be re-added after addressing interop concerns: > https://github.com/webmachinelearning/prompt-api/issues/170 Identifiers > have been renamed for clarity before Web GA launch: https://github.com/ > webmachinelearning/prompt-api/issues/177 Any post-launch additive changes > should be backwards compatible: e.g. tool use, multimodal sampling > info/options and outputs, session history access, model info/options, etc. > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/5134603979063296?gate=5123192519393280 > > Links to previous Intent discussions > > Intent to Prototype: https://groups.google.com/a/ch > romium.org/d/msgid/blink-dev/CAM0wra_LXU8KkcVJ0x%3DzYa4h_sC > 3FaHGdaoM59FNwwtRAsOALQ%40mail.gmail.com > > Intent to Experiment: https://groups.google.com/a/ch > romium.org/d/msgid/blink-dev/CAM0wra9oT0jygAYT00WPp0_wtZ- > znrB2OdZ6GQb%2B3thFLP19pA%40mail.gmail.com > > Intent to Extend Experiment 1: https://groups.google.com/a/ch > romium.org/d/msgid/blink-dev/CAJcT_ZhyheBntZHMEwFJA%3DuhpkWmDx8yFieL5E5g% > 2Bwp5UA0mzQ%40mail.gmail.com > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit https://groups.google.com/a/ch > romium.org/d/msgid/blink-dev/CAJcT_Zj73wjXZfmMcpQRWePp-H% > 3D5LzxYBOnasViYcn%3DFzY2vVQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJcT_Zj73wjXZfmMcpQRWePp-H%3D5LzxYBOnasViYcn%3DFzY2vVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion visit https://groups.google.com/a/ch > romium.org/d/msgid/blink-dev/c257bea5-b444-42ab-b195-402593 > 0206f2%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c257bea5-b444-42ab-b195-4025930206f2%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion visit https://groups.google.com/a/ch > romium.org/d/msgid/blink-dev/fd88dc6e-a5fd-4dfd-9a8a-78971c > 13d363n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fd88dc6e-a5fd-4dfd-9a8a-78971c13d363n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25e6f203-87b6-4844-9edf-fa301ad36e3an%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25e6f203-87b6-4844-9edf-fa301ad36e3an%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2OZS%3Djn7CfH8AmkA9a%2BXf-fuP5wXyMQUb73DCuPUgLnFA%40mail.gmail.com.
