API Prompt de Chrome

• API native du navigateur permettant d’envoyer des requêtes en langage naturel au modèle Gemini Nano intégré à Chrome, avec inférence IA on-device sans aller-retour vers le serveur
• Permet de nombreux cas d’usage : recherche assistée par IA, flux personnalisés via classification des actualités, filtrage de contenu, création d’événements de calendrier, extraction de contacts, etc.
• Possibilité de choisir entre prompt() pour une réponse en une fois ou promptStreaming() pour une réponse en streaming basée sur ReadableStream
• Fournit des fonctions de contrôle de session fines : gestion du contexte par session, réponses en streaming, clonage de session, etc.
• Comme l’inférence IA se fait dans le navigateur sans aller-retour serveur, cela favorise la protection de la vie privée et la réduction de la latence
• Fonction multimodale intégrée prenant en charge non seulement le texte, mais aussi les entrées image et audio
  • Audio : AudioBuffer, ArrayBuffer, Blob, etc.
  • Image : HTMLImageElement, HTMLCanvasElement, VideoFrame, Blob, etc.
• Il est possible de transmettre un schéma JSON dans le champ responseConstraint afin de contraindre le format de sortie du modèle à un boolean, à une structure JSON précise, etc.
• initialPrompts permet d’injecter un prompt système et le contexte d’une conversation précédente, et append() autorise aussi l’envoi préalable de contexte supplémentaire après la création de la session
• En ajoutant prefix: true à un message assistant final, on peut orienter le modèle pour qu’il commence sa réponse dans un format spécifique
• Prise en charge de la gestion de la fenêtre de contexte par session : vérification de l’usage des tokens via contextUsage/contextWindow, suppression automatique des premiers échanges en cas de dépassement (le prompt système est conservé)
• clone() permet de bifurquer une session, destroy() de libérer les ressources, et AbortSignal d’annuler une session ou un prompt en cours
• expectedInputs/expectedOutputs permettent de définir les formats d’entrée/sortie et la langue (en, ja, es pris en charge actuellement)
• Exigences matérielles : Windows 10+/macOS 13+/Linux/ChromeOS, au moins 22 Go d’espace de stockage, plus de 4 Go de VRAM GPU ou au moins 16 Go de RAM CPU + 4 cœurs minimum
• Pour les iframes cross-origin, l’accès peut être délégué via l’attribut allow="language-model", et les web workers ne sont pas encore pris en charge
• Disponible via Origin Trial à partir de Chrome 138

[GN⁺]

Avis sur Hacker News

• Cette API semble parfaitement correspondre à une idée de de-snarkifier à laquelle je réfléchis depuis longtemps
  Les réseaux sociaux peuvent être intellectuellement stimulants et instructifs, mais il est facile de se laisser entraîner, même sans le vouloir, dans des joutes idéologiques et des flamewars. Se battre en ligne avec des inconnus au prix d’une dépense émotionnelle ressemble presque à un gaspillage de capital humain
  Avec une API comme celle-ci, on pourrait imaginer une extension de navigateur qui adoucit uniquement les formulations agressives ou sarcastiques avant d’afficher un texte, tout en préservant les informations factuelles. On pourrait même aller plus loin et faire en sorte qu’un ton agressif paraisse plus ridicule ou incompétent
  Ainsi, les lecteurs seraient protégés des attaques personnelles d’inconnus, et les auteurs n’auraient plus intérêt à être impolis. Si tout le monde utilisait ce genre de filtre, il n’y aurait plus de raison de rivaliser pour savoir qui peut être le plus odieux

  • C’est un peu le Soylent de la communication écrite
    Il y a toute la valeur nutritive, mais sans saveur particulière
  • Ce type d’outil m’enthousiasme vraiment. Il pourrait retirer les calories vides d’Internet et réduire fortement l’usage des plateformes populaires actuelles
    Ce que je veux, c’est supprimer tous les titres putaclic et les pubs, et n’afficher que des titres factuels et austères
    Pour n’importe quel sujet, un article principal et quelques commentaires utiles me suffisent, et je ne veux généralement pas voir le reste du bruit
    L’état actuel des réseaux sociaux est tellement mauvais que je ne les utilise presque plus, à part HN, mais même ici cela semble évoluer dans la même direction avec la saturation par l’IA. Malgré tout, je finis encore par y perdre quelques heures une semaine sur deux, et j’aimerais m’en débarrasser complètement
    Dans l’idéal, j’aimerais que 98 % du contenu soit filtré ou résumé jusqu’à disparaître, et qu’avec le temps Internet ne serve plus qu’aux recherches intentionnelles. En gros, je veux retirer la majeure partie de la dimension divertissante d’Internet pour réallouer mon temps et mon énergie au monde réel et à des sources de meilleure qualité comme les livres
  • Il existe déjà quelque chose de similaire sur YouTube, et j’utilise DeArrow
    Cette extension est un outil de réduction du sensationnalisme basé sur le crowdsourcing, même si je me demande si certains des principaux contributeurs ne sont pas des bots LLM
  • C’est une idée intéressante qui mérite d’être explorée
    Mais ce genre de chose devient imprévisible au contact du réel, et même si cela fonctionne bien, il y a de fortes chances que cela opère d’une manière assez différente de ce qu’on imaginait au départ
  • Je suis PM des built-in AI APIs de Chrome, et j’aime beaucoup cette idée de de-snarkifier, qui semble susciter un intérêt assez large
    Je n’ai pas pu résister et j’ai bricolé à la hâte un prototype Snarknada pour examiner à la fois les schémas à faible latence et ce qu’on pouvait espérer en matière de précision
    C’est exactement pour ce type de cas d’usage que je pense que l’on-device est la bonne approche. Si on voulait adoucir un flux infini entier via une API cloud, le coût en tokens deviendrait ingérable pour les développeurs. Et il est tout à fait normal que les gens n’aient pas envie d’envoyer leur feed personnel ou leurs DM à un serveur tiers juste pour en lisser le ton
    En déplaçant cela dans l’appareil, une Semantic Mutation à haute fréquence pourrait devenir réaliste pour la première fois, en termes de coûts comme de technique. Si quelqu’un développe quelque chose de plus sérieux que mon prototype PM un peu gadget et rencontre des points de friction concrets, j’aimerais vraiment en entendre parler. Cela aiderait à prioriser la roadmap
    [1]: Si vous utilisez un agent de code (Cursor, Claude Code, etc.), je recommande de lui pointer https://www.npmjs.com/package/built-in-ai-skills-md-agent-md. Beaucoup de modèles ont été entraînés sur l’espace de noms window.ai, désormais obsolète, et ce fichier de skills aide à utiliser correctement l’API actuelle

