Un asistente React puede usar Chrome Summarizer para resumir un encargo en el dispositivo y reservar una acción aparte para pedir a Gemini propuestas de cambios desde el backend. Mantén el encargo original, comprueba que cada propuesta corresponde al borrador actual y deja que la persona la revise antes de guardarla. Ese es el flujo que Raju Dandigam describió para Trip Workbench, su demo de planificación de viajes.
En esta guía
- Separa el resumen local de la propuesta de Gemini
- Comprueba si el dispositivo cumple los requisitos publicados
- Gestiona disponibilidad, cancelación y textos largos
- Vincula cada propuesta al borrador correcto
- Presenta los cambios antes de guardarlos
Separa el resumen local de la propuesta de Gemini
El resumen local sirve para ayudar a leer el encargo: Chrome indica que el modelo integrado procesa el texto en el dispositivo y que, durante ese uso, no envía datos a Google ni a terceros. La solicitud a Gemini es otra acción. En Trip Workbench, al pedir una propuesta, el encargo original se envía al backend de la aplicación, que llama al modelo en la nube.
Conviene mantener el original como referencia y tratar la respuesta de Gemini como una propuesta, no como una modificación ya autorizada. La demo separa el flujo en tres acciones: resumir el encargo, solicitar cambios propuestos y aplicar los cambios revisados por la ruta habitual de actualización del backend. Aplicarlos guarda el borrador; enviarlo o reservar el viaje son acciones distintas.
Comprueba si el dispositivo cumple los requisitos publicados
La documentación de Chrome para Summarizer, actualizada el 30 de julio de 2025, situaba la API a partir de Chrome 138 estable. También especificaba estos sistemas y requisitos de hardware. Son las condiciones que indicaba esa página en esa fecha.
| Comprobación | Requisito indicado por Chrome |
| Sistemas | Windows 10 u 11, macOS 13 o posterior, Linux, o ChromeOS en un Chromebook Plus con Platform 16389.0.0 o posterior |
| Dispositivos excluidos de las API de modelos fundacionales cubiertas | Android, iOS y dispositivos ChromeOS que no sean Chromebook Plus |
| Espacio libre | Al menos 22 GB en el volumen que contiene el perfil de Chrome |
| Hardware | Una GPU con más de 4 GB de VRAM, o un sistema con al menos 16 GB de RAM y 4 núcleos de CPU |
Chrome señala que hace falta una conexión sin límite de datos para descargar el modelo por primera vez. Una vez descargado, el uso local puede funcionar sin conexión. La afirmación de privacidad se refiere al uso del modelo integrado, no a la petición separada que tu aplicación envía al backend para obtener una propuesta de Gemini.
Gestiona disponibilidad, cancelación y textos largos
Comprueba la disponibilidad antes de crear una sesión. Summarizer.availability() devuelve available, downloadable, downloading o unavailable; haz la consulta con las mismas opciones que usarás al crearla. Si la creación requiere descargar el modelo, Chrome exige una interacción de la persona usuaria para iniciarla.
Para que la cancelación alcance también una creación pendiente, MDN documenta la opción signal en Summarizer.create(). Si se aborta antes de que se resuelva la promesa, se cancela la creación. Si se aborta después, se libera la instancia y las llamadas al Summarizer rechazan con AbortError.
No fijes un límite universal de tokens en tu interfaz. MDN indica que inputQuota depende de la implementación y documenta measureInputUsage() para medir un texto concreto frente a la cuota de la sesión. Así puedes decidir si procesarlo o pedir que se seleccione un fragmento menor.
Para documentos extensos, Chrome describe un método por partes: separar el texto por párrafos o temas, resumir cada fragmento y luego resumir el conjunto de resúmenes. Si hace falta, el proceso puede repetirse. Cada pasada adicional puede reducir la precisión y aumentar la latencia, así que conserva el texto original y presenta el resumen como una ayuda, no como sustituto.
Vincula cada propuesta al borrador correcto
En el flujo de Trip Workbench, el backend comprueba el acceso y lee el borrador guardado para generar una propuesta. El coordinador de la interfaz también registra la identidad del borrador y de la sesión, la revisión guardada, la versión de las ediciones locales y la del encargo. Comprueba que esos valores sigan vigentes al recibir la respuesta y vuelve a comprobarlos cuando la persona intenta aplicarla. Si hay ediciones locales pendientes, bloquea la aplicación.
La respuesta estructurada de Gemini tampoco debe saltarse las validaciones de la aplicación. En la implementación descrita, el adaptador solicita JSON, pero no envía un esquema de salida a Gemini; la aplicación analiza y valida la respuesta antes de usarla. Mantener esas comprobaciones en el backend y en el momento de aplicar evita que una propuesta atrasada sobrescriba cambios posteriores.
Presenta los cambios antes de guardarlos
Muestra el valor actual junto al propuesto y permite revisar cada modificación antes de aplicar el parche. El panel de Trip Workbench también contempla aclaraciones junto a los campos pertinentes y cambios que vacían un campo. La persona conserva así el control sobre qué se guarda en el borrador.
En la descripción de Trip Workbench publicada el 28 de octubre de 2026, Raju Dandigam informó de ocho comprobaciones controladas con un Summarizer simulado. Estas cubrieron el ciclo de vida del adaptador. También describió defectos en su adaptador candidato: una respuesta fallida de disponibilidad escapaba al manejo de errores, una solicitud ya cancelada aún creaba una sesión y la señal de cancelación no se pasaba a la creación. La extensión de React no se había montado ni comprobado con TypeScript; esas comprobaciones no evaluaron el comportamiento del modelo nativo, la calidad de los resúmenes, el rendimiento ni el tráfico de red.
