API de Prompt de Chrome

• API nativa del navegador para enviar solicitudes en lenguaje natural al modelo Gemini Nano integrado en Chrome, con inferencia de IA en el dispositivo sin ida y vuelta al servidor
• Permite diversos usos como búsqueda con IA, feeds personalizados mediante clasificación de noticias, filtrado de contenido, creación de eventos de calendario y extracción de contactos
• Con prompt() se puede obtener una respuesta de una sola vez o elegir una respuesta en streaming basada en ReadableStream con promptStreaming()
• Ofrece funciones de control de sesión detalladas como gestión de contexto basada en sesión, respuestas en streaming y clonación de sesiones
• Como la inferencia de IA se realiza dentro del navegador sin ida y vuelta al servidor, resulta ventajosa para la privacidad y para minimizar la latencia de respuesta
• Incluye funciones multimodales compatibles no solo con texto, sino también con entradas de imagen y audio
  • Audio: AudioBuffer, ArrayBuffer, Blob, etc.
  • Imagen: HTMLImageElement, HTMLCanvasElement, VideoFrame, Blob, etc.
• Se puede pasar un esquema JSON en el campo responseConstraint para restringir el formato de salida del modelo a boolean, una estructura JSON específica, etc.
• Con initialPrompts se pueden inyectar el prompt del sistema y el contexto de conversaciones previas, y con append() es posible enviar contexto adicional por adelantado incluso después de crear la sesión
• Si se añade prefix: true a un mensaje assistant posterior, se puede guiar al modelo para que empiece a responder en un formato específico
• Compatible con la gestión de la ventana de contexto por sesión: contextUsage/contextWindow permiten revisar el uso de tokens, y si hay desbordamiento se eliminan automáticamente las conversaciones iniciales (el prompt del sistema se mantiene)
• Permite bifurcar sesiones con clone(), liberar recursos con destroy() y cancelar sesiones o prompts a mitad del proceso con AbortSignal
• Con expectedInputs/expectedOutputs se pueden configurar el formato de entrada/salida y el idioma (actualmente compatibles: en, ja, es)
• Requisitos de hardware: Windows 10+/macOS 13+/Linux/ChromeOS, al menos 22 GB de almacenamiento, más de 4 GB de VRAM de GPU o bien 16 GB o más de RAM de CPU + al menos 4 núcleos
• En iframes de origen cruzado, se puede delegar el acceso con el atributo allow="language-model"; por ahora no es compatible en Web Workers
• Disponible como Origin Trial desde Chrome 138

[GN⁺]

Comentarios en Hacker News

• Esta API parece perfecta para una idea de de-snarkifier en la que llevo mucho tiempo pensando
  Las redes sociales pueden ser intelectualmente estimulantes y útiles para aprender, pero también es muy fácil que uno termine metido, sin querer, en peleas ideológicas y guerras de insultos. Pelear emocionalmente con desconocidos en internet es casi un desperdicio de capital humano
  Con una API así, parece posible hacer una extensión de navegador que, antes de mostrar una publicación, suavice solo las expresiones agresivas o sarcásticas, mientras preserva intacta la información factual. Incluso podría ir más lejos y hacer que, cuanto más agresivo sea el tono, más ridículo o incompetente suene
  Entonces quien lee queda protegido de los ataques personales de extraños, y quien escribe también pierde el incentivo de comportarse con grosería. Si todos usaran un filtro así, ya no habría razón para competir por ver quién es más cruel

  • Esto se siente como el Soylent de la comunicación escrita
    Tiene todo el valor nutritivo, pero sin mucho sabor especial
  • De verdad me entusiasma una herramienta así. Podría quitarle a internet sus calorías vacías y reducir mucho el uso de las plataformas populares actuales
    Lo que yo quiero es eliminar por completo los titulares clickbait y los anuncios, y ver solo títulos secos y basados en hechos
    Para cualquier tema, me basta con un artículo central y unos pocos comentarios sustanciales; el resto casi siempre es ruido que no quiero ver
    El estado actual de las redes sociales está tan mal que casi no las uso, y HN era la única excepción, pero hasta aquí parece que vamos en una dirección parecida por la saturación de IA. Aun así, termino desperdiciando unas horas cada dos semanas, y quisiera cortar incluso eso por completo
    Idealmente, me gustaría que el 98% del contenido se filtrara o resumiera hasta desaparecer, y que con el tiempo internet se volviera algo que solo uso cuando busco algo de forma intencional. Básicamente, quiero quitarle gran parte de la carga de entretenimiento a internet y redirigir ese tiempo y energía al mundo real y a fuentes de alta calidad como los libros
  • En YouTube ya existe algo parecido, y yo uso DeArrow
    Esta extensión busca reducir el sensacionalismo mediante crowdsourcing, aunque sospecho que algunos de los principales contribuidores podrían ser bots con LLM
  • Parece una idea interesante y vale la pena explorarla
    Dicho eso, estas cosas son impredecibles cuando chocan con la realidad, e incluso si funcionan bien, es muy probable que terminen operando de una forma bastante distinta a la imaginada al principio
  • Soy PM de las built-in AI APIs de Chrome, y esta idea de de-snarkifier realmente me encanta y parece despertar interés amplio
    No me pude contener y armé rápido un prototipo de Snarknada, mientras evaluaba tanto patrones de baja latencia como posibilidades de precisión
    Justamente por esto creo que on-device es lo correcto para este tipo de uso. Si quisieras suavizar un feed entero de scroll infinito con una API en la nube, el costo en tokens sería tan alto que para un desarrollador sería imposible de sostener. Además, es totalmente comprensible que la gente no quiera enviar su feed personal o sus DM a un servidor de terceros solo para ajustarles el tono
    Si esto se mueve al dispositivo, la Semantic Mutation de alta frecuencia podría volverse viable por primera vez tanto en costos como técnicamente. Si alguien lo construye con más seriedad que mi prototipo de PM de juguete y se topa con puntos concretos de fricción, me encantaría escucharlo. Ayuda a priorizar el roadmap
    [1]: Si usas agentes de código (Cursor, Claude Code, etc.), recomiendo apuntar a https://www.npmjs.com/package/built-in-ai-skills-md-agent-md. Muchos modelos fueron entrenados con el namespace window.ai, que ya quedó obsoleto, así que este archivo de habilidades ayuda a que usen correctamente la API actual

