Gentle reminder to review the Intent to Extend Experimentation for the Rewriter API. Let me know if you have any questions.
Thanks, Deepti On Wed, Oct 22, 2025 at 11:18 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/#rewriter-api > > Summary > > The Rewriter API transforms and rephrases input text in requested ways, > backed by an on-device AI language model. Developers may use this API to > remove redundancies within a text in order to fit into a word limit, > rephrase messages to suit the intended audience or to be more constructive > if a message is found to use toxic language, rephrasing a post or article > to use simpler words and concepts 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 > > Rewriter API > > Chromium Trial Name > > AIRewriterAPI > > Origin Trial documentation link > > > https://github.com/webmachinelearning/writing-assistance-apis/blob/main/README.md#rewriter-api > > WebFeature UseCounter name > > Rewriter_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 rewritten 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 input data 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 > > Rewriter 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 > > rewriter-api-for-gemini-nano > > Finch feature name > > AIRewriterAPI > > Requires code in //chrome? > > True > > Tracking bug > > https://issues.chromium.org/issues/358214322 > > Launch bug > > https://launch.corp.google.com/launch/4396842 > > 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/5112320150470656?gate=5133588907556864 > > Links to previous Intent discussions > > Intent to Prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9Jhe7o59mX5tJPD%3DcZQb2oL3mNi-T57wA86fPXn55OPw%40mail.gmail.com > > Intent to Experiment: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8dnNHXKM26MvQxZ6LBE16PUbvH6-GH5B3Z2WDv4uH0WQ%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_Zh__fbmmJBzfwsjuc282g_3RHWmNh0CjxwsZNTKoBbR6w%40mail.gmail.com.