• J’ai dirigé le travail de conception de cette API, et avant de partir à la retraite j’ai aussi écrit un billet récapitulant les considérations de conception associées
  https://domenic.me/builtin-ai-api-design/

  • Je serais curieux de savoir quels sont, selon vous, les cas d’usage cibles de cette API à court et à long terme
    Je me demande aussi si, au moment de construire ce genre de chose, les navigateurs essaient au moins de se coordonner de manière pragmatique entre eux, même hors du cadre W3C. Après tout, ce secteur reste assez petit
  • Félicitations pour la retraite

• Cela fonctionne réellement, et je l’ai déjà déployé pour du local inference
  Pour des tâches LLM modestes comme la recherche, cela pouvait servir d’ollama du pauvre. Le plus gros avantage, c’est que c’est gratuit, respectueux de la vie privée, et que l’utilisateur n’a presque rien à faire, ce qui en fait un bon moyen d’apporter l’inférence locale à des utilisateurs non techniques
  En revanche, l’expérience réelle n’est pas bonne. Le téléchargement du modèle est de plusieurs ordres de grandeur plus volumineux que le navigateur lui-même, et tout cela doit être terminé avant de recevoir le premier token
  Cela semble difficile à résoudre tant que le système d’exploitation ne fournira pas de manière fiable des modèles préintégrés, auxquels ce type d’API pourra se connecter

  • Il s’agit d’un téléchargement unique partagé par tous les sites qui utilisent la Prompt API
    Le plus gros problème, c’est que sur la plupart des PC grand public, le modèle est trop petit et trop lent. J’ai essayé de transformer en temps réel le texte d’une aventure textuelle Infocom, et aujourd’hui c’est trop lent sur beaucoup de machines pour être vraiment pratique
  • La prochaine grande tendance sera peut-être un abonnement logiciel premium vendu avec plusieurs 5090 installées directement
  • Avec des modèles MoE, on pourrait ne récupérer les couches expertes depuis le réseau, via des requêtes HTTP range, qu’au moment où elles sont nécessaires
    Un peu comme bittorrent récupère des morceaux de fichier depuis plusieurs hôtes. Il faudrait toujours télécharger les couches communes, mais le temps jusqu’au premier token pourrait alors être proportionnel à la taille active plutôt qu’à la taille totale
    Bien sûr, ce ne serait plus de l’inférence totalement hors ligne, mais pour une fonctionnalité web dans le navigateur, ce n’est peut-être pas un critère central
  • J’espère que nous ne vivrons pas dans un monde où les systèmes d’exploitation intègrent de manière fiable des modèles préchargés
  • C’est vraiment bien
    Mais si le modèle est bien plus gros que le navigateur et qu’il faut le télécharger avant le premier token, je me demande si cela signifie qu’il est téléchargé à la demande. Si les premiers utilisateurs doivent attendre la fin de ce téléchargement au moment du premier appel, l’expérience utilisateur semble assez terrible
    Je me demande aussi si Chrome affiche quelque chose comme une boîte de dialogue d’état du téléchargement pour limiter la confusion, et quelle quantité d’espace disque cela occupe