• Yo lideré el trabajo de diseño de esta API, y antes de retirarme también dejé escrito un texto con las consideraciones de diseño relacionadas
  https://domenic.me/builtin-ai-api-design/

  • Me da curiosidad cómo ven los casos de uso objetivo de esta API en el corto y largo plazo
    Y también si, al construir algo así, los navegadores intentan alinearse entre sí de manera práctica, no necesariamente a nivel W3C, para mantener puntos en común. Al final, esta industria es bastante pequeña
  • Felicidades por tu retiro

• Esto sí funciona en la práctica, y yo ya lo lancé para local inference
  En tareas livianas de LLM, como búsqueda, me sirvió como una especie de ollama para gente con pocos recursos. La mayor ventaja es que es gratis, protege la privacidad, y casi no exige nada del usuario, así que es una buena forma de darle inferencia local a personas no técnicas
  Pero la experiencia real de usuario no es buena. El tamaño de descarga del modelo es varios órdenes de magnitud mayor que el del navegador mismo, y todo eso tiene que completarse antes de recibir el primer token
  Parece difícil resolver esto hasta que los sistemas operativos ofrezcan de forma estable modelos ya integrados, y APIs de este tipo puedan conectarse a ellos

  • Esta es una descarga única que comparten todos los sitios que usan la Prompt API
    El problema mayor es que en la mayoría de las PCs comunes el modelo es demasiado pequeño y lento. Intenté reescribir en tiempo real el texto de una aventura de texto de Infocom, pero por ahora es demasiado lento en muchas PCs como para que sea práctico
  • Tal vez la próxima gran tendencia sea una suscripción premium de software que ya te venda varias 5090 instaladas
  • Si fueran modelos MoE, los expertos podrían traerse por red solo cuando hagan falta mediante HTTP range query
    Sería parecido a cómo bittorrent recibe fragmentos de archivos desde múltiples hosts. Las capas compartidas todavía habría que descargarlas, pero el tiempo hasta el primer token podría hacerse proporcional al tamaño activo y no al tamaño total
    Claro, eso ya no sería inferencia completamente offline, pero para una funcionalidad web del navegador quizá eso no sea una consideración central
  • Espero que nunca llegue un mundo donde los sistemas operativos metan de forma confiable modelos preinstalados
  • Está muy bien
    Pero si el modelo es mucho más grande que el navegador y hay que descargarlo antes del primer token, me pregunto si eso significa una descarga diferida. Si el primer usuario que lo invoca tiene que esperar en ese momento a que termine la descarga, la experiencia de usuario suena bastante terrible
    También me pregunto si Chrome muestra algo como un cuadro de estado de descarga para reducir la confusión, y cuánto espacio en disco ocupa

