Build a React assistant with separate Chrome and Gemini AI paths

A React assistant can use Chrome’s on-device Summarizer to help someone read a brief, then make a separate backend request to Gemini for proposed draft changes. Keep the original brief intact, tie each proposal to the draft version it was based on, and let the user review changes before applying them through the normal save path.

In this guide

• Keep the two AI actions on separate paths
• Check Chrome’s documented device requirements
• Handle availability, cancellation, and long briefs
• Bind each proposal to the current draft
• Show changes before saving
• Keep lifecycle checks separate from model quality

Keep the two AI actions on separate paths

Treat summarizing and proposing edits as different user actions with different data flows. In Raju Dandigam’s Trip Workbench design, Chrome’s built-in model summarizes the original brief locally and returns text for the person to review. A separate action sends the original brief to the application backend, which calls Gemini for proposed field changes and clarification questions. The backend holds the Gemini credential.

Chrome says its built-in model sends no data to Google or a third party during model use, and that using the model after its initial download does not require a network connection. The separate Gemini action does send the original brief to the application backend. Keep the local summary from silently triggering that request: the user should choose the cloud proposal action explicitly.

The proposal is not a saved change. Present it for review, then apply an accepted patch through the application’s existing update path. In Trip Workbench, applying a patch saves the draft; submitting it is a separate action, and applying the patch does not book travel.

Check Chrome’s documented device requirements

Chrome’s Summarizer page, last updated July 30, 2025, lists Chrome 138 stable as its starting point. Its documented platform and hardware requirements give developers a concrete eligibility check before they make local summarization a required part of a workflow.

These are the requirements on Chrome’s dated documentation page. They are not a check of a particular user’s device or browser installation.

Handle availability, cancellation, and long briefs

Before creating a session, check Summarizer.availability() with the same options you intend to pass to Summarizer.create(). Chrome documents four results: available, downloadable, downloading, and unavailable. When creation needs a model download, start it following a user interaction; the initial download requires an unmetered connection.

Pass an AbortSignal to Summarizer.create() so cancellation can reach session creation. MDN documents two outcomes: aborting before the creation promise resolves cancels creation; aborting after it resolves releases the instance, and Summarizer calls reject with AbortError.

Do not hard-code one token limit for every browser and model. MDN describes inputQuota as implementation-dependent and provides measureInputUsage() to check a specific text against the session’s quota. For long briefs, Chrome’s guidance is to split text at paragraph or topic boundaries, summarize each piece, then summarize the combined summaries, repeating the process if needed. Repeated summarization can reduce accuracy and increase latency, so retain the original brief and make a shorter selection an option.

Bind each proposal to the current draft

A proposal can become stale while someone is editing. Track the draft or session identity, saved revision, local edit version, and brief version used for the request. When the response arrives, check that it still matches the current editing context, then check again when the user chooses Apply. Block applying while unsaved local edits would make the proposal’s basis out of date.

Keep the server in control of authorization and persistence. Trip Workbench’s reported design checks access before reading the saved draft, then uses its normal backend mutation path to apply changes. Its Gemini adapter requests JSON using responseMimeType: "application/json", but does not send an output schema. The application parses and validates the response before treating it as a proposed patch. That validation is important: a JSON response is a format, not proof that the proposed values are valid for the application.

Show changes before saving

Show each proposed value beside the current draft value, including when the proposal would clear a field. Keep clarification questions visible with the changes they affect. The user should be able to accept or reject proposed edits before Apply saves them. Keep submission separate from saving so a reviewed patch cannot accidentally become a completed booking.

Keep lifecycle checks separate from model quality

In an implementation account published October 28, 2026, Raju Dandigam reported eight controlled lifecycle checks using a fake Summarizer. The checks covered the adapter’s handling of availability errors and cancellation, among other lifecycle behavior. Dandigam also described candidate-adapter problems: an availability rejection escaped error handling, an already-cancelled request still created a session, and the creation call did not receive the abort signal.

Those checks concerned the adapter and its test double. Dandigam said the React extension had not been mounted or typechecked, and the checks did not establish native-model behavior, summary quality, performance, or network payloads. Treat the lifecycle tests as a way to exercise application control flow, not as evidence of how well a model summarizes a real brief.