>From a procedural point of view I don't personally think we should be considering flagging this off at this stage. It already went out in our early stable release last week and will be deployed to all Chrome stable users in a matter of days. Using a kill switch at this late stage is generally reserved for emergencies to mitigate significant user harm (and comes with its own risks, since we have not been testing the off state in our canary/dev/beta population). While the strength of the Edge team's concern is apparently a surprise, I don't think there's actually any significant new information about the cost/benefit risk tradeoff here.
Instead I suggest we try to focus on finding and fixing any interop issues in practice. As I said on the Mozilla standards position thread, I'm personally supportive of Chrome making breaking changes where necessary to break calcification around model-specific quirks (as we've done in the past in the name of interop, eg. when fixing WebKit border image quirks, breaking mobile Gmail in order to match the spec and Firefox). Reilly says the team is working to share more developer signals. Once we have some real-world use cases to point at we can focus together on driving interop in practice. I'll note that there's some parallels here to how the browser community approaches performance - the one big longstanding aspect of probabilistic platform behavior (alongside snaller examples like the web speech API). Most applications aren't that sensitive to performance differences, and I expect the same here (but could be wrong!). But for some applications, a performance difference can mean the difference between an app being usable or not. Browsers largely compete on performance implementations but collaborate on benchmarks and API design. It has its downsides, but I think it's also done a lot of good to drive user-positive innovation and investment through constructive competition. Rick On Fri, May 1, 2026, 12:04 p.m. Reilly Grant <[email protected]> wrote: > On Thu, Apr 30, 2026 at 2:19 PM Alex Russell <[email protected]> > wrote: > >> Hey folks, >> >> First, an apology: I've had concerns about this API for a long while but >> simply missed that we had 3 LGTMs for 148. We're now hours from branch, and >> it would be pretty anti-social to -1 at this point. However, I think we >> need to consider finching the Prompt API off for 148 and moving back to OT >> for a few reasons. >> >> First, none of the OT feedback I've seen, or engagement that the Edge >> team has separately had with developers, suggests that an unversioned >> multi-modal client-side model will be able to avoid serious application >> breakage if used as the basis for core app functionality. I've mentioned to >> various folks overthe past year+ that it would be useful if we had a way to >> call out capabilities, versions, or other parameters at construction time, >> but the spec doesn't seem to have any discussion of that flexibility today: >> >> >> https://webmachinelearning.github.io/prompt-api/#dictdef-languagemodelcreateoptions >> >> > > The parameters in LanguageModelCreateCoreOptions > <https://webmachinelearning.github.io/prompt-api/#dictdef-languagemodelcreatecoreoptions> > (in particular, expectedInputs and expectedOutputs) which can be passed to > both availability() and create() allow the developer to check for the > availability of and request both language support and multi-modality > capabilities. For example: > > const session = await LanguageModel.create({ > > expectedInputs: [ > > { type: "text", languages: ["en"] }, > > { type: "audio" }, > > { type: "image" }, > > ], > > expectedOutputs: [{ type: "text", languages: ["en"] }], > > }); > > This seems to cover everything you’re asking for other than versions, > which is something I think we should be opinionated about: The browser > picks the model. > > This is the fundamental difference between these “built-in AI” APIs versus > other options like WebNN. The tradeoff we’re making here is that the user > benefits from having a single model (or small set of models focused on > specific tasks, e.g. translation) rather than each developer downloading > their own large model consuming bandwidth, disk and memory. I could be > convinced to reveal the model version to the developer however I am > concerned this would result in a similar situation we see today with > user-agent sniffing rather than capability detection-based progressive > enhancement. > > >> Microsoft's own experiments with alternative models suggest getting to >> interoperability with multi-modality via a different training stack is not >> a given, > > > We meet regularly with our counterparts on the Edge team and this concern > is news to me. I’d like to hear more details. > > >> but feedback about the API only suggests workarounds, rather than API >> enhancements we'd expect in response to OT feedback: >> >> https://github.com/webmachinelearning/prompt-api/issues/202 > > > This feature request is quite fresh but our team agrees with the reporter > that there should be better capability detection here. We suggested they > file that issue based on a discussion in the Chromium issue tracker. > > This bleeds into a second, related concern: there hasn't been much in the >> way of what I'd characterise as "pull"-based feedback from developers about >> this API. But it's hard to judge based on the public record. I might have >> missed it, but OT interest hasn't been captured here, the original I2E, or >> the extension request thread: >> >> >> https://groups.google.com/a/chromium.org/g/blink-dev/c/6uBwiiFohAU/m/WhaKAB9fAAAJ >> >> https://groups.google.com/a/chromium.org/g/blink-dev/c/qs059tBaQMI/m/dWDP2ZvpAQAJ >> >> Should we be looking somewhere else to get a sense for developer >> enthusiasm? >> > > Agreed, we dropped the ball on publishing developer feedback and are > working on a better summary. > > >> It's also a bit concerning re: our process for features we're the first >> to ship to see responses like this, rather than proposed enhancements (even >> if they're for a future iteration): >> >> https://github.com/webmachinelearning/prompt-api/issues/187 >> >> Shipping subsets for v1 is fine; avoiding design work in response to >> feedback, less so. >> > > Batched inference is a good feature request but supporting it well (versus > conversational inference) will require a different API and underlying > inference engine features which may not be available. I think it’s > reasonable to acknowledge the feature request but flag it as out-of-scope > for v1. > > >> If partners are interested in seeing this ship ASAP, I'd be swayed (per >> usual) by them weighing in here. It would be particularly convincing if >> they could explain why they are not worried about the API changing >> behaviour in response to model upgrades, and it would be *most* persuasive >> if they'd tried both Edge's OTs using Phi in addition to Google's >> Gemini-based behaviour. >> > > I agree. It sounds like Edge has some developer feedback (or maybe it’s > just internal testing) that we haven’t seen yet. I’ve shared your concerns > about the interoperability issues inherent to this API. I think developers > successfully building sites that work in Chrome and Edge, as well as our > ability to upgrade the model (you’ll note that Google just released Gemma > 4, stay tuned) without breaking existing sites is the only true test of > whether the concerns are well-founded. > > >> Without that, I'm not sure what there is to do but flip the "Needs Work" >> flag, avoid shipping downstream in Edge, and suggest we all go back to OT >> and sort out interop, versioning, and modality questions. >> >> Given that time is short for 148, I hope we can get some useful >> on-the-record input from developers and/or persuasive details from Google's >> OT partners. >> >> Thanks, >> >> Alex >> On Wednesday, April 8, 2026 at 8:12:11 AM UTC-7 Rick Byers wrote: >> >>> Thank you for the additional details. Sounds good, LGTM3 >>> >>> On Wed, Apr 8, 2026 at 10:47 AM Vladimir Levin <[email protected]> >>> wrote: >>> >>>> 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/st >>>>> andards-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=51231 >>>>> 92519393280 >>>>> >>>>> 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%3DuhpkW >>>>> mDx8yFieL5E5g%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/ec9da2ca-20a1-41f2-b60b-ca0ecd959215n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ec9da2ca-20a1-41f2-b60b-ca0ecd959215n%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/CAFUtAY8S%3DZ0rKtQOg60XYHjj8pXTPk0%3D9AwnKZUN7bg%3Dnu67Mw%40mail.gmail.com.
