API de Prompt do Chrome

• API nativa do navegador para enviar solicitações em linguagem natural ao modelo Gemini Nano integrado ao Chrome, realizando inferência de IA no dispositivo sem ida e volta ao servidor
• Pode ser usada em diversos casos, como busca com IA, feed personalizado por classificação de notícias, filtragem de conteúdo, criação de eventos de calendário e extração de contatos
• Com prompt(), é possível obter uma resposta única de uma vez, ou escolher uma resposta em streaming baseada em ReadableStream com promptStreaming()
• Oferece controle detalhado de sessão, incluindo gerenciamento de contexto baseado em sessão, resposta em streaming e clonagem de sessão
• Como a inferência de IA ocorre dentro do navegador, sem ida e volta ao servidor, isso favorece a proteção da privacidade e a redução da latência
• Inclui recursos multimodais com suporte não só a texto, mas também a entrada de imagem e áudio
  • Áudio: AudioBuffer, ArrayBuffer, Blob etc.
  • Imagem: HTMLImageElement, HTMLCanvasElement, VideoFrame, Blob etc.
• É possível passar um schema JSON no campo responseConstraint para restringir o formato de saída do modelo a boolean, uma estrutura JSON específica etc.
• Com initialPrompts, é possível injetar o prompt de sistema e o contexto de conversas anteriores, e com append() também dá para enviar contexto adicional previamente mesmo após a criação da sessão
• Ao adicionar prefix: true a uma mensagem assistant subsequente, é possível induzir o modelo a iniciar a resposta em um formato específico
• Suporta gerenciamento da janela de contexto por sessão: é possível verificar o uso de tokens com contextUsage/contextWindow, e em caso de overflow as conversas iniciais são removidas automaticamente (o prompt de sistema é mantido)
• Com clone(), é possível bifurcar a sessão; com destroy(), liberar recursos; e com AbortSignal, cancelar a sessão e os prompts no meio da execução
• Com expectedInputs/expectedOutputs, é possível definir formatos de entrada e saída e o idioma (atualmente com suporte a en, ja, es)
• Requisitos de hardware: Windows 10+/macOS 13+/Linux/ChromeOS, mais de 22 GB de armazenamento, mais de 4 GB de VRAM de GPU ou pelo menos 16 GB de RAM de CPU + 4 núcleos ou mais
• Em iframes de origem cruzada, é possível delegar acesso com o atributo allow="language-model"; ainda não há suporte em web workers
• Disponível como origin trial a partir do Chrome 138

[GN⁺]

Opiniões do Hacker News

• Esta API parece perfeita para uma ideia de de-snarkifier que venho pensando há muito tempo
  As redes sociais podem ser intelectualmente estimulantes e trazer coisas para aprender, mas é muito fácil ser sugado para brigas ideológicas e flame wars mesmo sem querer. Ficar brigando na internet com desconhecidos, desperdiçando energia emocional, é quase um desperdício de capital humano
  Com uma API dessas, daria para fazer uma extensão de navegador que, antes de mostrar um texto, suavizasse apenas expressões agressivas ou sarcásticas, preservando intactas as informações factuais. Indo além, talvez até desse para transformar um tom agressivo em algo que soasse ridículo ou incompetente
  Assim, quem lê ficaria protegido de ataques pessoais de estranhos, e quem escreve perderia o incentivo para ser rude. Se todo mundo usasse esse tipo de filtro, também deixaria de existir motivo para competir para ver quem consegue ser mais cruel

  • Isso parece uma espécie de Soylent da comunicação por texto
    Tem todo o valor nutritivo, mas sem nenhum sabor especial
  • Estou realmente animado com uma ferramenta dessas. Ela pode remover as calorias vazias da internet e reduzir bastante o uso das plataformas populares de hoje
    O que eu quero é eliminar totalmente títulos clickbait e anúncios, mostrando só títulos secos e factuais
    Para qualquer tema, um artigo central e alguns comentários realmente úteis já bastam; o resto é, em grande parte, ruído que eu não quero ver
    O estado atual das redes sociais está tão ruim que quase não uso mais nenhuma, e o HN era a única exceção, mas até aqui parece estar indo em direção parecida por causa da saturação de IA. Mesmo assim, acabo desperdiçando algumas horas a cada duas semanas, e queria cortar até isso de vez
    Idealmente, eu gostaria que 98% do conteúdo fosse filtrado ou resumido até desaparecer, e que, com o tempo, a internet fosse usada só quando eu quisesse pesquisar algo de forma intencional. Basicamente, quero remover a maior parte do aspecto de entretenimento da internet e redirecionar meu tempo e energia para a vida real e para fontes de alta qualidade, como livros
  • Já existe algo parecido no YouTube, e eu uso o DeArrow
    Essa extensão é uma ferramenta de crowdsourcing para reduzir sensacionalismo, embora eu ache que alguns dos principais contribuidores talvez sejam bots de LLM
  • Parece uma ideia interessante e vale a pena explorar
    Dito isso, esse tipo de coisa é imprevisível quando bate de frente com a realidade, e, mesmo se funcionar bem, há uma boa chance de operar de forma bem diferente da imaginada no começo
  • Sou PM das built-in AI APIs no Chrome, e gostei muito dessa ideia de de-snarkifier; parece ter um interesse bem amplo
    Não consegui me segurar e montei às pressas um protótipo chamado Snarknada, enquanto também avaliava os padrões de baixa latência e o potencial de precisão
    É exatamente por isso que acho que on-device faz sentido para esse tipo de uso. Se você tentar suavizar um feed inteiro de rolagem infinita com uma API em nuvem, o custo de tokens fica inviável para o desenvolvedor. Além disso, é natural que ninguém queira mandar seu feed pessoal ou DMs para um servidor de terceiros só para ajustar o tom
    Levando isso para dentro do dispositivo, Semantic Mutation de alta frequência pode finalmente se tornar viável em termos técnicos e de custo. Se alguém levar isso mais a sério do que meu protótipo de PM e topar com pontos concretos de atrito, eu adoraria ouvir. Isso ajuda a definir prioridades no roadmap
    [1]: Se você usa agentes de código (Cursor, Claude Code etc.), recomendo apontar para https://www.npmjs.com/package/built-in-ai-skills-md-agent-md. Muitos modelos ainda foram treinados com o namespace obsoleto window.ai, então esse arquivo de skills ajuda a fazer com que usem a API atual corretamente

