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. 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. 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? 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 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. > > *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/standards-positions/issues/495) >>> >>> Web developers: Strongly positive ( >>> https://github.com/webmachinelearning/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/chromium.org/d/msgid/blink-dev/CAM0wra_LXU8KkcVJ0x%3DzYa4h_sC3FaHGdaoM59FNwwtRAsOALQ%40mail.gmail.com >>> >>> Intent to Experiment: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9oT0jygAYT00WPp0_wtZ-znrB2OdZ6GQb%2B3thFLP19pA%40mail.gmail.com >>> >>> Intent to Extend Experiment 1: >>> https://groups.google.com/a/chromium.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/chromium.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/chromium.org/d/msgid/blink-dev/c257bea5-b444-42ab-b195-4025930206f2%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/chromium.org/d/msgid/blink-dev/fd88dc6e-a5fd-4dfd-9a8a-78971c13d363n%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/CADsXd2NEafM%2BNsyDFMiDJ1z6m1SFe5jFt7dw3OEdAbPwYzys4g%40mail.gmail.com.
