Gentle reminder to review the Intent to Extend Experimentation for the Writer API. Let me know if you have any questions.
Thanks, Deepti On Wed, Oct 22, 2025 at 11:17 AM Deepti Bogadi <[email protected]> wrote: > Contact emails > > [email protected], [email protected], [email protected] > > Explainer > > > https://github.com/explainers-by-googlers/writing-assistance-apis/blob/main/README.md > > Specification > > https://webmachinelearning.github.io/writing-assistance-apis/#writer-api > > Summary > > The Writer API can be used for writing new material given a writing task > prompt, backed by an on-device AI language model. Developers will be able > to use this API to generate textual explanations of structured data, > composing a post about a product based on reviews or product description, > expanding on pro and con lists into full views and more. An enterprise > policy (GenAILocalFoundationalModelSettings) is available to disable the > underlying model downloading which will render the API unavailable. > > Blink component > > Blink > AI > Writing Assistance > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%20%3E%20AI%20%3E%20Writing%20Assistance%22> > > Web Feature ID > > No information provided > > TAG review > > https://github.com/w3ctag/design-reviews/issues/991 > > TAG review status > > Pending > > Origin Trial Name > > Writer API > > Chromium Trial Name > > AIWriterAPI > > Origin Trial documentation link > > > https://github.com/webmachinelearning/writing-assistance-apis/blob/main/README.md#writer-api > > WebFeature UseCounter name > > Writer_Create > > Risks > > > Interoperability and Compatibility > > This feature has definite interoperability and compatibility risks, due to > the likelihood that different implementations will use different language > models, prompts, and fine-tunings, and even within a single implementation > such as Chrome, these pieces will likely change over time. Additionally, > not all browsers and operating systems will have a built-in language model > to expose, and not all devices will be powerful enough to run one > effectively. We are taking a variety of steps to attempt to mitigate these > risks. For example, the specification is designed to allow the API to be > backed by a cloud-based language model. This approach could extend the > functionality to a wider range of devices and users. The API is designed to > abstract away the specifics of the underlying language model, including > prompts and fine-tuning. This prevents developers from relying on specific > outputs, ensuring they receive newly-written text rather than structured > data that might vary across implementations. Finally, the API surface is > designed with many clear points of failure, that encourage the developer to > probe for capabilities ahead of time and fall back to other techniques if a > capability is not available. Nevertheless, interoperability and > compatibility risk remains high for these sorts of APIs, and we'll be > closely monitoring it during the experiment period. > > Gecko: Negative ( > https://github.com/mozilla/standards-positions/issues/1067) > > WebKit: No signal ( > https://github.com/WebKit/standards-positions/issues/393) > > Web developers: Mixed signals ( > https://github.com/WICG/proposals/issues/163) Prototyping with partners > behind a flag revealed enthusiasm and many prototypes built, from which we > drew the discussion of potential use cases [1]. Feedback on the WICG thread > was more mixed. Some themes we saw include: asking for more capabilities > (e.g. full prompting of a language model instead of higher-level APIs (our > response at [2]); multi-modal support); desire to make sure the API > actually works robustly in many real-world use cases; removal of any > safety/ethical safeguards; and confusion about client-side vs. cloud APIs. > [1]: > https://github.com/WICG/writing-assistance-apis/blob/main/README.md#summarizer-api > [2]: > https://github.com/WICG/writing-assistance-apis/blob/main/README.md#directly-exposing-a-prompt-api > > Other signals: > > Activation > > This feature would definitely benefit from having polyfills, backed by any > of: cloud services, lazily-loaded client-side models using WebGPU, or the > web developer's own server. We anticipate seeing an ecosystem of such > polyfills 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? > > No information provided > > > Goals for experimentation > > Although developers have prototyped using the behind-a-flag implementation > and given good feedback, several partners are interested in testing out the > API with real users. We're looking forward to getting feedback from such > testing, especially with regards to output quality, multilingual support, > and what types of writing tasks are handled well vs. poorly. We also want > to understand whether we've found the right set of options to offer to > control the output, and whether the resulting output reflects those > controls to the extent that developers expect. > > > Reason this experiment is being extended > > Writer API suffers from perceived quality issues and a critical language > support disconnect. These APIs are currently not production-ready for many > use cases, particularly those outside of English. In addition, we are also > seeing low adoption in the OT phase for this API. Hence, we are requesting > the extension of the trial to give us time to collect more feedback from > our partners and make the API more robust and resilient. > > Ongoing technical constraints > > As discussed above, not all devices are capable of running the language > models required to implement this API. The availability() function allows > developers to feature-detect whether the current device can support the API. > > Debuggability > > It is possible that giving DevTools more insight into the nondeterministic > states of the model, e.g. random seeds, could help with debugging. See > related discussion at > https://github.com/explainers-by-googlers/prompt-api/issues/9. > > Will this feature be supported on all six Blink platforms (Windows, Mac, > Linux, ChromeOS, Android, and Android WebView)? > > No > > Not all platforms will come with a language model. In particular, in the > initial stages we are focusing on Windows, Mac, and Linux. > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > No > > The API surface is reasonably well tested with mocked models, but > production model downloading and non-deterministic outputs are not fully > tested at the web-platform-tests layer. The explainer discusses this in > https://github.com/WICG/writing-assistance-apis/blob/main/README.md#specifications-and-tests > . > > DevTrial instructions > > > https://docs.google.com/document/d/1v6-fOC13zS3S-bOLuqIRbzgmia_aPGJl-wzOx4ItSVE/edit?usp=sharing > > Flag name on about://flags > > writer-api-for-gemini-nano > > Finch feature name > > AIWriterAPI > > Requires code in //chrome? > > True > > Tracking bug > > https://issues.chromium.org/issues/357967382 > > Launch bug > > https://launch.corp.google.com/launch/4396832 > > 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 > > Origin trial desktop first > > 137 > > Origin trial desktop last > > 142 > > Origin trial extension 1 end milestone > > 148 > > DevTrial on desktop > > 129 > > 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). > > At this point all known proposed changes have been incorporated into the > specification and implementation. > > Link to entry on the Chrome Platform Status > > https://chromestatus.com/feature/4712595362414592?gate=6282634527375360 > > Links to previous Intent discussions > > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9qMAkT%3DiUBbDGfd_zcH7uEqze-H1r5DWUa8OFbtZGZ1Q%40mail.gmail.com > > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9G-fLtpDFO1%2BdR1JS_1XWgczg%2BRte1_h32FUziSe-yLw%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_Zj73LDmK__0U%3DX%2B%3DKLrew1M7sgeskSrg4mGefb1Hczp3Q%40mail.gmail.com.