• Eu liderei o trabalho de design desta API e, antes de me aposentar, também escrevi um texto organizando as considerações de projeto relacionadas
  https://domenic.me/builtin-ai-api-design/

  • Tenho curiosidade sobre como vocês enxergam os casos de uso-alvo desta API no curto e no longo prazo
    E também queria saber se, ao criar algo assim, os navegadores tentam se alinhar na prática entre si, fora do âmbito formal do W3C, para buscar pontos em comum. No fim, esse setor é relativamente pequeno
  • Parabéns pela aposentadoria

• Isso realmente funciona, e eu já lancei algo usando para local inference
  Em tarefas leves de LLM, como busca, deu para usar como uma espécie de ollama para quem tem pouco recurso. A maior vantagem é ser gratuito, preservar a privacidade e exigir quase nada do usuário, então é uma boa forma de levar inferência local para pessoas não técnicas
  Mas a experiência real de uso não é boa. O tamanho do download do modelo é várias ordens de magnitude maior que o próprio navegador, e tudo isso precisa terminar antes de receber o primeiro token
  Isso parece difícil de resolver antes de o sistema operacional passar a oferecer de forma confiável modelos já embutidos, aos quais APIs desse tipo possam se conectar

  • Esse é um download único compartilhado por todos os sites que usam a Prompt API
    O problema maior é que, na maioria dos PCs comuns, o modelo é pequeno demais e lento demais. Tentei reescrever em tempo real frases de um text adventure da infocom, mas hoje isso ainda é lento demais em muitos PCs para ser prático
  • Talvez a próxima grande tendência seja um premium de assinatura de software já vendido com várias 5090 instaladas
  • Em um modelo MoE, daria para buscar as camadas especialistas pela rede só quando necessário, usando HTTP range query
    Seria parecido com o BitTorrent recebendo pedaços de arquivo de vários hosts. As camadas compartilhadas ainda precisariam ser baixadas, mas o tempo até o primeiro token poderia ficar proporcional ao tamanho ativo, e não ao tamanho total
    Claro, aí já não seria inferência totalmente offline, mas, para um recurso web de navegador, isso talvez não seja a consideração principal
  • Espero que nunca cheguemos a um mundo em que sistemas operacionais passem a incluir modelos pré-instalados de forma estável
  • Muito bom
    Mas, se o modelo é muito maior que o navegador e precisa ser baixado antes do primeiro token, fico curioso se isso significa download sob demanda. Se o usuário só baixar quando fizer a primeira chamada e tiver de esperar até o fim nesse momento, a experiência parece bem terrível
    Também queria saber se o Chrome mostra algo como uma caixa de diálogo de status de download para reduzir a confusão, e quanto espaço em disco isso ocupa