• À première vue, cela semble utiliser Gemini Nano, mais les récents Gemma 4 E2B/E4B paraissent bien meilleurs, donc à court terme il serait peut-être préférable de distribuer une version quantifiée via une extension

  • 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
    Sources :
  • https://huggingface.co/google/gemma-4-E2B-it
  • https://android-developers.googleblog.com/2024/10/gemini-nano-experimental-access-available-on-android.html
  • Je ne connais pas la situation interne actuelle, mais à l’époque où j’étais dans cette équipe, nous intégrions très rapidement les derniers petits modèles Google dans Chrome
    Si Gemma 4 ou son équivalent Gemini Nano n’est pas encore dans Chrome, je m’attendrais à ce qu’il y arrive bientôt
    Et cet article a été mis à jour pour la dernière fois le 2025-09-21, et à ce moment-là on en était déjà à Gemini Nano 3
  • Oui
    Il est écrit que la Prompt API envoie des requêtes en langage naturel à Gemini Nano dans le navigateur
  • La Prompt API utilise le modèle disponible dans le navigateur
    Dans Edge, ce sera probablement Phi4

• À première vue, cela semble aussi être un bon moyen pour des scripts JS malveillants de faire générer des tokens à des visiteurs qui n’y comprennent rien
  Il serait intéressant de voir s’il est possible de répartir un grand prompt entre plusieurs navigateurs, chacun ne traitant qu’un petit fragment, afin de produire un résultat utile sous la forme d’un pattern de subagent ou d’une structure proche d’un RLM

  • Cela semble représenter énormément de travail pour un bénéfice limité
    L’infrastructure technique et commerciale deviendrait extrêmement complexe, et si l’objectif est vraiment de déporter les prompts vers les navigateurs des utilisateurs, autant utiliser correctement la Chrome API. Je doute même qu’il y ait beaucoup de cas réellement utiles où décharger des prompts côté serveur vers des modèles aussi modestes aurait un impact significatif
    Et si c’est vraiment ce qu’on veut faire, WebGPU existe déjà depuis longtemps
  • La génération de tokens par de petits modèles n’a pratiquement aucune valeur

• Cela ressemble à un pas vers une véritable Model API, mais ce n’est encore qu’un petit pas
  Cela fait aussi penser aux Foundation Models d’Apple
  Beaucoup d’intégrations IA se concentrent sur la communication textuelle ou les styles de chat, alors qu’en réalité de nombreux logiciels pourraient bénéficier d’interfaces non textuelles
  À terme, je pense que l’OS et le navigateur devraient fournir une API de gestion des modèles, afin que les applications puissent accéder à des modèles on-device et distants via une interface simple
  Ce serait formidable si cela pouvait être standardisé en cross-platform, et comme cela devrait aussi inclure le mobile, ceux qui sont le mieux placés pour pousser cela dans la réalité sont probablement surtout Apple et Google. Meta pourrait suivre, ou au contraire bouger en premier
  Le point essentiel, c’est que cela ne doit pas être réservé à un modèle promotionnel spécifique
  Les applications doivent pouvoir interroger le système et choisir un modèle approprié
  (1) https://developer.apple.com/documentation/foundationmodels

  • Les Foundation Models d’Apple ont l’air bien sur le papier, mais en pratique ce qui saute aux yeux, c’est la fenêtre de contexte de 4k
    Bon, cela dit, on n’en est encore qu’au début

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

  • À voir aussi : https://github.com/mozilla/standards-positions/issues/1213

• Nous utilisons cela pour un résumé rétrospectif de hackday
  https://remotehack.space/previous-hacks/
  C’est un petit script qui lit un flux RSS et génère un résumé à partir du corps de texte, et cela fonctionne plutôt bien avec un site statique. J’aimerais un jour l’étendre pour poser d’autres questions sur le même contenu

• Un LLM local accessible depuis le navigateur est intéressant du point de vue de la vie privée, mais si chaque navigateur met un modèle différent derrière cette API, le cauchemar des tests risque d’être encore pire qu’aujourd’hui
  Comme la plupart des implémentations risquent de s’aligner sur Gemini Nano, je me demande aussi si cela ne va pas pousser encore davantage les utilisateurs vers Chrome

  • La fragmentation des tests est vraiment le problème central
    En pratique, les prompts ne sont pas agnostiques vis-à-vis des modèles, donc un prompt soigneusement optimisé pour Gemini Nano 3 v2025 peut discrètement perdre en qualité sur le modèle de Gecko. Or l’API ne fournit même pas de détection de capacités pour gérer ce genre de branchement
    C’est pire que WebGL, où l’on pouvait au moins interroger la prise en charge des extensions. Livrer une fonctionnalité dépendant de la qualité des prompts d’un modèle caché derrière le navigateur, sans même connaître son nom ou sa version, revient presque à publier un logiciel dont le comportement dépend du dictionnaire que l’utilisateur a installé

• Il me semble que Gemini Nano, contrairement à Gemma, n’a pas de poids open weight
  À moins que quelqu’un l’ait déjà fait, j’aimerais bien essayer de dumper les poids du modèle