[blink-dev] Intent to Ship: Prompt API

[Deepti Bogadi]

Contact emails

m...@chromium.org, rei...@chromium.org, kenji...@chromium.org, dbo...@chromium.org

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 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

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, Language Model, Prompt API, Built-in AI

TAG review

https://github.com/w3ctag/design-reviews/issues/1093

TAG review status

Issues addressed

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.

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, 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 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 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?

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). 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.

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.

[Mike Taylor]

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).

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJcT_Zj73wjXZfmMcpQRWePp-H%3D5LzxYBOnasViYcn%3DFzY2vVQ%40mail.gmail.com.

[Rick Byers]

Can you elaborate on this? I see 14 issues 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 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, 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 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 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?

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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c257bea5-b444-42ab-b195-4025930206f2%40chromium.org.

[Mike Wasserman]

Regarding TAG review status:
The scope of issues raised is broad. We conducted thoughtful google-internal reviews and 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. 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 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. 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, 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.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJcT_Zj73wjXZfmMcpQRWePp-H%3D5LzxYBOnasViYcn%3DFzY2vVQ%40mail.gmail.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 blink-dev+unsubscribe@chromium.org.

[Vladimir Levin]

On Mon, Apr 6, 2026 at 6:04 PM Mike Wasserman <m...@chromium.org> wrote:

Regarding TAG review status:
The scope of issues raised is broad. We conducted thoughtful google-internal reviews and 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

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJcT_Zj73wjXZfmMcpQRWePp-H%3D5LzxYBOnasViYcn%3DFzY2vVQ%40mail.gmail.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 blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c257bea5-b444-42ab-b195-4025930206f2%40chromium.org.

--

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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fd88dc6e-a5fd-4dfd-9a8a-78971c13d363n%40chromium.org.

[Mike Wasserman]

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 <m...@chromium.org> wrote:

Regarding TAG review status:
The scope of issues raised is broad. We conducted thoughtful google-internal reviews and 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.

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 provided in Nov 2025 suggested these renames; spec and impl 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 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

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJcT_Zj73wjXZfmMcpQRWePp-H%3D5LzxYBOnasViYcn%3DFzY2vVQ%40mail.gmail.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 blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c257bea5-b444-42ab-b195-4025930206f2%40chromium.org.

--
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 blink-dev+unsubscribe@chromium.org.

[Rick Byers]

On Tue, Apr 7, 2026 at 3:00 PM Mike Wasserman <m...@chromium.org> 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 <m...@chromium.org> wrote:

Regarding TAG review status:
The scope of issues raised is broad. We conducted thoughtful google-internal reviews and 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

[Tag Review] - Interoperable model parameters

measureInputUsage includes <model> start response token

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 provided in Nov 2025 suggested these renames; spec and impl 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 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). 

[Mike Wasserman]

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 "wpt bots" with a separate set of /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.

[Vladimir Levin]

Thank you for your responses.

LGTM2

Thanks,

Vlad

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25e6f203-87b6-4844-9edf-fa301ad36e3an%40chromium.org.

[Rick Byers]

Thank you for the additional details. Sounds good, LGTM3