• À primeira vista, parece que isso usa Gemini Nano, mas o Gemma 4 E2B/E4B mais recente parece bem melhor, então talvez por enquanto valha mais a pena distribuir uma versão quantizada via extensão

  • 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
    Fontes:
  • https://huggingface.co/google/gemma-4-E2B-it
  • https://android-developers.googleblog.com/2024/10/gemini-nano-experimental-access-available-on-android.html
  • Não conheço a situação interna atual, mas, na época em que eu estava nesse time, colocávamos os pequenos modelos do Google mais recentes no Chrome muito rapidamente
    Se Gemma 4 ou o Gemini Nano equivalente ainda não estiver no Chrome, eu esperaria que entrasse em breve
    E este texto foi atualizado pela última vez em 2025-09-21, quando já era Gemini Nano 3
  • Isso mesmo
    Está escrito que a Prompt API funciona enviando solicitações em linguagem natural para o Gemini Nano dentro do navegador
  • A Prompt API usa o modelo disponível no navegador
    No Edge, provavelmente seria Phi4

• Isso também parece uma boa maneira de scripts JS maliciosos empurrarem geração de tokens para visitantes desavisados
  Também seria interessante ver se dá para distribuir prompts maiores quebrando-os em partes menores entre vários navegadores, usando algum tipo de padrão de subagente ou estrutura parecida com RLM, de modo a produzir resultados úteis com esse processamento distribuído

  • Parece trabalho demais para a recompensa
    A infraestrutura técnica e de negócio também ficaria extremamente complexa; então, se a ideia é mesmo empurrar prompts para o navegador do usuário, talvez seja melhor simplesmente usar direito a Chrome API. Também é questionável em quantos casos faria sentido real descarregar prompts do servidor para modelos tão fracos
    E, se alguém realmente quisesse fazer isso, WebGPU já existe há bastante tempo
  • A geração de tokens por modelos pequenos quase não tem valor algum

• Isso parece um passo em direção a uma Model API de verdade, mas ainda é só um passo pequeno
  Também me lembra o Foundation Models da Apple
  Muita integração de IA se concentra em comunicação textual ou estilo de chat, mas, na prática, há muito software que também se beneficiaria em interfaces não textuais
  No fim, acho que o sistema operacional e o navegador precisam oferecer APIs que gerenciem modelos, para que apps possam acessar modelos on-device e remotos por meio de uma interface simples
  Seria ótimo se isso fosse padronizado de forma multiplataforma, e precisaria incluir mobile também; então, realisticamente, Apple e Google parecem ser os atores com mais capacidade de empurrar isso. A Meta talvez venha depois, ou até se mova antes, quem sabe
  O ponto principal é que isso não deveria ser exclusivo de um modelo específico promovido por marketing
  Os apps deveriam poder consultar e escolher um modelo apropriado
  (1) https://developer.apple.com/documentation/foundationmodels

  • O Foundation Models da Apple parece bom na documentação, mas, quando você vai olhar de perto, esbarra numa janela de contexto de 4k
    Claro, ainda está bem no começo

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

  • Vale ver também isto: https://github.com/mozilla/standards-positions/issues/1213

• Estamos usando isso para resumos retrospectivos de hackday
  https://remotehack.space/previous-hacks/
  É um script pequeno que lê feeds RSS e gera resumos em forma de texto corrido, e combina bem com um site estático. Um dia eu gostaria de expandir isso para também fazer outras perguntas sobre o mesmo conteúdo

• Um LLM local acessível pelo navegador é ótimo do ponto de vista de privacidade, mas, se cada navegador tiver um modelo diferente por trás dessa API, o pesadelo de testes pode ficar ainda pior do que já é hoje
  No fim, como a maioria das implementações provavelmente vai se alinhar ao Gemini Nano, também fico curioso se isso não vai empurrar ainda mais usuários para o Chrome

  • A fragmentação de testes é realmente o problema central
    Na prática, prompts não são agnósticos a modelo, então um prompt cuidadosamente ajustado para Gemini Nano 3 v2025 pode simplesmente perder desempenho no modelo do Gecko sem nenhum aviso. E a API nem sequer oferece detecção de capacidades para permitir tratamento condicional
    Isso é ainda pior do que o WebGL, que pelo menos permitia consultar suporte a extensões. Lançar uma funcionalidade que depende da qualidade de prompt de um modelo cujo nome e versão ficam escondidos atrás do navegador é quase como lançar um software cuja funcionalidade depende do dicionário instalado pelo usuário

• Pelo que eu entendo, o Gemini Nano não tem pesos abertos como o Gemma
  A menos que alguém já tenha feito isso, eu adoraria tentar extrair os pesos do modelo