• A simple vista, parece que esto usa Gemini Nano, pero Gemma 4 E2B/E4B se ve mucho mejor, así que por ahora quizá convenga más distribuir una versión cuantizada como extensión

  • Gemini Nano-1: 46% MMLU, 1.8B
  • Gemini Nano-2: 56% MMLU, 3.25B
  • Gemma4 E2B: 60.0% MMLU, 2.3B
  • Gemma4 E4B: 69.4% MMLU, 4.5B
    Fuente:
  • https://huggingface.co/google/gemma-4-E2B-it
  • https://android-developers.googleblog.com/2024/10/gemini-nano-experimental-access-available-on-android.html
  • No conozco la situación interna actual, pero cuando yo estaba en ese equipo metíamos los modelos pequeños más recientes de Google en Chrome con mucha rapidez
    Si Gemma 4 o su equivalente en Gemini Nano todavía no están en Chrome, esperaría que entren pronto
    Y esta publicación fue actualizada por última vez el 2025-09-21, y para entonces ya era Gemini Nano 3
  • Sí
    Dice que la Prompt API funciona enviando solicitudes en lenguaje natural a Gemini Nano dentro del navegador
  • La Prompt API usa el modelo disponible en el navegador
    En Edge probablemente sería Phi4

• Esto también parece una buena manera de hacer que un script JS malicioso les cargue generación de tokens a visitantes desprevenidos
  También sería interesante ver si es posible una especie de descentralización útil, fragmentando prompts más grandes y enviándolos a múltiples navegadores, con cada uno procesando solo una parte pequeña, usando un patrón de subagentes o algo parecido a RLM

  • Parece demasiado trabajo para la recompensa
    La infraestructura técnica y de negocio se volvería enormemente compleja, y si de verdad quieres descargar prompts en el navegador del usuario, no sería mejor simplemente usar bien la Chrome API. Además, es discutible cuántos casos realmente significativos habría para descargar prompts del lado del servidor hacia modelos tan limitados
    Y si de verdad quisieras hacerlo, WebGPU ya existe desde hace tiempo
  • La generación de tokens con modelos pequeños casi no tiene valor

• Esto parece un paso hacia una Model API de verdad, pero por ahora sigue siendo un paso pequeño
  También recuerda a Foundation Models de Apple
  Muchas integraciones de IA se enfocan en comunicación textual o estilo de chat, pero en realidad también hay mucho software que se beneficiaría en interfaces no textuales
  Al final, creo que el sistema operativo y el navegador deberían ofrecer una API que gestione modelos, para que las apps puedan acceder tanto a modelos on-device como remotos mediante una interfaz simple
  Sería excelente que esto se estandarizara de forma multiplataforma, y como también tendría que incluir móvil, en la práctica parece que Apple y Google serían quienes realmente podrían empujarlo. Meta podría seguir después o incluso moverse primero
  La clave es que no debería estar atado a un modelo promocionado en particular
  Las apps deberían poder consultar y elegir el modelo adecuado
  (1) https://developer.apple.com/documentation/foundationmodels

  • Los Foundation Models de Apple se ven bien en la documentación, pero cuando lo revisas aparece una limitación de ventana de contexto de 4k
    Aunque claro, todavía está en una etapa temprana

• https://github.com/mozilla/standards-positions/issues/1067

  • También vale la pena ver esto: https://github.com/mozilla/standards-positions/issues/1213

• Nosotros lo estamos usando para resúmenes retrospectivos de hackdays
  https://remotehack.space/previous-hacks/
  Es un script pequeño que lee feeds RSS y genera resúmenes en el cuerpo del texto, y encaja bastante bien con un sitio estático. Algún día me gustaría ampliarlo para hacer también otras preguntas sobre el mismo contenido

• Un LLM local accesible desde el navegador es bueno en términos de privacidad, pero si cada navegador conecta esta API a un modelo distinto, la pesadilla de pruebas podría empeorar aún más que ahora
  Al final, es probable que la mayoría de las implementaciones se alineen con Gemini Nano, así que también me pregunto si esto empujará todavía más a los usuarios hacia Chrome

  • La fragmentación en pruebas es de verdad el problema central
    En la práctica, los prompts no son agnósticos al modelo, así que un prompt afinado cuidadosamente para Gemini Nano 3 v2025 podría degradarse silenciosamente en el modelo del lado de Gecko. Pero la API ni siquiera ofrece detección de capacidades para hacer bifurcaciones
    Eso es peor incluso que WebGL, donde al menos podías consultar si había soporte para extensiones. Lanzar funcionalidades que dependen de la calidad de prompts de un modelo cuyo nombre y versión están ocultos detrás del navegador es como publicar software cuyo comportamiento depende del diccionario que el usuario tenga instalado

• Tengo entendido que Gemini Nano, a diferencia de Gemma, no tiene pesos abiertos
  No sé si alguien ya lo hizo, pero me gustaría intentar volcar los pesos del modelo